The prototype took a weekend. The demo landed, the room nodded, and the thing you built with a few well-aimed prompts looked like a product. Then real users arrived, and the cracks showed up in places no demo ever tests. Vibe-coded apps feel fast until the first production constraint arrives, and then the speed you bought turns into the bill you owe.
That speed was real. You greenlit AI prototyping, shipped something impressive in days instead of quarters, and the bet paid off where it was supposed to: getting to a working idea fast. The problem isn't the AI, and it isn't you. It's the delivery layer the demo let you skip. This article names the three ways vibe-coded apps die in production, then the three disciplines that change the outcome.
The demo was real. So is the gap
Vibe coding is the practice Andrej Karpathy named in early 2025: you describe what you want in natural language, an AI model writes the code, and you accept the output by feel rather than reading every line. It is genuinely good at producing something that runs. What it does not produce, by default, is something that survives contact with real traffic, real attackers, and real change requests.
That gap between "it runs" and "it holds" is where most of the cost lives. A demo proves the happy path works once, for one user, under conditions you controlled. Production is the opposite of all three: unexpected inputs, concurrent load, and people actively trying to break things. The code can be identical and the outcome completely different.
Here is the contrast most teams discover the hard way.
| Concern | Demo mode | Production reality |
|---|---|---|
| Authentication | A login screen that works for you | Session handling, token expiry, password reset, account lockout |
| Error handling | Happy path only | Graceful failures, retries, user-facing error states, logging |
| Cost | One user, one request | Connection pools, rate limits, and a cloud bill that scales with abuse |
| Data security | "It's behind a login" | Authorization checks on every record, not just a login wall |
| Maintainability | You remember how it works | A second engineer can read, extend, and audit it safely |
None of this is exotic. It is the ordinary work of shipping software, and it is exactly the part an AI model skips when it optimizes for code that looks finished.
Failure mode 1: Silent production failures
The most dangerous production failures are the quiet ones. The app doesn't crash. It just stops doing the thing it was supposed to do, and nobody notices until a customer complains or a number looks wrong.
You have seen the shapes these take:
- A webhook that processed payments fine in testing silently stops firing, and orders pile up unconfirmed.
- A loading spinner that never resolves because an API call failed and nothing caught the error.
- A payment that charges the customer's card but never records the transaction, because the success handler assumed the network never fails.
- A $400 surprise cloud bill at the end of the month from database connections that were opened and never closed.
Every one of these passed the demo. The webhook fired once when you tested it. The spinner resolved when the network was fast and local. The payment recorded when you ran it yourself. AI coding tools are very good at making the first successful run happen, and that is the trap, because production is not about the first run. It is about the ten-thousandth run, the one that hits a timeout, a malformed input, or a rate limit.
The cost to you is rarely a dramatic outage. It is slow leakage: revenue that quietly fails to land, customers who churn without telling you why, and a support queue full of problems you can't reproduce. By the time a silent failure becomes visible, it has usually been bleeding for weeks.
Failure mode 2: The security and authorization gap
AI generates authentication that looks complete and often isn't. The login page works. Users can sign up and sign in. And underneath, the check that should stop one user from reading another user's data was never written, because nobody asked for it in plain language and the model had no reason to add it.
The clearest recent proof is the Lovable breach. Security researchers documented a Broken Object Level Authorization (BOLA) flaw in apps built on the Lovable platform, where the system verified who you were but never checked what you were allowed to see. Per The Register (2026), the flaw was live from a February 2026 backend change until its public disclosure on April 20, 2026, and sat unpatched for 48 days after a private report, letting any free-tier account read other projects' source code, chat histories, and database credentials. BOLA is the gap between authentication, which confirms your identity, and authorization, which confirms your permission. Vibe-coded apps routinely get the first and miss the second.
For an executive, this is not an abstract engineering concern. It is the failure mode that turns into a breach disclosure, a hard conversation with your biggest customer, and a due-diligence finding that stalls a funding round or an acquisition. Authentication failures are embarrassing. Authorization failures are existential, because they expose other people's data and the liability that comes with it. An AI model will not threat-model your data-access layer unless someone makes it the explicit job, and "make the login work" is not that job.
Failure mode 3: Architectural drift and black-box code
The first two failures are about what the code does. The third is about what the code is. When you build feature by feature through prompts, each addition is locally reasonable and globally unaccountable. There is no owned architecture, just an accumulating pile of decisions no single person made on purpose.
The symptoms compound over time:
- Hallucinated dependencies: packages the model invented or pulled in that don't do what the code assumes.
- Inconsistent patterns: three different ways of talking to the database, because three different prompts produced three different approaches.
- Logic the team can't extend, because changing one thing breaks two others in ways nobody can predict.
- Code that is "not investor-ready," because any technical due-diligence reviewer will open it, read for ten minutes, and flag it as a liability.
The endgame is an app you can't safely change. Every new feature is a gamble, every bug fix risks a regression, and the people who could help you are reluctant to touch a system they can't reason about. The speed that got you to a demo has quietly become the thing slowing you down, because you now spend more time being careful around the code than building on top of it. This is the doom loop teams describe: prompt a fix, break something else, prompt a fix for that, repeat.
What we do instead: three delivery disciplines
None of this means stop vibe coding. The fast prototype is a real advantage and you should keep it. It means adding the layer the demo let you skip: turning a thing that runs into a thing that holds. Three disciplines do that work, and each one answers a failure mode above directly.
| Failure mode | Delivery discipline | What "done" looks like |
|---|---|---|
| Silent production failures | Production-readiness as definition of done | Error handling, health checks, logging, rate limits, and cost guards specified before code is accepted |
| Security and authorization gap | Human-verified security and auth | Authorization tested on every data path, billing and PII paths independently reviewed |
| Architectural drift | Human architecture and scope control | An engineer owns the architecture, scope is deliberate, features ship without regressions |
Discipline 1: Production-readiness as definition of done
Production-readiness is not a phase you reach at the end. It is part of what "done" means for every feature, written down before the code is accepted. That list is concrete: error handling on every external call, health checks that tell you when something is wrong, structured logging you can search, rate limiting so one bad actor can't take you down, and cost guards so a runaway process can't quietly drain your budget.
The discipline is making this the standard the work is measured against, not a cleanup task you hope to get to. In practice the first change is adding the production-readiness list to the same pull request that defines the feature, so it is reviewed before merge, not after launch. When "done" includes graceful failure, the silent production failures stop being surprises, because you designed for the ten-thousandth run from the start.
Discipline 2: Human-verified security and auth
Authentication is what an AI model gives you for free. Authorization is what a human has to verify on purpose. The discipline is to threat-model the data-access layer explicitly: for every record a user can request, confirm the code checks that this user is allowed to see this record, not just that they are logged in.
Anything touching billing, payments, or personal data gets an independent review by someone who did not write it. Testing authorization is different from testing authentication, and it is the test most vibe-coded apps never run. Doing it before real users arrive is the difference between a finding in a review and a breach in the news.
Discipline 3: Human architecture and scope control
Someone has to own the architecture on purpose. That means a deliberate set of decisions about how the system is structured, made by an engineer who can defend them, rather than emerging by accident from a sequence of prompts. It also means scope control: shipping a defined set of features without letting the build sprawl into territory nobody designed for.
This is where disciplined delivery shows its difference most clearly. In our own delivery work, we have shipped a defined scope of 22 features into production without architectural drift, because the architecture was owned and the scope was held, not because the team typed faster. The contrast with a drifting vibe-coded codebase is not subtle. One is a system an engineer can extend with confidence. The other is a black box everyone is afraid to touch.
If the honest blocker is that your team doesn't have the engineering bandwidth to harden the app yourselves, that is a staffing gap, not a dead end. An embedded agentic team can own the architecture and the hardening alongside your people. And if you would rather pressure-test where you stand before committing to anything, an AI Readiness Snapshot is a free 30-minute call to do exactly that.
Proof: 22 features, zero drift
The disciplines above are not theory. The clearest way to see the contrast is to put a disciplined delivery next to the failure modes that open this article.
On a recent build, our team shipped 22 features into production with zero architectural drift and no production regressions. Every feature met a production-readiness definition of done before it was accepted. The authorization layer was tested independently of the login flow. The architecture was owned by an engineer who could explain every decision, and scope was held deliberately so the codebase never sprawled into the black-box state that makes an app unmaintainable.
That is the same number of features a vibe-coding sprint might claim to produce in a fraction of the time. The difference is what arrives in production: not 22 features that demo well and break under load, but 22 features that hold. Fast prototyping and durable delivery are not opposites. The first gets you to a working idea. The second is what makes it a business asset instead of a liability.
How to tell if your app is actually production-ready
You don't need an audit to get an honest first read. Run your app against this checklist and count the yeses.
- Does every external call (API, database, payment) have error handling, or does a failure leave the user stuck?
- Have you tested authorization, not just authentication, by trying to access another user's data as a normal logged-in user?
- Does one engineer understand and own the architecture well enough to explain it to a stranger?
- Are there cost guards and rate limits, or could a single abusive user spike your cloud bill?
- Do you have logging good enough to diagnose a problem you can't reproduce locally?
- If your most experienced developer left tomorrow, could someone else safely extend this code?
If you answered "no" to two or more, your app is in the gap between demo and production. That is not a verdict on the work. It is a map of what the last 20% actually contains, and every "no" is a specific, fixable thing rather than a vague worry.
You shipped fast. Now ship durable
Moving fast was the right instinct, and the speed you got from AI prototyping was not an illusion. The next move is to add the delivery discipline that turns a fast prototype into software you can run, defend, and build on. The failure modes are predictable. So are the disciplines that prevent them.
Book a Discovery Sprint - a focused one-week engagement that audits your vibe-coded app against the failure modes above and hands you a concrete roadmap to production-ready, owned by engineers who do this for a living.
