You built your MVP with AI tools — or a tiny team moving at AI speed — and it works. Users use it. Money might even come in. Then an engineer looks under the hood and uses the word "rewrite," and now you can't sleep.
Take a breath. Here's the senior read.
What your AI-built MVP bought you
Everything that matters, actually: proof. Proof people want the thing, proof they'll pay, proof of what they actually use (never what you predicted). You bought it for a fraction of what it cost two years ago, in a fraction of the time. That trade was correct. Anyone sneering at vibe-coded MVPs is missing the point of an MVP.
What it didn't buy you
- A foundation. AI-generated codebases are optimized to work, not to be changed. The first big feature addition is where this bites — everything is subtly coupled to everything.
- Security posture. AI code is confident, plausible, and frequently wrong about auth edge cases, injection, and secrets handling. Assume nothing was hardened until a human verifies it.
- Operational knowledge. When it breaks at 2 a.m., "the AI wrote it" is not a runbook. Someone has to actually understand the system.
- Discrimination between load-bearing and decorative. Human-written codebases have intent baked into their structure. AI codebases have patterns without reasons, which makes every future change slower and scarier.
When the rewrite conversation is real
Rewrite talk is justified when — and only when — you can check several of these boxes:
- Small changes routinely break unrelated features
- No engineer can confidently explain what a core module does
- You're handling money, health, or personal data on unaudited AI code
- Feature velocity has visibly collapsed and refactoring hasn't fixed it
- The stack itself is a dead end (wrong platform, unsupported framework)
Even then: the answer is usually strangle, don't rewrite — build new functionality on a clean foundation, migrate the old piece by piece, keep shipping the whole time. Big-bang rewrites kill more startups than bad code ever has.
When it's noise
Be skeptical of rewrite pressure when it arrives via:
- A new engineer's first week. Every engineer wants to rewrite every codebase they didn't write. This is a law of nature, not an assessment.
- An agency proposing the rewrite they'd get paid for. Obvious conflict, constantly ignored.
- Aesthetic complaints. "This code is ugly" is not a business case. Ugly code that ships features beats beautiful code that's six months away.
- Framework fashion. Migrating because the new thing is popular is how you pay twice to stand still.
What to actually do
- Get an independent read. Someone with no rewrite to sell audits what you have: security, architecture, the honest ceiling. (This is exactly what our free Health Check is — but any senior neutral party works.)
- Harden, don't rebuild. A security pass, tests around the money paths, monitoring, and a deploy pipeline turn a prototype into an operable system for maybe 15% of a rewrite's cost.
- Draw the line for v2 — based on evidence. You now know what users actually do. When you do build the next foundation, you're building from proof, not guesses. That's the luxury your "throwaway" MVP bought you.
The MVP did its job. Don't let anyone — including the voice in your head at 2 a.m. — convince you it was a mistake. Just don't confuse it for the building you'll spend the next decade in.