AI · JUNE 29, 2026
Your vibe-coded MVP just got users. Here is what breaks first.
You built an MVP with AI in a weekend. Now it has real users, and it is starting to break. Here is the honest harden-or-rebuild decision, and what fails first.
David Marin · 5 min read
Contents
You described an app to an AI tool over a weekend, and it built one. It looked good, you put it in front of people, and some of them stayed. That is not luck. You found a real problem and shipped something people use, which is the hard part, and you did it without hiring anyone. The mistake is treating what comes next as a betrayal. AI makes it easy to build something nice. It does not make it easy to keep that thing standing once real users lean on it.
This is the moment a lot of founders panic and ask the wrong question: rebuild the whole thing, or limp along? Almost always there is a calmer, cheaper answer in between. But to get to it you have to know what actually breaks.
What breaks first
The features you can see are usually fine. A login form renders, a dashboard loads, a record saves. What breaks is the part the demo never tested, because a demo runs the happy path once and a real user runs every path at once.
- Authorization, not authentication. The login works. What is missing is the check on the server that you are allowed to see this record. Vibe-coded apps routinely gate the UI ("hide the admin button") without gating the API, so anyone who guesses a URL or edits a request sees everyone's data. This is the failure that turns into a headline.
- The data model. A schema built to make the demo work is shaped for one user doing one thing. It has no constraints, no indexes, and assumptions that fall apart the moment two users act at once or a table grows past a few thousand rows.
- Error handling. The generated code handles the case it was shown. The external API timing out, the payment that half-completes, the upload that fails midway: those paths were never written, so they fail silently and you find out from a confused user, not a log.
- Cost and rate limits. If the app calls an AI model, there is often no cap and no caching. A retry loop that storms a provider, or one viral day, arrives as a bill.
None of these are visible in a demo. All of them are visible to users. That gap is the whole problem, and it is why "it worked when I built it" and "it is breaking now" are both true.
| What the demo runs | What real users hit | |
|---|---|---|
| Authorization | UI hides the button | Server must check every record |
| Data model | One user, one happy path | Concurrency, scale, constraints |
| Error handling | The path you showed | Timeouts, partial failures, retries |
| Cost | A few model calls | Caps, caching, rate limits |
What the demo runs
- Authorization
- UI hides the button
- Data model
- One user, one happy path
- Error handling
- The path you showed
- Cost
- A few model calls
What real users hit
- Authorization
- Server must check every record
- Data model
- Concurrency, scale, constraints
- Error handling
- Timeouts, partial failures, retries
- Cost
- Caps, caching, rate limits
The demo runs one path once. Production runs every path at once.
Harden or rebuild?
The instinct after the first incident is to rewrite from scratch. Usually that is the expensive choice. A rewrite throws away the one thing the MVP earned you, which is proof of what users actually do, and it spends months rebuilding features that already worked while you stop shipping. The question is not "is the code perfect," it is "is the foundation sound enough to build on."
Should you harden the MVP or rebuild it?
- The core works and users like it; the problems are auth, data, and error handling bolted on late→ Harden it (start here)
- The data model is fundamentally wrong for what the product became, and everything depends on it→ Rebuild the data layer, keep the rest
- No one understands how it works, there are no tests, and every change breaks two things→ Audit first, then decide one module at a time
What "harden" actually means
Hardening is not glamorous and it is not a rewrite. It is finding the load-bearing risks and fixing them in priority order while the product keeps running. Add real authorization checks on the server. Put constraints and indexes on the data model before it grows further. Wrap the external calls that fail silently. Cap and cache the model calls. Add enough observability that the next problem shows up in a log before it shows up in your inbox. Each fix is small. Done in the right order, they move you from "breaks under load" to "boring and reliable" without a single month spent not shipping.
The trap on the other side is treating hardening as endless refactoring. You are not making the code beautiful. You are pricing the risks and retiring the ones that change whether the product survives contact with users. That is the same discipline as a technical due diligence audit, pointed at your own product instead of an acquisition.
When a rebuild is the cheaper option
Sometimes the honest answer is rebuild, and pretending otherwise costs more. The clearest signal is the data model. If the shape of the data is wrong for what the product turned out to be, and every feature is built on that shape, patching around it gets more expensive every week. A focused rebuild of the data layer, keeping the UI and the validated flows, is often the real move. A full ground-up rewrite is rare, and it is justified mainly when no one can safely change the code at all: no tests, no documentation, original author gone, every edit breaking something unrelated. At that point you are maintaining legacy code you happen to have written last month.
The first move is an audit, not a decision
You cannot choose between harden and rebuild from anxiety. You choose from a map. Before we touch a vibe-coded app, we run an intake audit: what the code actually does, where the real risks are, and which ones change the decision. The output is a ranked list, each item with a severity and a rough cost to fix, so the harden-or-rebuild call is made on evidence instead of a bad week. We wrote up the specific failure patterns we keep finding in auditing AI-generated code.
From panic to plan
- 01Audit the codeWhat it does, where the real risks are.
- 02Rank by severity and costA ranked list, not a vibe.
- 03Decide: harden or rebuildFrom the map, not a bad week.
- 04Harden in order, keep shippingSmall fixes, no month offline.
If your AI-built MVP just found users and started creaking, that is a good problem, and it has a calm answer. Get a read before you decide: try the MVP estimator to scope the work, or book a call and we will tell you honestly whether you should harden it or rebuild, including when the answer is "leave it alone for now."
Terms in this article