The Vibe-Code Production-Readiness Checklist

If you built something with Lovable, Cursor, Claude Code, Bolt, v0, or Replit and real users are about to touch it, run this first. It is a standalone checklist, ordered by how often each item bites, that you can work through yourself before you call anyone. One rule: a checkbox only counts when the server enforces it, not the screen.

This is not a knock on vibe-coding. It is how we start too. It is a map of the work that does not happen on its own, so you can find the gaps in AI-generated code before an incident does.

How do I know if my vibe-coded app is production-ready?

Work through the ten checks below in order. Each one is a question with a pass condition. If you cannot answer yes with evidence, it is not done. The first three are the ones that turn into incidents, so do not skip ahead.

The checklist

1. Authorization on the server. For every endpoint and every data read, does the server confirm who is asking and whether they are allowed? A frontend check does not count. Pass: change a user ID in a request and confirm you get a denial, not someone else's data.
2. Tenant and row isolation. If the app is multi-tenant, can one account physically reach another's records? Pass: isolation is enforced at the database or query layer, not in app logic you have to remember to add on every endpoint.
3. No secrets on the client. Are API keys, database URLs, or tokens in the client bundle or the repo history? Pass: a scan of the bundle and git history is clean, and anything ever exposed has been rotated.
4. Input validation at every entry point. Does every form and endpoint reject malformed, oversized, and hostile input cleanly? Pass: throwing junk at it returns a clean error, not a crash or a silent absorb.
5. Failure paths covered. When an external call times out, fails, or returns empty, does the app degrade gracefully? Pass: force each external call to fail and confirm the screen does not go blank with an unhandled exception.
6. Queries that scale. Are there database calls looped inside a render, or whole tables pulled to count rows? Pass: profiled under realistic data volumes, with N+1 queries and unbounded reads removed.
7. Concurrency and idempotency. Do two clicks create two orders, or two parallel requests both pass a balance check? Pass: anything that writes money or state is idempotent and handles duplicate and parallel requests.
8. Owned data layer with backups. Is the data in a managed database you control, with migrations under version control and automated backups? Pass: you have restored a backup at least once. A backup you have never restored is a hope.
9. Dependencies and licences vetted. Does any package carry a known vulnerability or a licence that forbids your commercial use? Pass: a dependency and licence scan is clean or consciously waived.
10. A regression suite exists. Are there tests so the next change, AI-written or not, cannot silently break what works? Pass: a suite runs on every change. See test-driven development for why this matters more, not less, when a model is writing the code.

"A model writes the code you asked for and nothing you forgot to ask for. This checklist is everything you forgot to ask for, in the order it tends to hurt."

Which items block a launch?

Not all ten are equal. Sort your failures into three buckets so you fix the right thing first instead of freezing on the whole list.

• Blocker. Anything that exposes customer data, loses money, or corrupts state: items 1, 2, 3, and 7. These do not wait. The launch waits for them.
• High. Real risk that has not bitten yet: items 4, 5, 6, and a known CVE under 9. Fix before you grow into it.
• Cleanup. Real but survivable: thin validation on low-stakes inputs, missing tests on stable code, the rest of 8 and 10. Worth doing, safe to schedule.

The point of the split is honesty about urgency. Do not dress a cleanup item up as a blocker, and do not let a real blocker hide in a long list.

Can I just ask the AI to fix these?

Partly. A model will happily add a validation check or wrap a call in error handling once you point at the spot. What it cannot do is decide where to look. It has no model of your technical debt and no instinct for the edge case a real user hits on day two. Finding the gaps is human work. Closing them is increasingly shared work. That is exactly how we run it.

What does it cost to clear the whole list?

That depends on what fails and how much money or sensitive data the product touches. We break the typical effort bands and where the time actually goes in what it costs to make a vibe-coded app production-ready. The short version: the audit that runs this checklist is the cheap part, and it tells you the size of the hardening before you commit to it. This is the front end of our software quality assurance service.