✦ Buying, cost and process
What is technical debt, and how do you know if you have a problem
Technical debt is the extra cost of maintaining and changing software because of shortcuts, ageing decisions, or a lack of investment in its design over time - not because the software is 'broken'. If your developer keeps using the phrase, it's worth understanding what it actually means before you agree to spend money fixing it.
Haystak · 11 August 2026 · Updated 11 August 2026 · 7 min read
Technical debt is what is what economists would call a metaphor: like financial debt, it lets you move faster now in exchange for a cost you'll pay later, with interest. In software, that cost shows up as new features taking longer to build, more bugs appearing in places nobody touched, and a growing reluctance among developers to change anything for fear of breaking something else.
It doesn't mean your software is bad or was built badly. Some technical debt is a reasonable trade-off, taken on deliberately to hit a deadline. The problem is when nobody tracks it, and the interest quietly compounds until ordinary changes become disproportionately expensive.
Where does technical debt actually come from?
It builds up from several different directions, and it's worth knowing which one you're dealing with, because the fix is different in each case.
| Source | How it happens | Example |
|---|---|---|
| Deliberate shortcuts | A quick fix chosen to hit a deadline, meant to be revisited later | Hard-coding a value instead of building a proper settings screen, 'just for now' |
| Ageing decisions | A choice that was reasonable at the time but hasn't kept pace with how the business grew | A system built for 10 users now serving 200 |
| Neglect | No ongoing investment or maintenance over years | Nobody has updated dependencies since the system launched |
| Knowledge loss | The people who understood the design have left, with nothing written down | Every change now requires reverse-engineering how it works first |
The first is often fine, provided it's revisited. The other three are what usually turns into a real problem, because nobody chose them deliberately - they accumulated.
The phrases that suggest technical debt is real, not an excuse
It's a fair worry that 'technical debt' can be used as a vague justification for a big invoice. Here's how to tell whether it's describing something real.
- "We can't make that change safely without touching several other things" - a sign of tightly tangled code where nothing can be changed in isolation.
- "That would take longer than it should because of how it was built" - worth asking specifically what about how it was built, and whether it's fixable.
- "We're scared to touch that part of the system" - a genuine and useful admission; it usually means there's no way to test that part safely before releasing a change.
- "It would be quicker to rebuild that section than change it" - the strongest, most concrete signal, and worth taking seriously rather than dismissing as an excuse to start again.
If your developer can only describe the debt in vague terms - 'it's just old' or 'it's messy' - ask them to point to a specific recent example where it slowed something down or caused a bug. A real answer will have one.
Signs your business has a technical debt problem
You don't need to read code to notice the symptoms. These are the practical signs, visible from the business side.
- 01Small changes take a long time. A request that should be a day's work regularly turns into a week, with no clear reason why.
- 02Bugs appear in places you didn't touch. Fixing one thing breaks something apparently unrelated.
- 03Nobody wants to make certain changes. Developers avoid touching specific parts of the system, or insist on extensive testing for small tweaks.
- 04New starters take a long time to become useful. If there's no documentation, every new developer has to learn the system from scratch by trial and error.
- 05The system can't do something your competitors' systems clearly can. Growth is blocked not by a business decision but by the software's structure.
Does technical debt mean we need to rebuild the system?
Not necessarily, and a full rebuild is rarely the first thing worth trying. Technical debt is usually paid down incrementally: restructuring a specific troublesome area, adding tests around the parts nobody dares touch, or documenting how something works before the person who understands it leaves. A full legacy system migration is warranted when the debt is so widespread, or the underlying technology so unsupported, that incremental fixes cost more than starting again.
The right way to decide is the same as any other investment decision: weigh the ongoing cost of the debt (slower delivery, more bugs, growing risk) against the cost of fixing it, and be honest about which is bigger. We'd rather tell you the debt isn't yet worth fixing than sell you a rebuild you don't need.
How to stop it building up again
A small amount of ongoing investment prevents most debt from becoming a crisis. This is one of the reasons a proper software maintenance arrangement matters beyond just fixing bugs - it's also where the routine work of paying down debt happens, a bit at a time, rather than in an expensive, disruptive block years later.
The original term was coined by Ward Cunningham in 1992, and his own explanation is still one of the clearest - he intended it as a description of a reasonable, deliberate trade-off, not a synonym for bad code. Worth reading if you want the concept from source rather than filtered through a sales conversation.
If a developer keeps raising technical debt and you want an outside, plain-English view on whether it's a genuine problem, get in touch - we're happy to take a look and tell you honestly whether it's worth acting on now or leaving for later.
✦ Where this fits
More on this from us: our legacy software modernisation service.