A production-readiness checklist for apps built with AI

An app that demos well and an app that survives the move to production are different things, and the gap between them is where most AI-built projects stall. The code works on your machine, against clean data, with one user: you. Production is none of those. This is the checklist we work through, grouped by what tends to fail first. None of it is fancy. The point is that fast, AI-assisted builds usually skip all of it.

Secrets and configuration

• No secrets in the repository or its git history. A key committed once and “removed” in the next commit is still in the history and still leaked. Generate a new one and move it to a secret manager or environment variables.
• Configuration is per-environment, not hardcoded. The same build runs against staging and production by changing config, not code.

Error handling and logging

• The app is resilient to invalid or malicious input. Every call that can fail (network, database, third party) is handled, and the user sees a sane message instead of internal error details. Invalid and malicious input is rejected.
• Logs are structured and searchable, with enough context to find the failing request later. A log you cannot query is a log you do not have.

Authentication and authorisation

• Access is enforced at the API, not just hidden in the user interface. A button you cannot see is not a permission; an endpoint that checks who it is talking to is.
• Sessions and tokens expire and can be revoked.

Tests and CI

• A CI pipeline runs on every push and blocks a merge when any of its safeguards detect an unwanted change.
• End-to-end tests cover the key paths that cannot fail you (sign-up, checkout, the most important processes your app carries out). You do not need full coverage to sleep at night. You need the critical paths tested automatically.

Data

• Backups run automatically, and a restore is verified. A backup you have never restored is a guess, not a backup.
• Schema changes are migrations, versioned and reversible, not manual edits against the live database.

Observability

• Errors are tracked somewhere you actually look, with alerts on the ones that matter.
• Uptime and a few key metrics are monitored, so you learn about an outage from a dashboard, not from a customer.

Deployment

• The app lives at a real address with a process that restarts itself when it dies. localhost:3000 and a terminal you must keep open is not a deployment.
• Deploying is one repeatable step, and you can roll back. A manual, multi-step release is a manual, multi-step way to take production down.

Scalability, when you actually need it

• The critical path must be load-tested at a multiple of today’s traffic, so you know where it bends before your users find out.
• State lives in the database or a cache, not in the process, so you can run more than one instance behind a load balancer.

How to use this

Do not try to do all of it at once, and do not do it in random order. Fix the security and data items first, because those are the ones that turn a bad day into a lost company. Then deployment and tests, so you can change things without fear. Observability and scale come once the rest is steady.

If you would rather not score your own homework, that is what a Review is for: an outside read of where your app stands against this list, what is solid, what is fragile, and what to fix first, with a quote for the work if you want it done.