Technical debt is usually invoked as an apology — a way of saying the code is untidy. That reading loses everything useful about the term. The metaphor is precise, and it is worth taking literally.
Debt is sometimes the correct decision
Borrowing to reach a market window or validate a product is a legitimate business choice. A shortcut taken knowingly, in a place you can reach again, to buy time you actually need, is not a failure of engineering. It is financing.
What makes it debt rather than damage is that it was chosen, recorded and scoped.
Interest is paid in delivery speed
The interest on technical debt shows up as time, and it is charged every time the affected area is touched:
- Features in that area take longer to estimate and longer to build
- Changes produce regressions in places that seem unrelated
- Onboarding slows, because the system cannot be explained honestly in a short time
- Engineers route around the area instead of through it, and the workarounds become debt of their own
None of this appears on a budget line, which is precisely why it goes unmanaged.
Unacknowledged debt is the expensive kind
A team that knows it took a shortcut can plan the repayment. A team that has forgotten simply experiences a codebase that is inexplicably slow to change, and concludes that this is normal.
Write the shortcut down when you take it. A recorded shortcut is debt. An unrecorded one is just a system nobody understands.
Repayment is a schedule, not a rewrite
The instinct to declare bankruptcy and rebuild is almost always wrong: it pays off the debt by destroying the asset. Repayment works the same way it does financially — allocate a consistent share of capacity to it, prioritise the debt carrying the highest interest, and repay principal in the areas you are actively changing.
This is how we build.
Cresslink engineers software products and custom systems for businesses. The principles we write about are the ones we work to.