The Vibe-Code Production-Readiness Checklist

If you built something with Lovable, Cursor, Claude Code, Bolt, v0, Replit, or conventional tools and real users are about to touch it, use this as a first pass. It is not a complete production-readiness or security standard. Tailor the checks to the architecture, data, threat model, regulation, and potential harm. One rule: a visual control is not an authorization boundary; trusted enforcement must occur where the protected action or data is controlled.

This is not a knock on vibe-coding. AI-assisted and human-written code need the same evidence-based engineering controls. The checklist was reviewed on 2 September 2026 against the OWASP ASVS, OWASP API Security Top 10, and NIST SSDF.

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

Use the ten checks as triage, then add architecture-specific requirements. A pass condition needs evidence, but passing all ten does not prove readiness. Risk, exploitability, exposure, and impact determine priority; the numeric order is not an incident-frequency ranking.

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 confidential secrets on the client. Are privileged API keys, credentials, or bearer tokens in the client bundle, logs, build artifacts, or repository history? Some public identifiers and publishable keys are designed for clients, but they still require least privilege and server- or data-layer authorization. Rotate exposed confidential credentials and verify revocation.
4. Input and output validation at trust boundaries. Do APIs, queues, webhooks, file parsers, and downstream integrations enforce schema, size, type, encoding, and business constraints? Client validation helps usability but is not a security boundary. Test malformed, oversized, hostile, and unexpected upstream responses.
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, replay, and idempotency. Identify operations where duplicate or parallel execution would cause harm, such as charges, inventory, entitlements, jobs, or external side effects. Apply idempotency keys, uniqueness, locking, transactions, ordering, or deduplication as the workflow requires. Not every state change should be blindly repeatable.
8. Recoverable data and configuration. Define recovery objectives for databases, object storage, identity configuration, secrets, and infrastructure state. Version migrations where applicable, automate backups, protect them from the same failure domain, and test restoration plus reconciliation.
9. Dependencies and licences governed. Inventory direct and transitive components, versions, provenance, support status, vulnerabilities, and licence obligations. A scanner finding is input to exploitability and business-risk assessment, not an automatic pass or fail.
10. Proportionate regression evidence exists. Run automated tests and other verification on every relevant change, covering critical behavior, authorization, failure paths, migrations, and integrations. No suite can guarantee that the next change cannot break working behavior. See test-driven development for one useful practice.

"AI-generated code does not change what production evidence you need. Start with authorization, isolation, secrets, validation, recovery, and verification, then extend the review to the system's actual threats and obligations."

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. A credible path to unacceptable harm with no effective control or recovery, such as unauthorized sensitive-data access, unsafe privileged actions, duplicate charges, or unrecoverable corruption.
• High. A material weakness whose likelihood or impact requires treatment before the planned exposure, including exploitable vulnerable components or untested critical failure paths.
• Scheduled treatment. Lower residual risks with a named owner, deadline, monitoring, and explicit acceptance by the accountable decision-maker. Missing tests or recovery evidence can still be blockers when the affected function is critical.

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?

AI can help inspect code, generate tests, trace data flows, and propose fixes, but its findings depend on repository access, tools, prompts, model behavior, and the quality of specifications. It can miss cross-system assumptions and can also produce false positives or unsafe patches. Use it as one reviewer alongside threat modeling, automated analysis, dependency inventory, dynamic tests, and qualified human review. That is how we run custom software development.

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.