.webp)
A CTO we spoke to last month had an MVP that hit product-market fit 14 months earlier and grown from 2 engineers to 9. His team was shipping half as fast as they did in year one. Every new hire took 6 weeks to their first meaningful commit. His CEO wanted to fundraise. His engineering team wanted to rewrite the whole thing in Rust. His investors were sceptical.
That conversation is happening across UK and US SaaS startups right now. The MVP that got you to product-market fit was designed for validation, not scale. The technical debt is real. The rewrite temptation is stronger.
This article is for the CTOs, founders, and VP Engineerings in that conversation. Seven signals it is actually time. Three paths and their real costs. The playbook that ships. And the second-system syndrome that has been killing rewrites since 1975.
The 7 Signals Your MVP Needs a Rewrite
Not every slow-shipping team needs a rewrite. Watch for these specific signals.
1. New feature velocity dropped 50 percent-plus from year 1 to year 2. Track story points, PRs merged, or feature releases. Year 1 baseline versus current pace. Below 50 percent is a warning; below 30 percent is a crisis.
2. Onboarding a new senior engineer takes 4 to 8 weeks to first meaningful contribution. A senior engineer joining a healthy codebase should be shipping within 1 to 2 weeks. 4+ weeks means the codebase is undocumented or inconsistent enough that experience does not translate.
3. Every deploy has 20 percent-plus chance of production incident. Track incident rate per deploy. Above 20 percent means the coupling between components is too tight to change safely.
4. Test coverage below 40 percent and adding tests is prohibitively expensive. Low coverage is common in MVPs. What matters is whether you can add tests cheaply. If test infrastructure requires rewriting before tests can be added meaningfully, that is signal.
5. Foundational technology deprecated or approaching end-of-life. Framework unmaintained, database version unsupported, language version dropped. This forces the decision on timeline.
6. Multiple critical paths blocked by shared bottleneck code nobody wants to touch. The one file that touches billing, auth, and reporting that everyone avoids. When 3+ critical initiatives block on it, that is signal.
7. Team of 6+ engineers cannot ship in parallel due to monolithic architecture. Merge conflicts, integration delays, deployment coordination overhead. Small teams tolerate this; 6+ engineers do not.
Three of these together with no realistic refactor path is meaningful. Four or more is close to conclusive. The GitHub State of the Octoverse publishes annual developer productivity data that helps benchmark your team's velocity against comparable stages.
Rewrite vs Refactor: Cost and Time Reality
Three paths with distinct cost profiles.
Refactor. Change internal structure without changing external behaviour. Improve testability, extract components, replace technologies incrementally. Cost £30k to £150k over 3 to 6 months. No user-visible change. Preserves domain knowledge embedded in existing code. Lowest risk.
Full rewrite. Start again with new architecture, new stack, new codebase. Migrate users at cutover. Cost £250k to £800k over 6 to 15 months. Highest risk. Chance to fix architectural mistakes that cannot be refactored.
Strangler pattern (gradual rewrite). Build new system alongside old. Route traffic gradually. Old system strangled by new functionality over time. Cost £200k to £600k over 9 to 18 months. Middle risk. Original system keeps running as safety net.
Martin Fowler's bliki on software patterns covers the strangler pattern (originally strangler fig application) as the default recommendation for most teams contemplating a rewrite. The pattern preserves optionality; if the rewrite goes wrong, you still have the working original.
Most teams should try refactor first. Real refactoring done properly recovers 60 to 80 percent of the value of a full rewrite at 20 to 30 percent of the cost and risk. Full rewrite is the option when the refactor path is genuinely blocked by fundamental architectural mistakes.
The Rewrite Playbook That Works
Six principles from teams that shipped successful rewrites.
Keep the MVP running as system of record. Original is the truth until every user is migrated. No exceptions.
Rewrite behind feature flags. Every new module goes into production dark, then rolled out gradually. Full rollout is the last step, not the first.
Migrate traffic in stages. 1 percent, 5 percent, 20 percent, 50 percent, 100 percent. Each stage has clear success criteria before advancing.
Run data migration in parallel with app migration. Not sequentially. Dual-write to both systems during transition. Reconcile daily.
Kill switches at every boundary. Any component can fall back to the old system in under 5 minutes if something goes wrong.
Deprecation timeline with hard dates. Old system has a shutdown date. If the date slips more than once, the rewrite is failing and needs re-scoping. See our earlier post on enterprise software modernisation cost for the larger-scale version of this playbook.
Real 2026 Cost Bands
Refactor. £30k to £150k over 3 to 6 months. Small team (2 to 4 engineers) working alongside feature development. No user-visible change.
Strangler pattern (gradual rewrite). £200k to £600k over 9 to 18 months. Larger team (3 to 6 engineers) plus product manager plus lead engineer. Original keeps running throughout.
Full rewrite. £250k to £800k over 6 to 15 months. Larger team (4 to 8 engineers) plus PM plus tech lead. Original system running until cutover.
Enterprise-scale rewrite (multi-team SaaS above £5m ARR). £600k to £2m over 12 to 24 months. Multiple teams, dedicated migration lead, complex data and integration migration.
Add 20 to 30 percent for post-migration stabilisation. Any rewrite budgeted without stabilisation contingency ships late or ships broken.
What We Learned Rewriting Systems Like TrackVid
TrackVid is our video proof and claim management platform. It has been through architectural evolution. Two lessons transfer directly.
Strangler pattern beats big-bang rewrite by orders of magnitude in real outcomes. When we needed to change TrackVid's multi-seller architecture, we did it behind feature flags with per-seller rollout. Original tenant isolation stayed intact during migration. Any issue could fall back in minutes. Same principle applies to most MVP rewrites: gradual replacement preserves value while enabling change.
Domain knowledge is the most underestimated asset. The MVP encodes hard-won knowledge about the problem domain (edge cases, user preferences, business rules) that nobody remembered to document. Full rewrites throw this away and rediscover it painfully. Refactor and strangler patterns preserve it.
You can see TrackVid at our portfolio. If you want a candid conversation about your specific rewrite decision, book a rewrite discovery call with WhiteStone.
Common Failure Modes: Second System Syndrome
Fred Brooks named this in 1975. The tendency to over-engineer the rewrite with every feature the original lacked and every architectural pattern the team wanted to use. The result: system ships late, contains new bugs, disappoints, and destroys team morale.
Three specific failure patterns.
Scope creep during rewrite. Team decides to also add multi-tenancy, event sourcing, and GraphQL. What was a 9-month rewrite becomes a 24-month rewrite that ships less than the original had.
Rewriting in the newest technology because the team wants to. Rust because engineers wanted to learn Rust. Kubernetes because Kubernetes is cool. Technology choices should serve the business, not resume-drive engineers.
Underestimating parity work. Recreating existing functionality takes 60 to 80 percent of the total rewrite effort. Only 20 to 40 percent is new capability. Teams underestimate parity work by 2x consistently.
Ruthless scope discipline is the difference between a rewrite that ships and a rewrite that kills the company.
Frequently Asked Questions
How do I know if my MVP has too much technical debt?
Track seven signals: velocity drop 50 percent+ year-over-year, senior engineer onboarding 4-8 weeks, 20 percent+ incident rate per deploy, test coverage below 40 percent with expensive test infrastructure, deprecated foundational technology, blocked critical paths on untouchable shared code, team of 6+ cannot parallelise. Three of these together with no refactor path is meaningful.
Is it cheaper to rewrite or refactor an MVP?
Refactor is typically 20-30 percent of full rewrite cost with 60-80 percent of the value. £30k-£150k over 3-6 months for refactor versus £250k-£800k over 6-15 months for full rewrite. Try refactor first. Only rewrite when refactor path is genuinely blocked.
How long does a full MVP rewrite take?
Full rewrite: 6-15 months for typical SaaS MVP with 4-8 engineers. Strangler pattern rewrite: 9-18 months with more gradual delivery. Enterprise scale: 12-24 months. Add 20-30 percent for post-migration stabilisation. Rewrites budgeted without stabilisation contingency ship late.
Should we rewrite in the same language or switch?
Same language is faster and lower risk. Different language should have a specific technical justification (performance, ecosystem, hiring). Engineers wanting to learn a new language is not a technical justification. Business needs plus talent market plus operational cost together might be.
How do we avoid second-system syndrome?
Ruthless scope discipline. Only recreate existing capability plus one specific improvement (better architecture, better testability, or removed technical debt). Do not add new features during rewrite. Do not adopt new architectural patterns beyond what solves the specific problem. Deprecation date hard-set from kickoff.
The One Thing to Remember
Most MVPs that appear to need a full rewrite actually need a disciplined refactor. Real refactoring recovers most of the value at a fraction of the cost and risk. The teams that succeed with rewrites are the ones that ruthlessly limited scope to fixing what was actually broken. The teams that failed rewrites tried to build the perfect system in one go and shipped nothing useful.
If you want a candid conversation about your specific decision, browse our custom software development services or come to the call.
