On this page
Time gained now, interest paid later
You notice technical debt the day a small change suddenly takes days. It behaves like a loan. You gain time now, an earlier launch or a lower quote, and then pay interest on every change: an extra hour here, a day of digging there, an update nobody dares to install.
Debt is not limited to custom code. A WordPress site with twenty plug-ins nobody updates, a spreadsheet full of macros only the founder understands, an integration held together with tape: all of them are loans. When you buy software from an agency, near or far, the debt you inherit matters as much as the features you see. At the Dagstuhl seminar of 2016, researchers agreed on a working definition: design or code choices that are expedient in the short term but make future changes more costly or impossible. So is an app an AI model wrote without anyone reading the code, known as vibe coding.
Since Ward Cunningham in 1992
- 26 March 1992Cunningham coins the metaphorIn an experience report for the OOPSLA conference on WyCash, a portfolio management system, Ward Cunningham writes that shipping first-time code is like going into debt.
- 2009Cunningham explains it againIn a five-minute video he tells how the metaphor began, defends it as an argument for refactoring and corrects how it is often misread.
- 14 October 2009Fowler draws four kindsMartin Fowler sorts debt on two axes: prudent or reckless, deliberate or inadvertent.
- April 2016A shared definitionResearchers and industry agree on a working definition at Dagstuhl seminar 16162, known since as the 16162 definition.
- 21 May 2019Interest in daysFowler does the sums: a four-day feature takes six with messy code, and cleaning up takes five.
Principal and interest
Cunningham wrote in 1992 that a little debt speeds development, as long as it is paid back promptly with a rewrite. The danger starts when it is not: every minute spent on not-quite-right code counts as interest. Entire engineering organisations, he warned, can grind to a halt under the load.
Martin Fowler turned it into arithmetic in 2019. With a clear structure a new feature takes four days; with the mess that is there now, six. Those two days are the interest. Cleaning up takes five days: that is the principal. For one feature, paying off does not pay; for three, it does. And a nuance that often gets lost: you only pay interest when you touch that part of the software. Messy code you never change can stay; the code you work in every week has to be clean.
Deliberate or accidental, reckless or prudent
Not every debt is a mistake. Fowler places debt in a grid built on two questions: did the team know it was borrowing, and was that a sensible choice?
| Kind | What it sounds like | What to do about it |
|---|---|---|
| Deliberate and prudent | We launch before the trade fair and clean up the week after. | Book the clean-up straight away, with a date. |
| Deliberate and reckless | No time for tests, it has to ship tomorrow. | Stop: the interest arrives within weeks, not months. |
| Inadvertent and reckless | Another plug-in for every request. | Have someone experienced review the foundations. |
| Inadvertent and prudent | A year in, you know how it should have been built. | Normal. Rewrite what you touch often. |
The last kind is unavoidable, Fowler says, even for the best teams: you learn while you build. An MVP almost always takes on deliberate debt, and that is fine, as long as the clean-up is in the plan. In Scrum that work belongs inside the sprints, not on a list for later. If you sell your software as a service, a SaaS product, the interest compounds with every customer you add.
A year of interest, in hours
Extra hours added up, over one year
- Keep paying interest: 8 hours a month
- Pay it off: 60 hours in month 1, then 1 hour a month
After just over 8 months, paying off is cheaper
month, hours
Four kinds of debt, after Martin Fowler
Deliberate or inadvertent
We go live before the trade fair and clean up the week after.
No time for tests, it has to ship tomorrow.
A year in, you know how it should have been built.
Another plug-in for every request, and nobody checks what it does.
Prudent or reckless
A worked example, not a client. At 75 euros an hour, a year of interest costs 7,200 euros; paying off costs 5,325 euros and the site is quicker to change afterwards.
Three debts we often run into
The WordPress site with twenty plug-ins. Take a wholesaler with a WordPress site from 2019, 23 plug-ins, several of them without updates for years, on a server running PHP 7.4. That version has had no security fixes since 28 November 2022; WordPress now recommends PHP 8.3 or higher and warns that older versions may expose your site to vulnerabilities. PHP 8.2 drops out of support on 31 December 2026 as well. Upgrading is blocked, because two plug-ins break on a newer version. Every small change, a new block on a product page, a field in the form, takes three hours instead of one, because someone first has to find out what breaks. Whether WordPress is safe depends on exactly this, and it is often why WordPress is so slow.
The spreadsheet that became a platform. A haulage company plans its trips in a spreadsheet with macros, built by the owner on a Sunday. It worked for five drivers. At twenty, every new customer means a new tab, only one person can plan at a time and nobody knows which formula does what. That is technical debt too, and the interest sits in the planner's hours. Whether to replace it with an off-the-shelf package or your own tool is the question in build vs buy software.
The interest in hours and euros
Work it out like a loan. Take the wholesaler's site: four changes a month at two extra hours each is eight hours of interest a month. At 75 euros an hour that is 600 euros a month, 7,200 euros a year, with nothing new to show for it. Paying off: plug-ins down from 23 to 12, PHP to 8.4, the theme cleaned up, sixty hours or 4,500 euros. Afterwards at most an hour of interest a month remains. After a year you have paid 71 hours instead of 96: 5,325 euros against 7,200, and the lines cross after just over eight months.
What the sum leaves out is risk. A site on a PHP version without security fixes can be hacked any day, and recovery then costs more than the whole clean-up. Rates for that work differ across Europe; our guide to web developer hourly rates compares Belgium with five markets.
Paying down without a full rebuild
- Take stockVersions of PHP, framework and plug-ins, what no longer gets updates, and which parts nobody dares to touch.
- Measure where the interest goesFor a month, log how many hours each change takes and where the time goes. Those are your expensive spots.
- Start where you work mostClean up what you change every month first. What is stable and rarely changes can wait.
- Set up a safety netTests, and a backup with a rehearsed way back, before you rewrite anything. Without a net, cleaning up becomes a risk of its own.
- Pay down steadilyA fixed share of every work cycle goes to clean-up, rather than one big project every three years.
Straight answers about old code
Is technical debt always bad?
No. Borrowing on purpose to make a trade fair, a season or a first customer can be the right call. It becomes a problem when nobody plans the clean-up, or when debt grows unnoticed because nobody experienced looks at the foundations.
How do you measure technical debt?
In hours: how much longer a change takes than it should, and how often you make that kind of change. Add the hard signals: software without security fixes, versions you cannot upgrade, parts without tests. An exact figure does not exist; a sound estimate does.
Who pays for technical debt when an agency built the software?
Whoever owns the software, and that is you. So have the quote state which versions are used, how long they are supported, who does updates and whether tests are included. A low quote without those terms is often a loan in your name.
Rebuild or refactor?
Refactor when the foundation is healthy and the debt sits in a few places. Rebuild when the foundation itself is the problem, such as a version with no upgrade path, or when cleaning up costs more than starting over with what you know now.