Technical debt is the engineering equivalent of a credit card. A little is fine — you pay it off when you have time. A lot, left unchecked, starts compounding until the interest payments consume your entire sprint.
The problem is that technical debt is invisible to most stakeholders. Revenue is down, the sprint velocity has halved, and engineers are spending 60% of their time on “maintenance”. No one called it debt — it just happened.
What counts as technical debt
Technical debt is any shortcut in the code or its design that makes future changes slower or riskier. Some of it is deliberate and sensible: you ship a simpler version to meet a date, knowing you will revisit it. The damaging kind is the debt nobody decided to take on, which builds up through rushed fixes, missing tests and designs that no longer fit what the product has become.
How to spot it early
First, watch your bug recurrence rate. If the same category of bug keeps appearing in different parts of the codebase, you have a structural problem — not a one-off. Second, track your time-to-first-PR on new features. If it keeps growing, your architecture is slowing you down. Third, ask your engineers directly. They know. They are just not always asked.
Other signals worth watching:
- Estimates keep growing for work that looks similar to what the team did a year ago.
- Areas nobody wants to touch. Every codebase has one. Note how much of the product depends on it.
- Releases need a ritual. Manual steps, a specific person or a quiet Friday are signs of fragile delivery.
- New engineers take months to make a safe change.
- Fixes cause new bugs in unrelated places.
Where the cost shows up
The engineering cost is the visible part. The larger costs sit elsewhere: features that arrive a quarter late, outages that reach customers, good engineers who leave because the work has become frustrating, and opportunities the business turns down because “the system cannot do that”.
Not all debt is worth paying
Code that is ugly but stable and rarely changed costs you almost nothing. Debt is expensive where the team works every week. Before planning any clean-up, rank areas by two things: how often they change and how much pain they cause when they do. Fix the top of that list and leave the rest alone.
The fix: pay continuously
The fix is not a debt sprint — it is building repayment into every sprint as a first-class citizen. Budget 20% of capacity for debt reduction every cycle. Track it like a feature. Review it in your sprint retros.
Two habits make that budget effective:
- Improve what you touch. When a feature takes you into a messy area, clean up that area as part of the work, with tests, while the context is fresh.
- Write the debt down. Keep a short, ranked list with the business effect of each item. “Checkout changes take three times longer than they should” gets prioritised. “Refactor the order module” does not.
Explaining it to non-engineers
Talk about outcomes, not code. Stakeholders do not need to understand the architecture; they need to know that a specific investment will make a specific kind of work faster or safer. Show the trend in delivery time and tie each proposed fix to a feature it unblocks.
Technical debt paid early is cheap. Technical debt paid at crisis point is expensive in ways that go far beyond the engineering cost.
If your team is stuck behind a difficult codebase, our engineering team can help you assess it, or you can add senior engineers to work through it alongside your own.
