The burn-it-down vs iterate call — backed by evidence.
7-factor diagnostic, strangler-fig vs greenfield analysis, cost-time-risk modeling. Defensible recommendation. Fixed-scope deliverable.
Who this is for
CTO debating burn-it-down-and-rebuild vs incremental refactor where the team is split, the board is impatient, and either path carries huge risk if chosen wrong.
The pain today
- Team split — senior engineers want rewrite, junior want refactor
- Board pressure for 'clean' technical story before Series B
- Codebase clearly painful but incremental fixes seeming endless
- Rewrite risk (6-month no-feature blackout) vs refactor risk (endless slog)
- No senior technical voice outside the team to break the deadlock
The outcome you get
- 7-factor diagnostic framework applied to your specific situation
- Defensible recommendation (rewrite, strangler-fig, or refactor) with evidence
- Cost/time/risk modeling for each path
- Migration plan if rewrite or strangler is the answer
- Executive narrative for board conversations
The 7 factors I weigh
Rewrite vs refactor isn't instinct — it's a multi-variable decision. Factor 1: codebase age (>7 years often favors rewrite, <5 years favors refactor). Factor 2: test coverage (low coverage makes refactor dangerous). Factor 3: architectural clarity (muddled boundaries favor rewrite). Factor 4: team size and tenure (small tenured team can refactor, rotating team can't). Factor 5: business velocity pressure (high pressure forces incremental). Factor 6: technology freshness (stack 10 years out of date effectively requires rewrite). Factor 7: cost of being wrong (high-stakes systems favor conservative incremental). Score each 1–5 with evidence; the overall picture usually becomes clear when all seven are in front of you.
Strangler fig vs greenfield
Two rewrite flavors. Greenfield: new codebase from scratch, migrate data when complete, switch traffic at go-live. Risky, 6+ month blackout, big-bang cutover. Strangler fig: new codebase stood up alongside old, traffic routed endpoint-by-endpoint, old retired piece by piece. Slower to complete but features ship throughout, risk is distributed across many small cutovers, business pressure manageable. For 90% of rewrite cases, strangler fig is the right answer — greenfield is right only when the old codebase cannot be stood alongside the new (incompatible data model, fundamental platform migration). I argue for strangler by default and only recommend greenfield when specific technical factors force it.
Cost/time/risk modeling
Each path has a model. Rewrite: 3–18 months depending on scope, $X engineer-cost, feature blackout of Y weeks in the middle (if not strangler). Refactor: 6–24 months of parallel work at 20–30% capacity, lower total cost, no feature blackout, higher risk of never-finishing. Strangler: 9–18 months, middle cost, middle risk, distributed over the timeline. I build a specific model for your context with evidence for each number (team velocity data, existing feature commitments, funding runway). The model makes the trade-offs legible to the board — engineering opinions about clean code become business decisions about capacity and risk.
Case study: Imohub rebuild that paid for itself
Imóveis SC (now Imohub) was a legacy real estate portal where refactor was evaluated and rejected in favor of rebuild. The rebuild (Next.js + Laravel + Meilisearch + MongoDB + AWS) paid back in infrastructure savings alone: 70% infra cost reduction. Query response under 0.5s for 120k+ properties. Top 3 Google rankings. Development velocity lifted after the cutover because the new stack's primitives matched the product's needs. The decision required evidence — architectural review showed that the legacy stack's limitations were fundamental, not incremental. Not every rewrite pays back this clearly; discipline in the diagnostic is how you avoid the ones that don't.
Fixed-scope deliverable
Rewrite-vs-refactor decision work fits the Fractional CTO service, delivered as a 2–3 week fixed-scope engagement at the $4,500/mo tier (pro-rated if needed). Deliverable: written diagnostic report with the 7-factor scoring, cost/time/risk models for each path, defensible recommendation, and migration plan if rewrite or strangler is the answer. Follow-up engagement (implementation oversight) is optional — many founders take the recommendation and execute with internal team. 14-day money-back on the diagnostic. Work Made for Hire on all written deliverables. Executive narrative included so you can present the decision cleanly to board and investors.
When the answer is 'neither'
Sometimes the diagnostic reveals that the technical situation isn't the real problem. Team turnover is. Product-market fit isn't. Hiring process is. In those cases, rewrite or refactor won't solve the actual issue — different work will. I say so when the diagnostic points there. It's not the expected answer, but it's the honest one. A company shouldn't rewrite its codebase to solve a hiring problem; it should fix hiring. A company shouldn't refactor indefinitely to avoid product pivots; it should pivot. Honesty about what's actually broken is more valuable than an engineering-shaped recommendation that doesn't solve the root issue.
Recent proof
A comparable engagement, delivered and documented.
Rebuilt a real estate portal at a fraction of the cost
Rebuilt Imóveis SC's real estate portal as ImoHub — a faster, more scalable successor — handling 120k+ properties with sub-second search and drastically reduced AWS costs.
Frequently asked questions
The questions prospects ask before they book.
- How long does the diagnostic take?
- 2–3 weeks: week 1 codebase and team access, week 2 7-factor scoring and model building, week 3 recommendation drafting and review meeting. If access is limited or team interviews are delayed, timeline extends by 1 week.
- What if the team disagrees with the recommendation?
- Team input is central to the diagnostic (interviews feed the 7-factor scores). If the team disagrees with the final recommendation, I explain the scoring that led there and address specific concerns. Unresolved disagreement is rare; when it happens, the founder makes the final call with full information.
- Do you oversee the rewrite or refactor after the decision?
- Optional. Many founders take the recommendation and execute with internal team. Others keep me on retainer for implementation oversight — reviewing key architectural decisions, unblocking when stuck, mentoring team leads. Your call based on team capability and budget.
- What's the success rate of rewrites you've recommended?
- Of rewrites I've recommended (a small fraction of overall diagnostics — I usually recommend refactor or strangler), the track record is good because the diagnostic is conservative. I only recommend rewrite when evidence strongly supports it. Imohub is the clearest example — 70% infra cost reduction, clear payback.
- Can you present the recommendation to the board?
- Yes. Executive narrative is part of the deliverable, and I can join a board meeting as technical spokesperson if founder wants external voice for credibility. 60-minute board session typically — presentation plus Q&A. Included at the Fractional tier, available as a $1,500 add-on at the Advisory tier.
Ready to start?
Tell me what you need in 60 seconds. Tailored proposal in your inbox within 6 hours.