Your vibe-coded app runs fine in the demo. That is not the same thing as being ready for real users, real data, and real downtime at 2am.
"Vibe coding" — building software by prompting an AI and shipping what works — gets you to a demo astonishingly fast. The gap it hides is everything that keeps an app alive after launch: a stack you can actually update, a place the code lives that isn't one laptop, a deploy you can repeat, backups you have actually restored, secrets that aren't pasted in plain text, monitoring that tells you before your users do, and a handoff a new person could follow.
Below is a 7-point production-readiness check you can run on any AI-built or vibe-coded app in about ten minutes. For each point: the question to ask, why it bites in production, and the minimum bar to clear.
1. Known, updatable stack
Ask: Do you know exactly what the app is built on — and can you update it when a dependency ships a security patch?
If the honest answer is "the AI picked the libraries and I'm not sure which versions," you have an update problem waiting to happen. Vibe-coded apps often pin nothing, mix incompatible packages, or depend on a framework the author can't name. The first critical CVE turns that into an emergency you can't triage.
Minimum bar: You can list the language, framework, and major dependencies, and you have run a dependency update at least once without the app breaking.
2. Version control and a real owner
Ask: Where does the code live, and who is allowed to change it?
"It's in the ChatGPT thread" or "it's on my Mac" is not version control. Without git (or equivalent) plus a named human owner, there is no history to roll back to, no review before a bad change lands, and no way to answer "who touched this?" after an incident.
Minimum bar: Code is in a repository with commit history, and one specific person is accountable for merges.
3. Repeatable deployment
Ask: How does a change get from your machine to production — and could someone else do it?
If deployment is "I drag files into the host" or "I re-run the prompt and copy-paste," you cannot ship a fix quickly or safely under pressure. Manual, undocumented deploys are where late-night mistakes happen.
Minimum bar: There is a documented, repeatable deploy path (a script, a CI pipeline, or a one-command push) that a second person could follow.
4. Backups with a tested restore
Ask: If the database died today, what happens?
The dangerous answer isn't "we have no backups" — it's "we have backups but we've never restored one." An untested backup is a hope, not a recovery plan. AI-built apps frequently ship with the default managed database and zero restore drill.
Minimum bar: Automated backups exist and you have restored one into a scratch environment and confirmed the data came back.
5. Managed secrets, scoped access
Ask: Where do API keys and passwords live?
Vibe-coded code loves to inline secrets — in the source, in a committed .env, in the prompt history. Once a key is in a repo or a screenshot, treat it as public. The blast radius of a leaked production key (billing, data export, account takeover) is rarely scoped down.
Minimum bar: Secrets live in a secret manager or environment config outside version control, and each key has the narrowest scope that still works.
6. Monitoring with alerts
Ask: How do you find out the app is broken?
"A user emails me" is not monitoring. Without uptime checks, error tracking, and an alert that actually reaches a human, you learn about outages last — after they've already cost you trust.
Minimum bar: An uptime check plus error tracking, wired to an alert (email, Slack, phone) that someone will see.
7. A handoff a new person can follow
Ask: Could someone who has never seen this codebase take it over?
This is the summary of the other six. If the only person who understands the app is the person (or AI session) that built it, every future change is a risk and every absence is a single point of failure. A prototype becomes a real product the moment a second person can safely run and change it.
Minimum bar: A short README or runbook that covers stack, how to run it locally, how to deploy, where secrets live, and where backups are.
Score yourself honestly
Count how many of the seven you can clear at the minimum bar:
- 6–7: You have a real product, not just a demo. Tighten the gaps and keep shipping.
- 3–5: It works today and will hurt later. Prioritise backups-with-restore, secrets, and monitoring first — those cause the worst incidents.
- 0–2: Treat it as a prototype, not something to depend on. Do the hardening before you put real users or real data on it.
Turn the answers into a checklist
If you want to run this as a scored, private self-check — no sign-up, nothing stored, everything in your browser — I put the interactive version and a copyable hardening checklist here:
Is your vibe-coded app production ready? — free self-check
It walks the same seven dimensions, scores your readiness, surfaces your biggest gaps first, and gives you a checklist you can paste straight into your issue tracker.
Shipping fast is good. Shipping fast and being able to keep it alive is the whole game.
Disclosure: I work on Omni Care, which helps teams take over and productionise AI-built and vibe-coded apps. This article was drafted with AI assistance and reviewed for accuracy before publishing. The self-check tool linked above is free and stores nothing.
Top comments (0)