Two founders, same week.
The first wants to throw away a working product because an engineer he just hired called the codebase "garbage" on day two. The product has paying customers. It is slow and ugly under the hood, but it works, and it makes money every day it stays online.
The second wants to keep a product that loses data. Every few weeks, a background job silently drops records, and the team has learned to just re-run the import and hope nobody notices. She does not want to hear the word rewrite, because the last time someone said it, the company spent four months building nothing else.
Both founders are wrong, not because the answer sits in the middle, but because neither is asking the right question. It is not "rewrite or keep." It is "which parts, in what order, starting where."
The details above are a composite of several companies we have worked with. The pattern is not.
The Real Problem: Nobody Scored the Codebase
Founders usually reach a rewrite decision through a feeling. An engineer winces at the code. A bug takes three days to trace. A demo breaks in front of an investor. The feeling is real, but it is not a plan, and it is not a budget.
There is a well-known 2000 essay, still passed around in engineering circles, arguing that rewriting a working product from scratch is close to the single worst strategic mistake a software company can make. The reasoning holds up: a messy codebase encodes years of small, hard-won fixes for edge cases nobody remembers discovering. Throw it away and you throw those fixes away too, then rediscover most of them the hard way, on a slower timeline, while a competitor keeps shipping.
But that essay assumed a team that understood what it had built. Vibe-coded products break that assumption. Nobody on the team fully understands the code, including whoever prompted it into existence. The "hard-won fixes" argument only protects you if the fixes are actually in there, and in an AI-generated codebase, some of what looks like a fix is a bug wearing a fix's clothes.
So the real question is narrower than "rewrite or keep." It is how much of what you have is genuinely sound, and how much just looks finished. That is answerable, if you score it instead of feeling it.
The Seven-Question Scorecard
We score every codebase we review against seven dimensions, each worth 0, 1, or 2 points. It takes a few hours for a small product, longer for anything with real usage history. You do not need us in the room to run a rough version of it yourself.
| Question | 0 | 1 | 2 | |---|---|---|---| | Data model soundness. Do tables and relationships reflect how the business works? | Duplicated or contradictory, never planned | Workable, with known gaps | Clean, constraints enforced by the database | | Security posture. Can a user reach data or actions that are not theirs? | Untested, or known holes are unfixed | Spot-checked, no known critical holes | Reviewed end to end, enforced at the data layer | | Test coverage. Do you find breakage before a customer does? | No automated tests, every deploy is a guess | Tests on the riskiest paths only | Meaningful coverage, tests run on every change | | Dependency health. Are libraries current, maintained, and swappable? | Outdated or unmaintained, nobody dares touch them | Mostly current, one or two risky pieces | Current and actively maintained | | Ownership of the code. Does anyone actually understand how it works? | No one can explain it without re-reading it | One person understands it, undocumented | Understood by more than one, documented | | Deployability. Can you ship a change and roll it back safely? | Manual, deploys have caused outages before | Scripted but fragile, rollback is improvised | Automated, rollback is a tested step | | Performance headroom. Does it hold up if usage doubles? | Already slow, cause unknown | Fine today, untested for growth | Load-tested, bottlenecks known and planned for |
Add the seven scores together. The total, out of 14, is what decides the path, not the feeling that sent you looking for this article in the first place.
What Your Score Means
12 to 14: keep and harden. The foundation is sound. Whatever prompted the rewrite conversation is a symptom, usually a missing test suite or one security gap, not a reason to start over. Fix the two or three lowest-scoring dimensions and move on.
8 to 11: strangle and replace piece by piece. This is where most vibe-coded products with real customers land. Nothing is broken enough to justify downtime, but enough is shaky that you cannot build the next six months of features on top of it safely. You replace the weakest pieces one at a time, behind the same interface, while the product keeps running.
4 to 7: rewrite the core only. Usually the data model and security posture scored low, the two dimensions hardest to retrofit, while the rest is workable. You rebuild the foundation deliberately and keep whatever surface-level code still works.
0 to 3: full rewrite. Rare, and usually means the product has no real customers yet, or the data loss and security exposure are severe enough that every day it stays live is a liability. Scoring this low with paying customers already on the product is itself the finding.
Most vibe-coded products score in the 8 to 11 range: workable enough to keep running, unsound enough to build on carelessly. That is the range where founders most often pick the expensive option in either direction, an unneeded rewrite or years of quietly patching the same hole.
The Playbook We Use
When a founder brings us a vibe-coded product and the word "rewrite" has already come up, we do not start with an opinion. We start with the scorecard, as part of the technical audit inside our Fractional CTO & Technical Advisory service.
Week 1: score it. We run the seven questions against the actual code, not the founder's description of it, the same gap we cover in our guide to evaluating an AI-built demo. We also check it against the seven most common ways AI-built products fail in production, since most low scores trace back to one of those seven.
Week 2: sequence the strangler plan, if the score calls for one. Named for the way a strangler fig grows around a host tree until the original is no longer load-bearing, the pattern works the same way in software: a thin layer goes in front of the weak part, its replacement is built behind that layer, traffic cuts over once the replacement is proven, and only then does the old code come out. The product never goes offline for a rewrite.
Week 3 and on: fix the highest-leverage dimension first. If security and data model both scored low, security goes first, since it is the one that turns into an incident with users watching.
The cost math is worth doing in the open. At our senior-plus-AI rate of $199 an hour, call it $200 for the arithmetic, a scoped strangler replacement of one weak subsystem runs 60 to 120 hours, so $12,000 to $24,000, spread over weeks while the product keeps making money. A full rewrite of a mid-sized product is more often 400 to 600 hours before feature parity, so $80,000 to $120,000, with the product frozen the whole time. That gap is why the scorecard beats the feeling, and it is the same kind of arithmetic behind our breakdown of what an MVP actually costs in 2026.
The Counterintuitive Part
The cheapest rewrite you will ever do is the one you do before you have customers.
Founders treat the rewrite decision as something that happens later, once the product has proven itself and the debt has become undeniable. By then it is also the most expensive version of the decision: real users depend on uptime, real data has to migrate without loss, and every week spent rebuilding is a week not spent on whatever made the product worth keeping.
If your scorecard total is already low and you do not yet have paying customers, that is not bad news. It is the one window where a full rewrite costs the least it will ever cost. The moment revenue depends on the current version, the strangler pattern stops being optional. This is also where what senior oversight actually means once AI is writing the code matters most: someone has to decide, with the scorecard in hand, before the decision gets made by default.
What to Do Tomorrow
-
Run the scorecard yourself, even roughly. You do not need to be technical to ask the seven questions and get honest answers from whoever built the product. A score under 8 with real customers already on it means get experienced outside eyes on it soon, not the cheapest ones.
-
Write down what "strangle" would mean for your weakest dimension. Sketch, in a paragraph, what rebuilding just that piece behind the existing interface would look like. If you cannot picture it, that is worth a conversation with someone who has done it before.
-
Stop letting the loudest opinion decide. An engineer calling the code garbage and a founder flinching at the word rewrite are both instincts, not plans. The scorecard is slower to invoke and faster to trust.
Frequently Asked Questions
Should I rewrite my MVP or keep improving it?
For most vibe-coded products with real usage, the answer is neither in its pure form. Score the seven dimensions above. A total of 8 or higher usually means you keep the product and replace the weakest parts individually. A total under 8, especially with customers already depending on it, is when a scoped rewrite of the core is worth the cost.
How do I know if my codebase has too much technical debt to fix?
Technical debt itself is rarely the deciding factor. Data model soundness and security posture are. If those two score 0 or 1, the debt is structural, not cosmetic, and it will keep costing you until you address the foundation directly.
What is the strangler pattern and does it work for a small startup?
It replaces weak parts of a system gradually, behind the same interface, without taking the product offline or freezing feature work. It suits small teams well, because it never requires everyone to stop and rebuild at once.
If you are staring at a vibe-coded product and cannot tell whether to rewrite it, keep it, or replace it in pieces, schedule a free diagnostic call. We will score it with you.