Production readiness checklist
Is Your App Ready for Production? A 3-Minute Self-Check
Answer 14 short questions about your app. You get your top risks in plain words and one recommended next step. Built for founders who shipped with Lovable, Bolt, Cursor or Replit and are about to take payments or personal data.
Production readiness self-check
Step 1 of 30 of 14 answered
About your app
Four quick questions. They decide which next step fits.
What is a production readiness review?
A production readiness review is a check, done before launch, that an app can handle real users, real money and real failures. It looks past whether features work: who can see which data, whether payments survive retries, whether backups restore, whether anyone hears about an outage, and whether someone else can ship a fix.
Larger companies run the review with a reliability or platform team before a service takes real traffic. A founder with an AI-built app usually has no such team, so this self-check covers the questions that matter most at that stage.
Treat it as a first pass. A full production readiness assessment reads the code and tests each answer, which is what our vibe code audit does.
What does the production readiness checklist cover?
The checklist covers 10 areas where apps built with AI tools most often fail after launch: access rules, secret keys, payments, backups, alerts, AI spend, AI actions, tests, consent and deploys. Each check is a yes or no question a founder can answer without reading code. Every No or Not sure is a risk to look at.
| Check | Why it matters | Risk if the answer is No |
|---|---|---|
| Have the access rules on your tables been tested by signing in as two different users? | Rules can be switched on and still show one user the records of another. | Data leak between users |
| Are your secret keys kept only on the server? | A key in the app bundle or in git history can be read by anyone. | Exposed keys |
| Do payments survive a double click and a repeated webhook? | Without that, retries create duplicate customers or charge twice. | Double charges |
| Have you restored the app from a backup at least once? | A backup nobody has restored may not bring the app back. | Data loss |
| Does an alert reach your phone when the app breaks? | Without alerts, your users find failures before you do. | Silent outages |
| Is there a limit on AI spend per user? | One user or one bug can run up your AI provider bill. | AI cost overrun |
| Does the AI wait for a human confirmation before it changes data or money? | Text the model reads can talk it into actions nobody approved. | Unapproved AI actions |
| Do tests run before every release? | Each new change can quietly break what already works. | Regressions in production |
| Does analytics start only after the user consents? | Tracking before consent breaks the promise in your privacy policy. | Consent breach |
| Could someone other than your current developer deploy the app? | If one person leaves, nobody else can ship a fix. | Single point of failure |
Copy the table into a spreadsheet to use it as your own production readiness review checklist.
What happens after the check?
You get one recommendation. If nobody owns the technology or deploys depend on one person, start with a fractional CTO. If you have 100 or more users and no alerts, start with 24/7 DevOps support. Otherwise, start with a vibe code audit of the code itself, from $199 at a fixed price.
Talk to a fractional CTO
Nobody owns the technology, or your deploys depend on one person. A fractional CTO takes that ownership part-time and decides what to fix first.
How the fractional CTO worksGet 24/7 DevOps support
You have 100 or more users and no alert reaches you when the app breaks. Someone needs to watch production and answer at night.
See DevOps supportStart with a vibe code audit
A senior engineer reviews the code across 8 areas and ranks what will hurt you first. Fixed price, from $199.
See the audit
Frequently asked questions
A production readiness checklist is a list of conditions an app must meet before it serves real users. It covers security, payments, backups, monitoring, testing and deployment. Each item is a yes or no question, so gaps are easy to see. This one is written for founders whose apps were built with AI tools.
The terms are used loosely. A review is usually a checklist meeting before launch. An assessment usually goes deeper and checks the evidence: it reads the code, runs tests and scores each area. This self-check is a quick review. Our vibe code audit is a full assessment by a senior engineer.
Yes. The table on this page works as a template: 10 checks, why each matters and the risk behind a No. Copy it into a spreadsheet and add an owner and a date for each gap. Run it again before every major release, and whenever the person who deploys the app changes.
It shows where to look. It cannot prove the answers, because a Yes reflects what you believe the app does. Access rules, payment retries and AI approvals have to be tested in the code. If you take payments or personal data, have someone who reads code test them before launch.
Not sure how to read your result?
Book a 20-minute call. Bring your answers, and we will tell you which step makes sense first.
Prefer to talk?