Technical Debt Repayment vs New Feature Development
The most common engineering leadership question. This framework gives you the signals, decision scenarios, and ROI models to make the case either way.
Signals: Which Way Should You Go?
Signals to Prioritise Debt Repayment
- !Incident frequency has increased more than 20% quarter-over-quarter
- !Time to onboard a new engineer exceeds 8 weeks
- !More than 40% of sprint capacity is consumed by unplanned work and rework
- !Three or more engineers have cited codebase quality in exit interviews this year
- !A major feature has slipped more than 100% of its original estimate due to coupling
- !A security audit has returned critical findings tied to code quality
- !Your engineering assessment score (using our framework) is below 40
Signals to Prioritise Feature Building
- +Debt is stable and below 15% of estimated codebase
- +A competitor has just shipped a feature that is directly affecting your win rate
- +A time-sensitive market window (regulatory change, seasonal opportunity) is open
- +Debt is confined to non-critical, low-churn areas of the codebase
- +The feature does not touch high-debt components
- +Team morale and retention are healthy; debt is not a recruiting issue
- +Engineering assessment score is above 70
Common Decision Scenarios
Scenario
Critical customer commitment + high debt
Build first, schedule debt sprint immediately after delivery
A signed customer contract with a committed delivery date cannot be renegotiated for internal engineering reasons. Deliver, but formally schedule and protect the debt sprint in the next planning cycle. Do not let it slip.
Scenario
Competitive feature + moderate debt
Build with a 25% debt allocation baked into the estimate
If debt is moderate and the feature does not touch the worst areas, build it with a conscious commitment to clean up as you go. Add 25% to estimates to account for this. Do not rush; rushed features in a moderate-debt codebase become high-debt problems.
Scenario
Nice-to-have feature + high debt
Repay debt first
A feature that is not strategically urgent should not be prioritised over debt that is actively slowing every engineer. The feature will be faster and higher quality if delivered from a cleaner foundation.
Scenario
Critical security patch + any debt level
Security first, always
Security patches are not a trade-off decision. Apply them first. If the debt level makes security patching risky, that is the debt that needs to be addressed immediately - it is no longer theoretical.
Scenario
Speculative new product + critical debt
Pause new product development
Building a new product on a critically-indebted platform creates two unsustainable problems at once. The new product will inherit the debt, and the core product's debt will continue to compound. Fix the foundation first.
How to Model the ROI of Debt Reduction
Stakeholders respond to numbers. Use these models to build a financial case for debt investment.
Payback Period Model
Calculate how many sprints of debt reduction it takes to recover the investment through improved velocity. If reducing debt by 10 points restores 15% velocity, and that equates to 6 story points per sprint for a 5-person team, a 40-point sprint investment pays back in 7 sprints.
Feature Comparison Model
Estimate the cost of the next three major features before and after debt reduction. If three features currently estimated at 24 weeks total would take 16 weeks after clearing a key debt area, the 4-week debt investment is recovered in the first feature.
Incident Cost Avoidance
Calculate annual incident costs (engineer hours, on-call burden, customer impact). Estimate what percentage of incidents are debt-related. If 40% of incidents trace to a specific high-debt module, the cost of addressing that module is justified by 2-3 years of incident cost avoidance.
Start with a Credible Cost Number
The debate between debt and features goes faster when you have a concrete annual cost figure. Generate yours in 30 seconds.
Estimate My Debt Cost