Tech debt ROI calculator

Tech debt ROI — the engineering investment case

Tech debt is the #1 cause of slipping roadmaps, but fixing it is the #1 thing that gets deprioritized. The core problem: tech debt fixes don't ship features. This calculator reframes debt-fix projects as investments with measurable ROI — so you can make the case to skeptical leadership and pick which debt is actually worth paying down.

What counts as tech debt?

Not all "ugly code" is worth fixing. True debt-fix candidates have three qualities:

1. Active drag: Currently slowing down ongoing work. Dead modules aren't debt — they're just old.
2. Quantifiable impact: You can estimate the % of time lost to it. Gut-feel works: "15-25% slower shipping in this area".
3. Reversible after fix: The fix returns the area to healthy state. If the problem will regenerate (e.g., no process change), the ROI is temporary.

The debt categories

Not all debt is the same. Impact varies wildly:

• Architectural debt: Wrong abstraction, monolith that needs splitting, coupled services. Biggest drag (30-50% slowdown on affected code), hardest to fix (weeks to months), highest ROI when correctly targeted.
• Dependency debt: Outdated libraries, language version. Usually 5-20% drag. Fixes are mechanical but risky. ROI depends on whether security/features are blocked.
• Test debt: Missing tests, slow tests, flaky tests. 10-30% drag (more careful manual testing, rollbacks from missed bugs). Fixes are time-consuming but predictable.
• Infra debt: Manual deploys, no CI, bad monitoring. Often causes incidents that eat days of team time. High ROI when there's been a recent incident.
• Code-quality debt: Bad naming, poor structure, complex functions. Low drag (5-10%) and hard to quantify. Usually not worth dedicated projects — fix opportunistically.

The ROI formula

Drag cost per year = team size × loaded salary × drag %

Fix cost = team-weeks × (team size × weekly loaded salary)

Annual savings = drag cost today − drag cost after fix

Payback months = fix cost ÷ annual savings × 12

Target payback: 12 months or less for straightforward pitch, 12-24 months with strong strategic rationale, 24+ months needs extra justification beyond ROI.

How to estimate drag

Most teams intuitively know which areas are painful. Three techniques to quantify:

1. Team survey: Ask engineers who work in the area: "What % of your time goes to working around existing problems vs writing new code?" Average responses.
2. Velocity comparison: Compare velocity (story points / tickets / PRs per week) in affected area vs healthy areas of the codebase.
3. Pilot fix + measurement: Fix a small piece, measure velocity delta for 4-6 weeks. Project larger fix based on proportional scale.

Pitching to leadership

Framing matters. What not to say:

• "We need to rewrite X because it's bad"
• "Tech debt is slowing us down"
• "This code is a mess"

What to say instead:

• "Area X is costing us $400k/year in engineering drag. A 6-week investment ($200k) pays back in 6 months and generates $1.2M in freed-up capacity over 3 years."
• "The auth module's complexity blocks velocity on features A, B, C, all on the Q2 roadmap. Fixing it unblocks those by 4-6 weeks."
• "Our test suite takes 45 minutes; industry peers are 5-10 min. That's 2 hours/day/engineer of context switching. $300k/yr cost. Fix is 3 weeks for infra engineer, payback 1 month."

Translate "fix this" into "stop paying this" — that's the language executives understand.

Rewrite vs refactor

The big decision in any major debt project. Default to refactor unless:

• Fundamental data model is wrong (doesn't match product needs, not just "messy")
• Framework/language choice is blocking critical capability
• Clear system boundary makes isolated rewrite possible (e.g., one microservice)
• Team has written the functionality before successfully

Rewrites have ~70% failure rate (per Martin Fowler, Mike Loukides, others). They take 2-4x longer than estimated. They often ship without parity. Pick refactor unless there's strong reason otherwise.

Paying down debt continuously

Large debt-fix projects are hard to justify. Continuous improvement is easier to sneak in:

• Boy Scout rule: Leave code cleaner than you found it. Small improvements during feature work.
• 10-20% time: Dedicated time for debt work, explicit on the roadmap.
• Debt sprints: Every 6-12 weeks, a sprint focused on top debt items. Predictable cadence.
• Quality ratchet: Make it impossible to add new debt without paying down existing. Linting, test coverage gates, PR review standards.