How to know if your vibe-coded app is production ready.

The direct answer: your app is production ready only when you have evidence that the live version can handle the important real-world paths—not merely that it looks good or works on your computer. Before launch, prove who can access what, what happens to data and money, how you spot a failure, and how you recover.

What “production ready” actually means

Production is the version used by real people. They may use unexpected devices, enter surprising data, lose a connection, click twice, forget a password or arrive while a service you depend on is unavailable. Production ready does not mean perfect. It means the biggest risks have been checked, known limits are understood, and you have a calm response when something goes wrong.

For a vibe-coded or AI-built app, the key question is not whether an AI wrote some code. It is whether the actual deployed system behaves safely. Treat the AI as a fast collaborator, not as a guarantee.

Start with the live system, not the folder that looks right

Write down the production URL, repository and branch that deploy it, hosting account, database, domain, payment service and email provider. Then check that they connect to one another in the way you think they do. It is common to inspect a local project while an older branch, different database or temporary environment is what customers actually use.

Good evidence: a short list of the live domain, deploy source, production environment and connected services. If you cannot identify one of these, stop calling the app ready until you can.

Use this production-readiness checklist

1. Can the right people do the right things?

Test as a new visitor, ordinary customer and administrator where those roles exist. Logging in answers “who is this?” Permission checks answer “what may they see or change?” An ordinary customer must not be able to view another customer’s data, reach an admin action by guessing a URL, or change records through a browser request.

2. Are secrets and private data out of reach?

API keys, database passwords, payment secrets and private tokens belong in protected server-side environment settings, not in browser code, screenshots or source files. List the personal and business data you store, where it lives and who can access it. If a secret was ever committed publicly, replace it; removing the line does not make the old value safe.

3. Does the critical customer journey work end to end?

Pick the paths that matter most: sign-up, sign-in, saving important work, paying, receiving the purchased item, cancelling, or asking for help. Run each in the production environment. Do not count a payment success page as proof of fulfilment: confirm that the server received verified payment confirmation and that the customer actually got what they bought.

Also try normal mistakes: invalid input, refreshing at the wrong moment, pressing a button twice and returning after a timeout. These are ordinary human behaviours, not edge cases to ignore.

4. What happens when a service fails?

Payments, email, AI models, databases and external APIs occasionally fail or respond slowly. Decide what the user sees, what gets retried, and what must not happen twice. A retry that creates a second order or charges a second payment is worse than a visible, honest error. Important work should have a clear status and be safe to retry.

5. Can AI use create an uncontrolled bill?

If a user can call a model, set sensible limits on request size, frequency, timeout and spend. Confirm that expensive server credentials never reach the browser. Record enough usage to notice a loop, abuse or a feature that suddenly becomes popular. “We will check the bill later” is not a cost-control plan.

6. Will you know when it breaks?

Set up a simple way to see server errors, failed background work and important business events such as failed fulfilment. Logs should help you diagnose a problem without recording passwords, tokens or more customer information than needed. If the first alert is an angry customer message, monitoring is incomplete.

7. Can you restore data and roll back a release?

For meaningful data, verify that a backup exists and practise restoring it somewhere safe. Know how to return to the previous working deployment and how to disable a risky feature. Keep a private note of who controls the hosting, domain, database and payments account. Recovery should not depend on one person remembering a clever command at midnight.

A quick go/no-go test for a solo founder

Make a one-page list with four columns: risk, evidence, owner, next step. For each critical journey, ask: can the wrong person access it; can it lose or expose data; can it take or lose money; and can we detect and reverse a failure? A “yes” without evidence is a task, not a pass.

If you have a known serious gap—such as public secrets, missing permission checks, unverified payments or no way to recover important data—delay the launch or remove that risky feature. If the remaining issues are smaller and understood, launch in a controlled way, keep an eye on the first real users and re-check after changes.

What a production-readiness review should give you

A useful review does not drown you in jargon or pretend certainty. It should show the evidence it found, separate confirmed facts from untested assumptions, rank the risks and give clear next actions. You can see a real redacted example in the Ship Doctor sample report.

KHDS Ship Doctor is built for this moment: vibe coders and non-technical founders who need an evidence-led check inside their coding workspace. The free builder creates a starter instruction. The £49 one-off toolkit adds reusable workflows, diagnostic areas, evidence templates, scoring and a safe remediation plan. For a broader pre-launch list, read the vibe coding security checklist.

Frequently asked questions

How do I know if my AI-built app is ready to launch?

Look for evidence across the live version: access, data, critical journeys, costs, monitoring and recovery. A polished demo alone is not evidence of these things.

Is a working demo production ready?

No. A demo proves one path in one setting. Production readiness includes real users, live integrations, failures, duplicate actions and recovery.

What is the quickest production-readiness check?

Trace a user access journey, a purchase or other business-critical journey, and a failure or rollback journey. Record what happens and what remains unverified.

Can a non-technical founder do a production check?

Yes. You can ask for evidence, follow the journeys and assign an owner to each risk. A technical reviewer or AI assistant can help inspect, but should not hide uncertainty.