A Pre-Launch Audit Checklist for AI-Generated Code

If you built your app with AI — Cursor, Claude, ChatGPT, or any of the app builders — and you're about to put it in front of real users, this checklist is for you. It's the list we work through when someone hands us an AI-generated codebase, written so a technical founder can run most of it themselves in an afternoon or two.

A note on spirit before the list: the goal isn't to prove your code is bad. Most AI-built apps we look at are a mix — genuinely solid in places, hollow in others — and the hollow places cluster in predictable spots, because AI code fails in patterns (we wrote about why in why AI-built apps break in production). This list is those spots, in the order we'd check them.

For each item: check it, and write down what you find. A one-page honest list of "known problems" is worth more before launch than any amount of optimism.

Security — check these first

1. Are there secrets in the code? Search your repository for API keys, passwords, and tokens pasted directly into files — grep for things like key, secret, password, and the first characters of keys you recognize (sk-, AKIA). Every hit should move to environment variables, and any key that was ever committed should be rotated — its history remembers it even after you delete the line. This is the single most common finding in AI-built apps, and one of the most dangerous.

2. Does the server enforce who can do what? Not the interface — the server. Hiding the delete button from non-admins is cosmetics; the question is whether the server would refuse the delete request if a non-admin sent it directly. Test it: log in as a regular user, and try to call an admin action yourself. AI code fails this constantly because a client-side check looks identical in a demo.

3. Can one user reach another user's data? Take a URL or record that belongs to account A — an order page, a document — log in as account B, and try to open it, including by just editing the ID in the address bar. Every list and lookup should be scoped to the logged-in user on the server. This single test finds the most embarrassing class of breach there is.

4. Is anything validated on the way in? Paste something absurd into every input — a novel into the name field, negative numbers into quantities, script tags into anything that gets displayed back. The app should reject bad input cleanly, not store it, crash on it, or worst of all execute it.

5. Do your dependencies actually exist and hold up? AI occasionally invents package names, and attackers publish malware under those hallucinated names. Read your dependency list: do you recognize each package? Then run your ecosystem's audit tool (npm audit or the equivalent) for known vulnerabilities in the ones that are real.

Correctness — the quiet failures

6. What happens when things fail? Find the payment call, the email send, the file upload — anything that talks to the outside world — and read what happens when it fails. If failures are caught and ignored, the app doesn't crash; it silently does the wrong thing, which is worse. Every failure should do something deliberate: retry, tell the user, or at minimum get logged.

7. Does the same rule live in three places? Pick a business rule that matters — how a price is calculated, who counts as active — and search for it. AI sessions love re-implementing logic instead of reusing it, and the copies drift. If a rule exists in more than one place, one of them is wrong or will be soon.

8. Do the empty and in-between states work? New account with no data. A list with one item, and with a thousand. A page refreshed mid-action. A back button pressed at a weird moment. The happy path got demoed; these didn't.

Data — the part you can't un-lose

9. Do backups exist, and has anyone ever restored one? Not "the platform probably does it" — find the backup, and do a test restore. An untested backup is a hope, not a backup. Do this before launch, not after the first disaster.

10. Can the database structure change safely? When you change how data is shaped, does that happen through some orderly, repeatable mechanism (migrations), or by hand-editing the live database? Hand-edited production databases are how one bad Tuesday becomes unrecoverable.

11. Will queries survive real amounts of data? The classics: lists that load everything with no page size, lookups on columns with no index, and queries-inside-loops that turn one page load into a thousand database trips (the N+1 pattern). All invisible with 20 test records; all fatal at 50,000. If you can, load a realistic volume of fake data and click around.

Operations — can you actually run this thing?

12. When it breaks at 2 a.m., how will you find out? If the answer is "a customer emails me," you have no monitoring. At minimum you want error reporting that notifies you (a free-tier error tracker is fine) and logs you can actually read when chasing a problem.

13. Is deploying repeatable? Could you put out a one-line fix in ten calm minutes, or is deployment a ritual of manual steps someone has to remember in order? And is there anywhere to try a change that isn't directly on your live customers? A separate staging environment — even a scrappy one — is the difference between testing and gambling.

14. Are test data and live data actually separate? Same database? Test keys in production? Real customer emails reachable from a test run that sends mail? Sort the environments out before launch week sorts them out for you.

The honesty item

15. Can you explain every file? Walk your own repository and ask, for each piece: do I know what this does and why it's here? Every file where the honest answer is "the AI added that at some point" is unreviewed surface area — not necessarily broken, but unknown, and unknown is where the next incident lives. This item more than any other tells you the true state of the codebase: the problem with vibe-coded apps was never that a machine wrote them, it's that no qualified person has read them.

What to do with your findings

Don't aim for a perfect score — production software run by careful teams wouldn't ace this list. Aim for known: items 1–5 fixed before launch (security debt is the kind that compounds against you), 6–11 triaged with eyes open, 12–15 scheduled. A launch with a written list of known risks is a professional launch. A launch with no list is just item 15 wearing a party hat.

And if you hit the edge of what you can evaluate yourself — a lot of technical founders can run these checks but aren't sure they'd recognize a subtle failure of item 2 or 11 when it's in front of them — this checklist is literally the job we do as a free AI code audit. Read access is enough, nothing in your code changes, and in 48–72 hours you get the written version of everything above, run by people who do it for a living: what's solid, what's fragile, what's dangerous, and what we'd fix first. Free, no obligation, yours to keep.

Either way — run the list. Every item you check moves a risk from the "surprise" column to the "known" column, and that's the whole game before a launch.