Article
Rebuild or fix your vibe-coded app? How to decide with numbers
Published on
At some point, everyone who built an app with AI — Lovable, Bolt, Cursor, Claude Code, Codex — shows it to a developer and hears some version of "this is a mess, it needs to be rebuilt from scratch."
Sometimes that is true. Usually it is not. And it matters, because the two paths differ by months and thousands of euros, and because "rebuild it" is also what a developer says when reading someone else's code — or an AI's — is less comfortable than starting over. Rewrites proposed for the rewriter's comfort ship late and arrive missing the details that made the old version work.
Here is the decision, made with numbers instead of taste.
What "messy code" actually costs (and what it doesn't)
First, a reframe: spaghetti is not a reason to rebuild. Duplicated functions, 500-line files, three different patterns for the same thing — AI-generated codebases are full of this, and all of it is repairable in place, area by area, while the app keeps running.
The code being ugly costs you nothing directly. What costs you is:
- Unpredictability: you cannot tell what a change will break, so every change takes three attempts.
- Blocked features: something you need (roles, payments, a second user type) fights the current structure instead of fitting it.
- Risk: security holes, no backups, no way back when a deploy goes wrong.
All three are fixable without a rewrite. The question is only ever whether fixing costs less than replacing.
The four questions that decide it
1. Does it work today? If real users are using it — even a handful — the app embodies decisions and behaviours nobody wrote down, and users have built habits around them (including around its bugs). A rewrite silently discards that knowledge; a repair preserves it. Working software, however ugly, is evidence. Bias strongly toward fixing.
2. Is the stack dead or alive? AI tools overwhelmingly generate React, Next.js, Supabase, Node — current, well-supported stacks. That removes the one classic justification for rewrites (an unsupported platform with no upgrade path). If your app is on a living stack, the rewrite argument gets much weaker.
3. Is the damage local or everywhere? Usually the unfixable mess is concentrated — the payments module, the permissions logic — while the rest is merely untidy. That points to a partial rebuild: replace the rotten area, keep everything else. Partial rebuilds capture most of a rewrite's benefit at a fraction of the cost.
4. What do the two numbers actually say? Get a concrete quote for "fix what blocks us for the next year" and one for "rebuild to feature parity" — counting every feature the current app has, including the small ones you have stopped noticing. Rebuild estimates routinely miss those, which is why rebuilds run late. When the honest fix number clearly exceeds the honest rebuild number, rebuild. That is rare.
The pattern that works: freeze, then repair by area
The repair path, done properly, looks like this: put the code in a real repository, pin down the current behaviour (including the quirks users rely on), then fix in shippable slices — security and deploys first, the blocking bugs second, structure third — so the app never stops working while it gets better. This is how stalled software projects have always been rescued; AI-generated apps are just the newest arrivals. If yours is not even deployed yet, start with why it works in preview but not in production.
Getting the numbers without betting on an opinion
Everything above depends on someone actually reading your code before pronouncing a verdict. That is what our vibe code rescue audit is: 450 EUR, 48 working hours, a written report of what works, what is broken, what is dangerous, and the fix-vs-rebuild numbers for your specific app — with the rebuild recommended only when we can show you it is cheaper, in writing. If you continue into the rescue (typically 1,500–6,000 EUR, fixed scope), the audit fee is deducted.
Whichever way you decide, run the security checklist first. It is the one part of an AI-built app where "later" is the expensive answer.