Guides 6 min read

What is technical debt? Why software gets slower to change

What is technical debt? A plain definition, the loan analogy, how it builds up, how an owner notices it, a worked example in euros and when debt is fine.

by Tsunami Digital Team October 30, 2026

Technical debt is the extra work you pay for later because software was built the quick way instead of the right way. Ward Cunningham coined the metaphor in 1992: shipping a shortcut is like borrowing money. You get the feature sooner, but every later change costs more until someone goes back and cleans it up. This is for owners whose software keeps getting slower and more expensive to change.

Quick answer

Principal is the shortcut itself: the messy module, the copied code, the outdated library.
Interest is the extra time every later change costs because of it.
Debt builds up from deadlines, shortcuts nobody returns to, team changes and dependencies left to age.
An owner sees it as estimates that keep growing, fixes that break other things and one person who “dares to touch” a part of the system.
Paying it down means planned clean-up hours alongside new work, aimed at the parts you change most.
Some debt is fine: an MVP, a test of an idea, a tool that will be thrown away.

Where the term comes from: the loan analogy

Cunningham used the image in his OOPSLA ‘92 experience report on the WyCash portfolio system: “Shipping first time code is like going into debt.” A little debt speeds development, he wrote, as long as it is paid back promptly with a rewrite. The danger is debt that is never repaid: every minute spent on code that is not quite right counts as interest.

A loan is a fair comparison because it is not bad by itself. A business takes a loan to move faster. Trouble starts when nobody tracks it, the interest compounds and one day most of the budget goes on repayments instead of new things.

How technical debt builds up

Deadlines. “Make it work by Monday” is often the right call. The problem is when Tuesday never comes.
Shortcuts nobody cleans up. The same logic copied into three places, a hardcoded value, a missing test. Each one is small; together they make every change slower.
The business changed, the code did not. The system was designed for one warehouse and now serves four. The original design no longer fits.
Outdated dependencies. Frameworks and libraries age. Skip updates for two years and a routine upgrade turns into a project.
People leave. Knowledge that was never written down walks out the door, and the next developer works more slowly and more carefully.

Four kinds of debt

Martin Fowler sorts debt along two lines in his technical debt quadrant (2009): was it deliberate or inadvertent, and was it prudent or reckless?

	Reckless	Prudent
Deliberate	”We don’t have time for design.” Shortcuts with no plan to repay.	”We must ship now and deal with the consequences.” A conscious trade-off with a plan.
Inadvertent	”What’s layering?” The team did not know better.	”Now we know how we should have done it.” Learned only after building.

Only the reckless half is a quality problem. Prudent debt is a normal part of building software: you learn the right design by building the first version.

How a non-technical owner notices it

Every change costs more than the last, even when it looks just as small.
A fix in one place breaks something unrelated.
Releases get rarer and riskier, and they are followed by a week of fixes.
Only one developer can safely touch a part of the system.
Estimates come with “it depends what we find in there”.

A worked example: the interest in euros

An illustrative calculation, not client data. Your system gets 4 changes a month. In clean code a typical change takes 8 hours; in this system it takes 20 hours, because developers first have to untangle what each change might break.

Clean: 4 × 8 = 32 hours a month.
Indebted: 4 × 20 = 80 hours a month.
Interest: 48 hours a month. At €40-60 per hour (our rate, excluding VAT) that is €1,920-2,880 a month, or €23,040-34,560 a year, paid for work that adds nothing new.

Now say three of the four changes land in the same module. Spending 60 hours once to clean it up brings those changes from 20 to 10 hours, saving 30 hours a month. The clean-up pays for itself in two months. That is the whole case for paying debt down: start where you change the most.

You are not alone in paying interest. In Stripe’s Developer Coefficient survey (September 2018), the average developer was estimated to spend 13.5 hours of a 41.1-hour week, about a third, on technical debt.

What paying it down looks like in a monthly arrangement

Paying down debt is not a six-month rewrite. In a monthly maintenance and development arrangement it is a share of the hours: the developer cleans up the part they are already working on, adds tests before risky changes, keeps libraries current and keeps a short written list of known debt with a rough cost for each item. You decide what gets priority, the same way you decide on new features.

What the monthly budget for this usually is, is covered in software maintenance cost and support. If the debt is so deep that every change is a gamble, read legacy software: migrate or build new before paying anyone to keep patching. And if you are inheriting a system from another supplier, start with taking over software from another agency.

When it is fine to carry debt

An MVP or test of an idea. Speed matters more than perfect code until you know the product works. See how to build an MVP.
A short-lived tool. A script for one migration or a campaign that ends in March does not need perfect design.
Code nobody changes. Debt only charges interest when you touch the code. A messy module that has not changed in two years can stay as it is.

The rule: take debt on purpose, write it down and know when you will pay it back.

Frequently Asked Questions

Is technical debt the same as bugs? No. Bugs are things that do not work. Technical debt is code that works but is expensive to change. Debt often leads to more bugs, because changes in tangled code break things.

Can technical debt be measured? Approximately. Tools like SonarQube estimate it from the code, but for an owner the more useful measure is time: how long changes take now compared with a year ago.

Does AI-generated code create technical debt? It can, quickly. That is a separate topic, covered in vibe coding and AI-generated code in production.

Is your software getting slower to change?

We can look at the code, tell you honestly where the debt is and what it costs you, and pay it down as part of ongoing work. See our engagement models.

Reach out at [email protected] or via the form on our homepage.

All articles