Tech

Technical debt explained to whoever pays

Technical debt is the sum of the shortcuts taken to deliver sooner: every shortcut is repaid with interest as changes get slower and dearer. It is not always a mistake — sometimes it is the right call — but it must be made visible, measured and repaid regularly instead of ignored until a rewrite.

15 Dec 2025 · 8 min read · updated on 27 Aug 2026

There is a moment, in every software project a few years old, when the conversation changes tone. You ask for a change that seems small and the answer is "three weeks". You ask why, and you get a technical explanation that clarifies nothing.

You are not being taken for a ride, and it is almost never incompetence. You are being described, badly, a phenomenon with a precise name: technical debt. And it is an economic concept, not a computing one — which is why it is worth understanding for whoever signs, not only for whoever codes.

What it is, in one line

Technical debt is the sum of the shortcuts taken to deliver sooner. Like a loan: you take value now — the feature ships in March instead of May — and repay it later, with interest, as changes that cost more and more.

The metaphor holds all the way, including the uncomfortable part: you pay the interest even if you never repay the principal. A system full of shortcuts is not stuck: it slows down every single thing you will ever do to it from now on.

Where it comes from (and why it isn't always a mistake)

Contrary to what is often said, technical debt is not only the product of bad work. It arises in four ways, and two of them are legitimate.

A deliberate choice. You need to beat a competitor or meet a regulatory deadline: you take the short road knowing it will need fixing. That is good debt, like financing a machine.
The world changed. The software was built for twenty users and now has two hundred. Nobody was wrong: the initial assumptions expired.
Chronic hurry. Every request is urgent, there is never time to tidy up. Here debt accumulates without anyone deciding to take it on.
Nobody ever made it visible. The most common case: the debt exists, the people in the code know it, but it was never translated into a number decision makers can see.

The problem isn't having technical debt. It's having it without knowing, and therefore not being able to budget for it.How we treat the projects we inherit

The symptoms you can spot yourself

You don't need to read code. Four signals visible from your side are enough:

Estimates grow for the same request. A change that was "three days" two years ago is "two weeks" today, and the feature has not become more complicated.
Every fix breaks something else. You repair one thing and something apparently unrelated fails: it means the pieces are more entangled than they should be.
Nobody wants to touch that part. There is an area of the system spoken about in a low voice and avoided in planning meetings.
The supplier asks to rebuild everything. The most advanced symptom: when gradual repayment is no longer credible, a rewrite is proposed — which is like clearing a mortgage by taking a bigger one.

What ignoring it costs

The cost doesn't arrive as an invoice: it arrives as slowness. A team spending half its time working around the past delivers half as much for the same spend. It is a tax paid every month, and precisely because it is spread out it appears nowhere.

Then there is a worse and less predictable cost: the inability to react. The day the market asks for something new and the answer is "not with this system", the debt has stopped being technical and become a competitive limit.

How it is repaid, without stopping everything

The strategy that works is not "let's stop for three months and fix it": it is constant repayment, invisible in the plan but continuous.

Make it visible. Ask the supplier for a list of the critical points with the practical effect of each: "this area slows every change to orders by twenty per cent". If they can't answer, that is already information.
Reserve a fixed share. Between ten and twenty per cent of development time dedicated to repayment, every cycle, without asking permission each time. It is the line that makes everything else sustainable.
Tidy where you pass. Every time an area is touched for a new feature, leave it slightly better than you found it. It is the cheapest method because it needs no dedicated projects.
Rewrite only the inevitable. A total rewrite has a low success rate and meanwhile the old system still needs maintaining: two costs at once. Reserve it for cases where the technology is no longer sustainable, not where the code is ugly.

Questions to ask your supplier

Which three parts of the system slow the work most, and what do they cost us in time?
How much of your time each month goes into maintenance and how much into new things?
If tomorrow we had to add a feature in the most delicate area, what would it cost compared with the same feature elsewhere?

These are questions a serious supplier has been waiting years for: they finally let them show a problem they have already flagged technically, and that nobody understood.

Technical debt is not eliminated: it is governed, like any other form of borrowing. The difference between companies that live well with it and companies it strangles is one thing only: the former know how much they have.

How do I know if our supplier is managing it?

Ask how much of the time goes into maintenance. If the answer is "almost none, we only do new things", the debt is growing. If it is "about fifteen per cent", somebody is governing it.

Is rebuilding from scratch ever right?

Sometimes: when the technology no longer receives security updates, when nobody on the market knows it any more, or when the system cannot meet a business requirement that has become essential. Rarely because "the code is old".

Does technical debt apply to bought software too?

Yes, in a different form: customisations never updated, versions frozen years back because upgrading would break the changes, integrations written for a format the vendor has changed. The effects are identical.

What does repaying it cost?

Less than not repaying it — a convenient answer. In practice a constant share of the development budget, between ten and twenty per cent: below that the debt grows anyway, above it you slow value delivery too much.