Founders call us saying "we need to rebuild the whole thing." They're usually right that something is wrong and usually wrong about the fix. A full replatform is occasionally the answer and far more often the most expensive way to avoid a cheaper one. Here's how we tell them apart.
When a founder asks for a replatform, what they usually need
"Replatform" is what a founder says when the product has stopped feeling trustworthy — features take too long, bugs recur, nobody's confident touching the code. The instinct is clean-slate: start over, do it right this time. The instinct is almost always more emotional than technical. What they need is for the product to become reliable and extensible. A rewrite is one way to get there. It's rarely the cheapest or the safest.
The full rewrite has a failure mode that's been documented for decades and got louder in 2026: it takes longer than estimated, it silently re-introduces the business-logic bugs that were hidden in the old code (because the old code was the only place those rules were written down), and it leaves the existing product frozen and unmaintained for the months it takes (Autonoma). For a product with real users, that's a large bet to place in order to feel decisive.
| Full rewrite | Remediation | |
|---|---|---|
| Speed to value | Slow — product frozen for months | Incremental, product stays live |
| Hidden business logic | Often lost, then re-broken | Preserved and documented by tests |
| Risk | High, well-documented failure mode | Lower, reversible step by step |
| When it's right | Architecture is fundamentally wrong | Most cases with paying users |
Remediation means: build a test suite that documents current behaviour, then improve the code incrementally while the product keeps running. Slower to feel satisfying, faster to be safe.
Before anyone says "rewrite," we ask:
- Is the architecture wrong, or is the code messy? (Messy code gets refactored. Wrong architecture gets replaced.)
- What specifically is slow — the whole system, or three endpoints? (Usually three.)
- Do you have tests that capture what the product currently does? (If not, a rewrite will lose behaviour you didn't know you depended on.)
- Can the business survive months of frozen feature work? (If not, the rewrite decision is already made for you.)
Sometimes it genuinely is: the data model can't represent what the business now needs, a core dependency is end-of-life, the security model is unsalvageable, or the architecture blocks the next year of roadmap no matter how you refactor. In those cases we replatform deliberately — strangler-pattern, behaviour-locked by tests, shipping in slices, never a big-bang cutover.
The honest answer to "should we rebuild it?" is usually "no — but here are the three things that made you ask."