Production readiness: the checklist your AI-built app has to pass.

The demo standard and the production standard are different tests.

A demo passes when it works for you, once, on your machine, with friendly data. A production app faces strangers, malformed input, concurrent users, real money, and the legal weight of holding other people's information. AI coding tools are excellent at the first standard. The second one is engineering, and it does not happen by accident.

The good news: for most vibe-coded apps the distance between the two is a bounded, known list of work, not a rewrite. Here is the list.

The six areas, with the checks that matter.

1. Secrets

• No API keys, tokens, or service credentials in the client bundle. Search your built output, not just your source.
• Nothing sensitive in git history. Deleted in a later commit does not mean gone; see our leaked key response plan.
• Secrets live in environment variables or a secret manager, separated per environment.

2. Access

• Database-level access rules on every table and bucket: Supabase RLS or Firebase rules, with default deny.
• Authentication hardened: email confirmation, tight redirect allowlists, sane session expiry. See the auth checklist.
• Authorisation checked server-side. Signed-in is not the same as allowed.

3. Data

• Every write validated at the boundary: types, ranges, ownership.
• Automated backups on, and a restore actually tested once. An untested backup is a hope, not a plan.
• Schema changes go through migrations, not hand edits in a dashboard.

4. Reliability

• The obvious hot queries are indexed, and connections are pooled. See why AI-built apps fall over under load.
• Public endpoints are rate limited.
• You have load-tested the signup and the busiest write path, even briefly.

5. Observability

• Error tracking wired in, so you hear about crashes before your customers tell you.
• An uptime check on the public URL.
• Logs you can actually search when something goes wrong at 22:00.

6. Ownership

• The domain, the repo, the database, and the billing are in accounts you control, not a freelancer's or a platform default.
• You can export your code and your data today, and you know the steps.
• Someone specific gets alerted when things break, and they know what to do first.

The three checks almost everyone skips.

1. The restore test. Backups fail silently more often than databases do. Restore last night's backup into a scratch project once, time it, and write the steps down. Thirty minutes now, existential later.
2. The load test before launch. Ten minutes with a free tool against your signup flow finds the missing index and the connection exhaustion while they are still cheap to fix.
3. The incident plan. One paragraph: who notices, who acts, what gets checked first, and where the keys live. Written calmly beats improvised at midnight.

Run it yourself, or have it run for you.

A technical founder can work through this list in a focused week, and the linked guides give you the commands for the sharpest items. What a production-readiness review adds is speed and blind-spot coverage: senior engineers who have seen where AI-built apps actually fail go through all six areas against your real code and infrastructure, and hand you a ranked list: what must be fixed before real users, what can wait, and what is already fine. If the app only needs a few small fixes, the review says exactly that.