Quantifying the cost (Cost Calculator) and building the case (Business Case Builder) only gets you to the starting line. This page compares the four execution approaches that actually work in practice — and when to reach for each.
Pause feature work entirely for a fixed window and put the whole team on debt paydown — the highest-drag items first, not the loudest complaints. It's the fastest way to make a visible dent, and the easiest for leadership to understand because it has a clear start and end date.
Rough cost, 10-person team: team size × avg. fully-loaded salary × (sprint weeks ÷ 52) — a 3-week sprint at a $150K average loads to roughly $85K–$90K in opportunity cost against paused feature work, landing most estimates in the commonly-cited $50K–$150K band depending on team size and duration.
Pros: fast, visible, easy to scope and measure. Cons: feature roadmap stalls for the duration; requires real management buy-in to protect the freeze from getting cut short.
Best for: teams with a visible crisis (missed sprints, repeated incidents) and a leadership sponsor willing to hold the line.
Ring-fence roughly one-fifth of every sprint for debt work as a standing, non-negotiable allocation — not "whatever's left over." The mechanism is simple; the hard part is holding the line when a deadline gets tight.
Pros: no dedicated budget ask, spreads the cost thin and predictably, keeps debt from re-accumulating once you've paid it down. Cons: requires ongoing discipline — it's the first thing that gets cut under deadline pressure, and it moves too slowly to address a genuine crisis on its own.
Best for: steady-state maintenance once your debt ratio is already under roughly 20–25% — see the Industry Benchmarks page for where that sits relative to your stage.
Named for the fig species that grows around a host tree until the original is gone — build the new implementation alongside the legacy one, and incrementally route traffic or functionality to it, piece by piece, rather than attempting a big-bang cutover.
Pros: the system stays live and shippable the entire time; risk is isolated to whatever slice you're migrating this week; you can stop or reverse course without a wasted rewrite. Cons: requires running two implementations in parallel for a while, which has its own coordination overhead; needs careful routing/interface design up front.
Best for: architecture-level debt in systems that genuinely can't tolerate downtime or a hard cutover — most core platform and payments-adjacent systems.
"Leave every file a little better than you found it." No dedicated allocation, no sprint carve-out — just a norm that whenever you're already touching a piece of code, you clean up what's immediately around it before you move on.
Pros: effectively free — no budget conversation required, works well layered on top of any of the other three strategies. Cons: slow by itself, easy to skip under pressure, and does nothing for debt that nobody happens to be touching.
Best for: codebases that are already in reasonably good shape and want to stay that way, or as a supplement to a more active strategy above.
| Strategy | Startup cost | Ongoing cost | Buy-in needed | Risk level | Time to results | Best for |
|---|---|---|---|---|---|---|
| Debt Sprint | High | None | High | Low | Fast (weeks) | Visible crisis |
| 20% Rule | Low | Steady | Medium | Low | Slow (quarters) | Steady-state maintenance |
| Strangler Fig | Medium | Medium (parallel run) | Medium–High | Medium | Slow (months) | Architecture-level debt |
| Boy Scout Rule | None | Minimal | Low | Very low | Very slow (ongoing) | Already-healthy codebases |
These aren't mutually exclusive, and in practice most successful paydown programs stack two or more:
20% Rule + Boy Scout Rule — the standard combination for steady-state maintenance once you're in reasonable shape.
Debt Sprint + 20% Rule — use the sprint to recover from a bad state, then the 20% Rule to keep debt from creeping back up afterward.
Debt Sprint + Strangler Fig — for critical or architecture-level systems: use focused sprints to build out the new implementation in parallel while the Strangler Fig pattern handles the incremental cutover.
All three (Sprint + 20% Rule + Strangler Fig) — enterprise-scale transformations, where different parts of the estate are at different stages simultaneously.
How many teams, services, or downstream consumers does this piece of debt actually touch? Debt that's isolated to one team's internal tooling is a lower priority than debt sitting on a shared platform component.
How often does someone actually have to touch this code? Debt in a file that changes weekly compounds into real drag; debt in a file nobody has opened in two years is lower urgency, whatever its raw quality score.
Pull your incident history and unpatched-dependency list (see the Metrics Guide) and look for clustering. Debt that keeps showing up in postmortems jumps the queue.
Weigh the effort to remediate against what it's costing you to leave it alone — and remember that cost of inaction compounds rather than staying flat. The Compound Interest Visualizer models exactly this tradeoff.
A rewrite is high-risk by nature — you're pausing forward progress on a known-working system to bet on an unproven one — and should be the last resort considered, not the first idea proposed. It's genuinely warranted only when most of the following are true:
1. The platform has hit a scaling ceiling that no amount of incremental optimization will fix. 2. The underlying technology is genuinely unsupported or end-of-life with no viable upgrade path. 3. Incremental strategies — the Strangler Fig pattern included — have already been tried and failed, not just considered. 4. The business case for a rewrite clearly beats its multi-year cost, including the opportunity cost of frozen feature work. 5. Leadership is prepared to commit and genuinely protect the team from feature-delivery pressure for the duration.
If more than one or two of these don't hold, look harder at the Strangler Fig pattern first — it gets you most of the benefit of a rewrite without betting the whole system on one outcome.
Once you've picked an approach, here's where to go next: