// the checklist
The 12-point production readiness checklist
AI tools optimize for code that works, not code that survives. These are the twelve checks that separate a working prototype from software you can trust with real users and real traffic — what each one means, and what "passing" looks like. It's the same audit we run first when we open the hood on an AI-built app.
// security
Security
Authentication done right
AI tools routinely scaffold login flows with hardcoded credentials, weak session handling, or tokens that never expire. A working login screen is not the same as secure authentication.
Passing looks like: Sessions expire, tokens are signed and rotated, and no credentials live in the code.
Role-based access & authorization
The most common AI-generated flaw is checking who you are but not what you're allowed to do — so any logged-in user can reach any record by changing an ID in the URL.
Passing looks like: Permissions are enforced on the server for every request, not just hidden in the UI.
Secrets & API keys out of the frontend
Prompt-generated code frequently leaves API keys, database strings, and third-party secrets hardcoded in client-side code or committed to the repo — one of the most expensive mistakes in AI-built apps.
Passing looks like: All secrets live in environment variables or a secrets manager, never in the bundle or git history.
Input validation & sanitization
Every field a user can touch is an attack surface. AI code tends to trust input, opening the door to injection, XSS, and corrupted data.
Passing looks like: Inputs are validated and sanitized server-side before they touch your database or render to a page.
// resilience
Resilience
Error handling that fails safe
Prototypes crash loudly or leak stack traces when something unexpected happens. In production, a single unhandled error can take down a whole request path or expose internal details.
Passing looks like: Errors are caught, logged, and returned as safe responses — the app degrades instead of collapsing.
Rate limiting & abuse controls
Without limits, one scraper, bot, or bad actor can run up your bill, exhaust your database, or take the service down for everyone.
Passing looks like: Endpoints are rate-limited and protected against obvious abuse and runaway usage.
Backups & recovery
AI-built apps almost never include a backup or recovery plan. The first data-loss incident is not the time to discover you don't have one.
Passing looks like: Data is backed up on a schedule and you've actually tested restoring from it.
Load tested for real traffic
Everything works when it's you clicking around. The question is what happens at a thousand concurrent users — the exact moment a launch or a press hit should be a win, not an outage.
Passing looks like: The system has been tested under realistic peak load and holds its response times.
// quality & operations
Quality & operations
Real test coverage
AI can generate happy-path tests that prove nothing. Production breaks on the edge cases, the error conditions, and the "what happens when two people do this at once."
Passing looks like: Tests cover edge cases, failures, and integration points — not just the path where everything goes right.
Database indexes & performance
Generated queries work fine on ten rows and crawl on a hundred thousand. Missing indexes and N+1 queries are a silent time bomb that only detonates once you have real data.
Passing looks like: Queries are indexed and profiled; the app stays fast as the data grows.
Logging & observability
When something breaks at 2am — and it will — you need to know what happened. Most AI-built apps ship with no way to see inside them.
Passing looks like: Requests, errors, and key events are logged, and you can trace a problem to its cause.
CI/CD & safe deploys
Manually copying files to a server is how prototypes ship and how production goes down. You need a repeatable, reversible way to release.
Passing looks like: Deploys run through a pipeline, are repeatable, and can be rolled back cleanly.
The honest rule: 10 of 12 passing before you point paid traffic at it. Three or fewer, and it's still a prototype — no matter how finished it looks. Read why AI-built apps hit this wall.
// questions
Common questions
What does "production-ready" actually mean?
Production-ready means software that keeps working under real conditions — real users, real traffic, real attackers, and the edge cases nobody typed into a prompt. A prototype proves the idea works; a production system is a promise it will keep working. The twelve checks on this page are the concrete difference between the two.
How many of the 12 should pass before I launch?
Our rule of thumb: at least 10 of 12 passing before you point paid traffic at an app. Three or fewer passing means what you have is still a prototype, no matter how finished the interface looks. The security checks in particular are non-negotiable before real users and real data are involved.
Is AI-generated code production-ready by default?
No. AI coding tools optimize for code that runs, not code that survives. Independent testing has found that roughly 45% of AI-generated code introduces an OWASP Top 10 vulnerability when no security guidance is given. That does not make AI tools bad — it makes production-readiness a separate discipline you have to apply on top of them.
// book an audit
Not sure where your build stands?
Send us what you've built. We'll run this exact audit and tell you honestly how many checks you pass — and what production-ready would take.
Got it — thanks.
We'll take a look at what you've sent and get back to you within one business day.