Your Vibe-Coded App Runs in the Demo. Here's the 7-Point Production-Readiness Check Before You Ship It.

Omni Care — Fri, 25 Sep 2026 01:56:31 +0000

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.

Inherited an Unmaintained or Vibe-Coded App? A 7-Point Takeover Check Before You Touch the Code

Omni Care — Thu, 24 Sep 2026 11:47:26 +0000

When a developer leaves — or an AI-assisted "vibe-coded" prototype suddenly has to go to production — someone inherits a codebase they didn't write. The instinct is to start fixing things. That's usually the expensive mistake. Before you change a single line, run this takeover check.

1. Do you actually control it?

Repo access is not control. Confirm you hold the production hosting account, the domain and DNS, the database, the DNS registrar, and the deploy pipeline — under accounts your company owns, not a personal login from the person who left. If any of these sit in someone else's account, getting control back is step zero. Everything else waits.

2. Can you build and run it from a clean machine?

Clone into a fresh environment and follow whatever docs exist. If you can't get a working local build in an afternoon, you have an onboarding problem before you have a code problem. Capture the exact steps as you go — that becomes the README that never existed.

3. Where do the secrets live?

API keys, tokens, and env vars hard-coded in the repo or living only in one person's laptop are a time bomb. Inventory every secret, rotate the ones that walked out the door, and move them into a real secret store.

4. What happens on deploy — and can you roll back?

Trace one change from commit to production. Is there CI? A staging step? A way to revert in 60 seconds when something breaks at 2am? A takeover without a rollback path is how a small fix becomes an outage.

5. What's the blast radius of the data?

Find the database, confirm backups actually run and restore, and check whether personal data is handled sanely. Vibe-coded apps love to log everything and secure nothing.

6. Which parts are load-bearing vs. decorative?

AI-generated code often includes plausible-looking functions that are never called and "working" features held together with copy-paste. Map the real request paths before you trust the file names.

7. Rescue, rebuild, or bring in a lead?

With the above answered, the decision is usually clear: small controllable surface → rescue in place; no control, no tests, unknown data → contain first, rebuild the core; strategically important but under-owned → bring in a fractional lead to stabilize before scaling. Don't let sunk cost pick for you.

Score your own situation (free, no signup)

I built the full version of this into a free browser self-check — it scores your takeover risk across these dimensions and points you to the right next move. Nothing to install, no email required:

👉 https://care.omniai.one/software-takeover/?utm_source=devto&utm_medium=referral&utm_campaign=software_takeover

If you're staring at an inherited or AI-built app right now, do the control check (point 1) first. Most "the code is a mess" emergencies are really "we don't own our own production" emergencies in disguise.

DEV Community: Omni Care