The Production Readiness Checklist for AI-Built Apps

Most launch checklists you find were written for teams with a platform group and a release manager. They assume you already have staging, alerting, and a runbook, and they spend their time on things like canary percentages.

This one assumes the opposite: an app generated largely by AI, one or two people who understand it partially, and a launch date. It is ordered by consequence, not by category, so you can stop when you run out of time and know exactly what you accepted.

Eight gates. The first three are launch blockers.

Gate 1: No secret is reachable from a browser

Open your deployed app, open the network tab, and search the JavaScript bundle for the strings 'key', 'secret', 'sk-', and 'service_role'. Then search your repository history, not just the working tree — GitGuardian counted 28.65 million new hardcoded secrets in public commits during 2025, and AI-assisted commits leaked at roughly 3.2 percent versus a 1.5 percent baseline. AI code assistants inline credentials because that is what makes an example run.

Two things must be true: no privileged key is present in anything the client downloads, and every key that ever was present has been rotated. Removing a secret from a file does not un-leak it; the old commit still has it and so does anyone who cloned. Our walkthrough of finding every secret an AI left in your repo covers the history-scanning part properly.

Gate 2: One user cannot read another user's data

This is the failure that ends companies, and it is the single most common defect in AI-built apps. The test takes ten minutes and you can run it yourself: create two accounts, log in as the first, capture a request that fetches a record, then replay it from the second account's session with the first account's record ID.

If you get data back, you have a broken authorization boundary. Enabling row-level security is not the same as having correct policies, and a policy that references the wrong column passes every casual test. The specific mistakes repeat across projects — we catalogued them in RLS mistakes in AI-generated Supabase apps.

Check the write side too. Reading someone else's invoice is bad; updating it is worse.

Gate 3: Money cannot be double-charged or bypassed

If payments exist, three things must hold before launch: webhook signatures are verified, webhook handling is idempotent so a retried event does not charge twice, and entitlement is granted by the webhook rather than by the browser saying the checkout succeeded. That last one is common in generated code and means a user can grant themselves a paid plan by calling your own endpoint.

Gate 4: The database refuses bad data

Validation in the UI is a convenience feature. Constraints in the database are the actual rule. Confirm that required columns are NOT NULL, that anything that should be unique has a unique index, that foreign keys exist and have a defined delete behavior, and that money is stored as integers or a decimal type rather than a float.

Generated schemas are usually permissive because permissive schemas never throw errors during a demo. You find out later, when support asks why one customer has four half-created subscriptions.

Gate 5: Every external call has a failure path

Find each call to a third-party API — payments, email, an LLM, storage — and answer three questions: what does the user see when it fails, does the app retry, and can a retry cause a duplicate. AI-generated code is written for the happy path, so a timeout typically produces a spinner that never stops.

Add timeouts, decide on retry behavior deliberately, and make sure errors reach you and not just the console.

Gate 6: You can deploy and roll back

You need a repository you control, a deployment that runs from that repository, environment variables managed per environment, and a way back to the previous version that takes minutes rather than a rebuild. If the only copy of your app is inside a builder's preview environment, you do not have a rollback path — you have a hope.

A staging environment matters more here than the checklist tone suggests, because it is where you test the migration that would otherwise be tested on customers. See why you need a staging environment.

Gate 7: You find out before your users do

At minimum: error tracking on both client and server, uptime checks on the primary endpoints, and alerts that reach a phone. Logs need enough context to answer "which user, which request, what was the input" — a bare stack trace tells you something broke and nothing about who it broke for. Sizing this for a small team is covered in monitoring and alerts for a small SaaS.

Gate 8: Abuse costs the attacker something

Rate limit authentication, signup, password reset, and anything that calls a metered API on your account. An unlimited endpoint that proxies an LLM is a bill waiting to happen, and it will arrive on a weekend.

Where to stop if you are out of time

The first three are non-negotiable because their failure modes are irreversible. You cannot un-leak data or un-charge trust. The rest are expensive but recoverable, which is what makes them schedulable.

Clearing all eight on a typical AI-built MVP takes two to four weeks of focused engineering. The phase-by-phase version of that estimate is in how long a rescue takes.

Frequently asked questions

Can I ask my AI tool to run this checklist for me? It is genuinely useful for gates 4, 5, and 8 — mechanical, local changes it can make and you can verify by reading. It is unreliable for gates 1 and 2, because the model cannot test its own authorization rules from a second user's session, and it will report success based on the code looking correct. Verify those two by hand.

How do I know if I passed gate 2 rather than just believing I did? By replaying a real request with a different account's token and confirming you get a 403 or an empty result, for read and write, on every table that holds user data. A passing test is one you watched fail from the wrong account.

Do I need all of this for a beta with twenty friendly users? You need gates 1 through 3. Friendly users still have real credentials and real data, and a leaked key does not care how many people are on the waitlist. The rest can follow the traffic.

---

If you have a launch date and a list you are not sure you can clear, that is exactly the situation to get a second set of eyes on. SprintX runs this checklist against AI-built apps and hands back a prioritized report with fixed-price fixes for what fails. Send us your app and repo.