7-factor diagnostic, strangler-fig vs greenfield modeling, cost/time/risk per path. One defensible recommendation. Fixed-scope deliverable.
- Audit
- Architect
- Scale
monthly retainer
Who this is for
You're a CTO or technical founder staring at a codebase that's slowing every sprint down. The senior engineers want to burn it down and start clean. The junior engineers are terrified. The board wants a tidy technical story before the next funding round. And you know that picking the wrong path — rewrite or refactor — carries real consequences either way. That's the situation I work in.
The pain today
- Team split: senior engineers push for rewrite, junior engineers fear the transition
- Board pressure for a clean technical narrative before Series B or C
- Incremental fixes feel endless but a rewrite means 6+ months with no new features
- No neutral senior voice outside the team to break the deadlock
- Previous refactor attempts stalled halfway, leaving worse complexity than before
The outcome you get
- 7-factor diagnostic applied to your specific codebase and team context
- Scored recommendation: rewrite, strangler-fig, or refactor — with written justification
- Cost/time/risk model for each path, grounded in your team velocity and runway
- Migration plan if rewrite or strangler-fig is the answer
- Executive narrative ready to present to board and investors
Why this decision is genuinely hard
The rewrite or refactor decision is hard not because the options are unclear, but because the evidence is usually scattered across people who have conflicting interests in the outcome. Senior engineers want to rewrite because the current code embarrasses them. Junior engineers want to refactor because they are afraid of a blank page. Founders want the fastest path. Investors want the cleanest story. None of those inputs are wrong — they just aren't the same as evidence.
Studies of enterprise software rewrites put the failure rate between 60 and 80 percent. Projects that succeed commonly take two to three times longer and cost two to four times more than the original estimate. That's not an argument against rewrites — sometimes a rewrite is the right answer. It is an argument for making the decision carefully, with a structured diagnostic rather than a vote.
7-factor diagnostic applied to your specific codebase and team context
The 7 factors I score
I score each factor 1–5 with evidence from codebase access and team interviews. The overall picture usually becomes clear once all seven are in front of you.
Factor 1: Codebase age and decay rate. Systems older than seven years with no architecture documentation generally favor rewrite; systems under five years with coherent module boundaries favor refactor.
Factor 2: Test coverage. Low coverage makes refactoring genuinely dangerous — you cannot verify that behavior is preserved. Under 40 percent meaningful coverage is a strike against refactor.
Factor 3: Architectural clarity. If the domain boundaries are muddled and business logic is scattered across layers, refactor often just moves complexity around. A clean boundary problem is a rewrite signal.
Factor 4: Team size and tenure. A small, stable team can carry the context needed to refactor safely. A rotating or growing team cannot — the "code memory" (embedded business rules and edge cases that exist nowhere except the codebase) gets lost.
Factor 5: Business velocity pressure. High feature pressure forces incremental delivery. If the business cannot afford a feature blackout, greenfield rewrite is off the table regardless of technical merit.
Factor 6: Stack freshness. A stack that is ten or more years out of date, with no hire-able talent pool, often requires rewrite because the refactor path keeps you on infrastructure with no future.
Factor 7: Cost of being wrong. High-stakes regulated systems — fintech, healthcare, infrastructure — favor conservative incremental paths. The asymmetric downside of a failed rewrite in these environments is large.
120k+: Properties indexed and searchable.
Strangler fig vs greenfield: how I choose
When the diagnostic points toward rewrite, there are two flavors, and the choice between them matters as much as the rewrite decision itself.
Greenfield means a new codebase built from scratch, data migrated when complete, traffic switched at go-live. It is high-risk, requires a feature blackout during the cutover window, and concentrates all project risk into a single date. I recommend greenfield only when the old codebase genuinely cannot be run alongside the new one — incompatible data models, fundamental platform migrations, or regulatory mandates that require a clean separation.
Strangler fig means the new codebase is stood up alongside the old, traffic routed endpoint by endpoint, the legacy system retired piece by piece. Features ship throughout. Risk is distributed across many small cutovers rather than one big one. Business pressure stays manageable because the product keeps moving. For roughly 90 percent of rewrite situations, strangler fig is the right answer.
I argue for strangler by default and present greenfield only when specific technical constraints make it unavoidable. That recommendation comes with a written rationale, not just a label.
Cost/time/risk modeling per path
Each path gets a model built from your specific data: team velocity from your project management history, feature commitments already on the roadmap, funding runway, and current infrastructure spend.
Refactor typically runs 6–24 months at 20–30 percent of team capacity running in parallel with product work. Total cost is lower. No feature blackout. The main risk is never finishing — refactor projects stall when business pressure forces the team to keep shipping on the old foundation.
Strangler fig rewrite runs 9–18 months at higher dedicated capacity. Middle cost, middle risk, with risk distributed across the timeline rather than concentrated at the end. Revenue keeps flowing throughout.
Greenfield rewrite runs 3–18 months depending on scope, with a feature blackout period in the middle unless aggressive parallel investment is made. Highest total cost, most risk, but sometimes the only viable path given technical constraints.
When the models are side by side, what was an engineering debate becomes a business decision — capacity, runway, and risk tolerance rather than opinions about clean code.
The Imohub rebuild: when rewrite paid back
Imóveis SC — now Imohub — was a legacy real estate portal where I evaluated refactor and rejected it in favor of a rebuild. The diagnostic showed architectural boundaries that were too muddled to refactor safely, a stack with no viable hire-able talent pool, and infrastructure costs that were compounding. A strangler approach was not viable because the data model was incompatible with the new system.
The rebuild — Next.js, Laravel, Meilisearch, MongoDB, AWS — delivered 70 percent infrastructure cost reduction and query response under 0.5 seconds for 120k+ properties. Top 3 Google rankings followed. Development velocity lifted post-cutover because the new stack matched what the product actually needed.
Not every rewrite pays back this clearly. The discipline in the diagnostic is precisely what separates the ones that do from the 60-to-80 percent that don't.
When the answer is neither
Sometimes the diagnostic reveals the technical situation is not the actual problem. Team turnover is. Product-market fit isn't there. The hiring process keeps bringing in the wrong people. In those cases, a rewrite or refactor will not solve anything — it will just give the real problem a different set of symptoms.
I say so when the diagnostic points there. It is not the expected answer when a founder has built up to a technical decision, but it is the honest one. A company should not rewrite its codebase to solve a hiring problem. A company should not refactor indefinitely to avoid a product pivot that the market is demanding.
The deliverable in those cases is a shorter diagnostic report explaining what is actually broken and what work would address it. Honesty at that point is more valuable than an engineering-shaped recommendation that does not touch the root cause.
How the engagement works
The rewrite-or-refactor diagnostic fits the Fractional CTO service at the $5,499/mo advisory tier, delivered as a 2–3 week fixed-scope engagement. Week one is codebase access and team interviews. Week two is 7-factor scoring and model building. Week three is recommendation drafting and a review meeting with you.
Deliverable: a written diagnostic report with the 7-factor scoring, cost/time/risk models for each path, a defensible recommendation with written justification, and a migration plan if rewrite or strangler fig is the answer. The executive narrative for board conversations is included.
Follow-on implementation oversight is optional. Many founders take the recommendation and execute with their internal team. Others keep me on for the architecture review cycles during the build. 14-day money-back on the diagnostic. Work Made for Hire on all written deliverables.
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.
Read the case studyKeep reading
Frequently asked questions
The questions prospects ask before they book.
I score seven factors — codebase age, test coverage, architectural clarity, team tenure, business velocity pressure, stack freshness, and cost of being wrong — each 1 to 5 with evidence from codebase access and team interviews. The aggregate score usually makes the right path legible. When it does not, the ambiguity itself tells you something: the decision is close, and the lower-risk path (refactor or strangler) is generally correct when the evidence is genuinely split.
Studies put enterprise software rewrite failure between 60 and 80 percent — projects that either fail to deliver expected benefits or are canceled outright. Those that succeed commonly take two to three times longer and cost two to four times more than originally estimated. That is not an argument against all rewrites. It is an argument for using a structured diagnostic before committing to one, rather than making the decision by team vote or investor pressure.
For most situations, yes. Strangler fig distributes risk across many small cutovers, keeps features shipping throughout, and avoids the big-bang cutover that kills most greenfield projects. Greenfield is the right answer only when the old codebase genuinely cannot run alongside the new one — incompatible data models, fundamental platform migrations, or hard regulatory requirements. I recommend greenfield in roughly 10 percent of rewrite cases, always with specific written justification.
Yes, and this is one of refactoring's main advantages. A well-scoped refactor runs at 20–30 percent of team capacity alongside normal product work. The risk is that business pressure gradually crowds out the refactor work until it stalls entirely. Addressing that risk requires an explicit capacity commitment from leadership — not just engineering enthusiasm — and a measurable milestone structure so you can tell when the refactor is losing ground.
A common rule of thumb: if less than 40 percent of the codebase requires fundamental change, refactor is usually the better path. When estimated refactor cost reaches 60–70 percent of a full rebuild estimate, the economics shift. But percentages are a starting point, not a conclusion — architectural clarity, team stability, and business pressure often matter more than raw lines of code. I use the 7-factor score rather than a single threshold.
It depends on scope and approach. Greenfield rewrites for business-critical applications typically run 12–24 months. Strangler-fig rewrites run 9–18 months with features shipping throughout. These ranges assume a dedicated team with realistic capacity — not a team trying to rewrite while maintaining full feature velocity on the old system, which is how most rewrites overrun. The cost/time model I build is specific to your team size, velocity data, and existing commitments.
It is optional. Many founders take the written diagnostic and recommendation and execute with their internal team. Others keep me on at the Fractional CTO tier for implementation oversight — reviewing architectural decisions at key milestones, unblocking the team when stuck, and mentoring tech leads through the migration. The decision depends on your team's capability and your budget. The diagnostic deliverable is complete and actionable either way.
Yes. The executive narrative is part of the deliverable, written to be presented without me in the room. If you want me present, I can join a board session as a technical voice — typically a 60-minute meeting covering the diagnostic summary and Q&A. That is included at the Fractional CTO tier. For founders who engaged at the Advisory tier only, a board session add-on is available separately.