Production readiness checklist for an AI-built app
This is the list we work through on a paid check, published because most of it you can do yourself in an afternoon. It is ordered by what would hurt first, not by what is easiest.
Free no sign-up, no email
Before anything else: what is exposed
These are the ones where the damage is already done by the time you notice, so they come first regardless of how your app is built.
- Search your repository history for keys, not just the current files. A secret that was committed once and deleted later is still in the history and still works.
- Open the browser devtools on your own site, look at the network tab, and check what the client bundle contains. Anything the browser can read, a stranger can read.
- Take a URL that shows your own data, log out, and open it again. If it still works, every other user’s data works the same way.
- Change the id in that URL to somebody else’s. This is the single most common hole in generated code, because the generator was asked to show the data, not to check who is asking.
- Check what your error pages say. A stack trace in production tells a stranger the shape of your database.
Then: what happens when it stops
- Kill the process and watch. Does it come back on its own, or does it stay dead until somebody notices?
- Would you find out? Not "is there a dashboard" — would a message reach you, on a device you look at, before a customer wrote to you?
- Deploy something broken on purpose, in a copy. How long does it take to get the previous version back, and do you know the command without looking it up?
- Write down what happens if the one provider you depend on has an outage. You may decide to accept it; deciding is the point.
Then: whether your data survives
This is the one people are most confident about and most often wrong about, because the backup usually exists and has never been used.
- Restore a backup into a scratch environment. Actually do it. An untested backup is not a backup — it is a file you hope about.
- Check how far back the backups go and how often they run. Nightly and seven days is a choice; not knowing is not.
- Check that the backup is not stored only in the same account that holds the thing being backed up.
- If your database migration has a rollback path, read it. A rollback that drops a column a live deploy still needs is data loss with a friendly name.
Then: the things that expire on their own
- The TLS certificate. If it is not renewed automatically, put the expiry date in your calendar now — it will otherwise expire on a weekend.
- Domain renewal, and whether the card on file is still valid.
- API keys and OAuth tokens with an expiry, especially for payment and email providers.
- Free tiers you built on. They change, and the change arrives as an email you will not read.
Then: the boring correctness ones
- Every outbound call has a timeout. A request with no timeout does not fail — it hangs, and it takes the process with it.
- Retries are bounded, and only wrap operations that are safe to repeat. An unbounded retry on "send money" is not a resilience feature.
- Rate limiting on anything a stranger can call, especially the form on your marketing page.
- Test what happens with a very large input and a very strange one — an emoji, an apostrophe, a 10MB paste.
- If two people can act at the same moment, test that, not a sequential stand-in.
Last: the one nobody writes down
Can somebody who is not you run this? If your app can only be deployed from your laptop, with your keys, using steps that live in your head, then the risk is not technical any more. Write the runbook — how to run it, how to deploy it, how to roll it back — and hand it to somebody to follow while you say nothing. Whatever they get stuck on is the real state of your documentation.
If you would rather someone else did this
That is the Production check: we work through this list on your codebase and the place it runs, and write down what breaks first, what each fix costs, and the order to do them in. $450, five working days, and the report is yours either way.
Questions people ask first
Is this list specific to AI-built apps?
The list is not, but the ordering is. These are the checks that generated code fails most often, put in the order that matters when something is already live and carrying users, rather than in the order a textbook would use.
How long does it take to work through?
The exposure section is an afternoon. The rest depends on what you find — and finding nothing is itself a result worth having.
Do I need to sign up for anything to read this?
No. The whole list is on this page. There is no download, no email gate and no PDF.
The rest of what we do
- Production check — It works. People are using it. And nobody has ever checked what happens when it does not — when the database f…
- Make it production-ready — For something that was built quickly and now has people depending on it. One fixed number, agreed before any w…
- Keep it running — The part nobody wants to own. Your app is live and someone has to notice when it stops, renew the things that …
- Build in stages — From an idea, or from a project that stalled. Priced one stage ahead and paid per stage, and you own everythin…
- Our own products — what we build for ourselves, and run.