The production-readiness checklist for AI-built apps

You shipped something real with AI tools — here's the honest, skimmable checklist to run before you let strangers loose on it.

Building fast with Lovable, Cursor, Replit, Claude Code, v0 or Bolt is a genuinely good way to get a working product in front of people. The gap most founders hit isn't the build — it's the quiet, unglamorous layer underneath: the stuff that decides whether your first real traffic spike becomes a celebration or a 2am incident. This is that layer, laid out as a checklist you can self-audit against today. Work through it honestly. Anything you can't tick is a known risk, not a surprise — and a known risk is one you can plan around.

Security

AI tools are brilliant at happy-path code and less careful about the ways people abuse it. Assume every input is hostile and every endpoint is public until proven otherwise.

• Every API route and database query enforces who is allowed to do what — not just who is logged in, but whether this user owns this record.
• User input is validated and sanitised server-side; client-side checks are for UX, not safety.
• No secrets, API keys or admin flags exposed in the frontend bundle or in client-visible responses.
• Rate limiting on auth, password reset and anything expensive to call.
• Dependencies scanned for known vulnerabilities, and security headers (HTTPS-only, sensible CORS) in place.

Data & database

Your database is the one thing you can't regenerate from a prompt. Treat it accordingly.

• Schema has real constraints — foreign keys, unique indexes, not-null where it matters — so bad data can't quietly accumulate.
• Migrations are versioned and repeatable, not hand-run ALTER TABLE statements nobody wrote down.
• Row-level access rules tested with more than one user account.
• Indexes exist on the columns you actually filter and join on.
• Personal data is minimised, and you know exactly what you store and why.

Tests & CI

You don't need 100% coverage. You need a safety net for the handful of flows that, if broken, mean you have no business.

• Automated tests cover sign-up, login, payment and your core money-making path.
• Tests run automatically on every push — a red build blocks a deploy.
• At least one end-to-end test that exercises the app the way a user would.
• A clean checkout builds and starts from scratch, with setup steps written down.

Production readiness isn't about being bulletproof on day one. It's about knowing where the bullets can get in — and choosing which gaps to close before real users arrive.

Error handling & logging

When something breaks — and it will — the question is whether you find out from your logs or from an angry email. Silent failures are the ones that hurt.

• Errors are caught and logged with enough context to reproduce them, never swallowed.
• Users see a graceful message, not a raw stack trace or a spinning wheel.
• Structured logs go somewhere you can actually search, not just the console.
• An error-tracking tool alerts you when exceptions spike.
• No sensitive data (passwords, tokens, card numbers) written to logs.

Configuration & secrets

Hardcoded keys and "it works on my machine" are the two most common reasons a vibe-built app can't be safely deployed twice.

• All secrets live in environment variables or a secrets manager — never committed to the repo.
• Separate config for local, staging and production, with no production keys on your laptop.
• A documented list of every environment variable the app needs to boot.
• Rotating a leaked key is a five-minute job, not an archaeology dig.

Deployment & rollback

The measure of a deployment process isn't how fast you can ship — it's how fast you can un-ship when a release goes wrong.

• Deploys are repeatable and automated, not a sequence of manual steps you half-remember.
• You can roll back to the previous version in minutes.
• A staging environment mirrors production closely enough to catch problems first.
• Database migrations run safely as part of the deploy, without downtime surprises.

Monitoring & backups

If a backup hasn't been restored, you don't have a backup — you have a hope. Same goes for monitoring you've never seen fire.

• Automated database backups run on a schedule, and you've tested a restore.
• Uptime monitoring pings your app and tells you before your users do.
• Basic dashboards for traffic, error rate and response time.
• Alerts route to a human who's actually watching.

Performance & scale

You don't need to handle a million users. You need the confidence that your first hundred concurrent ones won't take the whole thing down.

• The obvious slow queries (the N+1s, the unindexed scans) are found and fixed.
• Expensive or repeated work is cached where it makes sense.
• Large lists paginate instead of loading everything at once.
• You've run the app under a bit of realistic load and watched what happens.

Legal & ownership

The least technical section, and the one founders skip most often. It's cheap insurance.

• You own the code, the domain and the accounts — not a tool, a contractor or a co-founder's personal login.
• A privacy policy and terms of service that match what the app actually does.
• Licences of any third-party code and assets are compatible with commercial use.
• Payment and data handling meet the basic obligations for your region.

That's the loop we care about: you vibe the idea into existence, we productionise the layer underneath, someone runs it properly so it stays healthy — and you get back to vibing the next thing. This checklist is exactly what our free production-readiness assessment scores you against, dimension by dimension, so you get a clear picture of what's solid and what needs attention before real users arrive. No obligation, no lecture — just an honest read on where you stand.