Technical debt: what it is, what it costs you and how to pay it down
By the E-Solutions Web editorial team. Published , updated . How we write
The short answer
Technical debt is the extra effort every change costs because of shortcuts and aging choices in a software system: rushed code, missing tests, outdated frameworks, logic only one person understands. Ward Cunningham coined the metaphor in 1992. A little debt speeds delivery if it is repaid. Left alone, its interest slows every new feature, until the team spends more time working around the system than improving it.
Every company that has run software for a few years carries some technical debt. This guide is for the people who pay for it, often without seeing it: the manager whose roadmap keeps slipping, the finance lead approving another maintenance budget, the CTO asked why a small change takes a month. The figures below come from the sources listed at the end, each read on October 1, 2026.
Technical debt, defined: the interest on every change
Technical debt is the extra time every change costs because the software is harder to modify than it should be. The metaphor comes from Ward Cunningham, in a 1992 experience report: “Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite.” He added the warning that matters most: “Every minute spent on not-quite-right code counts as interest on that debt.”
Martin Fowler makes the arithmetic concrete. A feature that would take four days in a clean module takes six in a confusing one: the two extra days are the interest. Cleaning the module would take five days, which does not pay for one feature but pays quickly if two more are coming. He also points out where the metaphor breaks: messy code that nobody touches costs nothing, because interest is only paid when you change it. That is why debt in the parts of a system that change every week is the debt to fix first.
When the interest has grown so high that the system can no longer follow the business, the answer is usually application modernization: replacing, piece by piece, what slows every change.
The four kinds of technical debt
Some debt is a sound choice; it depends on whether it was taken on knowingly and whether it was prudent. Fowler’s technical debt quadrant, published in 2009, crosses those two questions.
| Criterion | Prudent | Reckless |
|---|---|---|
| Deliberate | A shortcut chosen to meet a release date, with the team aware of the cost and a plan to repay it. | Quick and dirty by choice, because the team thinks it cannot afford clean code. Fowler calls this usually reckless. |
| Inadvertent | The better design the team only sees after months of building and learning. Fowler calls it inevitable, even for excellent teams. | Code written without knowing good practice. The team takes on debt without realizing it. |
The quadrant changes the conversation with management. Deliberate, prudent debt is a financing decision, like a loan. Reckless debt is a quality problem, and taking on more of it does not speed anything up for long: in his article on technical debt, Fowler writes that teams who do so “end up maxing out all their credit cards, but still delivering later.”
Where technical debt hides
Debt sits in the code, but also in the platform, the documentation and the way software is deployed. Code analysis tools see only the first.
| Form | What you notice | The business risk |
|---|---|---|
| Code | Duplicated logic, very long functions, no automated tests | Every fix breaks something elsewhere; releases slow down |
| Architecture | One change touches ten modules; nothing can be replaced alone | New features cost more each year |
| Outdated platform and dependencies | A language, framework or operating system past its end of support | Security holes that will not be patched; forced upgrades on someone else’s schedule |
| Knowledge | One person knows how the billing rules work, and nothing is written down | The system stops evolving the day that person leaves |
| Delivery | Manual deployments, no staging environment | Releases become rare and risky, so changes pile up |
| Data | Duplicated or inconsistent records across tools | Reports nobody trusts, integrations that need workarounds |
Platform debt has dates, which makes it the easiest to plan. PHP supports each release branch for two years of active support and two more for critical security fixes only, then it reaches end of life; on October 1, 2026, the oldest supported branch, 8.2, receives security fixes until December 31, 2026. Microsoft ended support for Windows 10 on October 14, 2025: devices still work, but no longer receive security updates outside Microsoft’s Extended Security Updates program. Any application tied to such a platform carries debt whose due date is public.
Knowledge debt is the one most often ignored. Recovering it starts with writing down where each rule lives. An assistant that answers from your internal documentation, like our knowledge assistant demo, then helps a new developer find it without interrupting the one person who knows.
What technical debt costs
Published estimates differ in method, but they agree on the order of magnitude: debt takes a large share of the time and money spent on software. Three sources, each with its limits:
- Developer time. In a 2018 survey run with Harris Poll among more than 1,000 developers and more than 1,000 C-level executives in the United States, the United Kingdom, France, Germany and Singapore, Stripe found that developers estimated spending 13.5 hours of a 41.1-hour week on technical debt, and 17.3 hours on maintenance overall, including debugging and refactoring. The survey is old and self-reported, which is worth keeping in mind.
- Share of systems. The UK government’s State of digital government review, published in January 2025, estimates that legacy technology made up 28% of systems in central government departments in 2024, up from 26% in 2023.
- Running cost. The same review notes that maintaining legacy systems often costs “three to four times that of modern alternatives,” citing contracts for maintaining COBOL systems at the UK tax authority.
None of these figures tells you the cost of your own debt. The useful number is local: how many days each typical change takes today, compared with what it would take in a clean system, multiplied by the number of changes your roadmap holds. That is Fowler’s four days against six, applied to your backlog.
How to measure technical debt
A credible measure combines a tool’s estimate of the code with the signals the business already sees. Static analysis gives the first part. SonarQube, a code analyzer, defines technical debt as the sum of the effort to fix all maintainability issues, and the debt ratio as that effort divided by the estimated cost of developing the code, with a default of 30 minutes per line. Its default maintainability rating goes from A, for a ratio of 5% or less, to E, at 50% or more.
The tool misses what is not in the code, so add four questions:
- How long does a typical change take, from request to production, and is it getting longer?
- How often does a release break something that was working?
- Which components are past or near their end of support, and when?
- Which parts does only one person understand?
A code audit answers these questions on your system with evidence: the analyzer’s figures, the list of dependencies and their support dates, and the parts of the code where change is slow. It ends with the risks ranked and a recommendation for each part of the software, and it runs under a confidentiality agreement.
Pay it down: refactor, replace or rewrite
Most debt is best repaid gradually, in the parts of the system you are changing anyway. Fowler recommends doing with technical debt what we usually do with financial debt: pay the principal off bit by bit, spending more cleanup time where the code changes most. The options, from lightest to heaviest:
| Option | When it fits | What to watch |
|---|---|---|
| Leave it and watch | Messy code that is stable and rarely touched | Nothing to repay as long as nobody needs to change it |
| Refactor as you go | Debt in code you modify often | Reserve a fixed share of each iteration; protect it with automated tests first |
| Upgrade the platform | A language, framework or OS near end of support | Plan it before the support date; upgrades across several versions grow fast |
| Replace one component at a time | An architecture that blocks change, a module nobody can maintain | The old and new parts run side by side for a while; plan the switch for each one |
| Rewrite | The platform is unsupported and cannot be upgraded, or the code no longer matches the business at all | Months without new features, and a risk of rebuilding the same problems |
A full rewrite is often the most tempting option, and the riskiest. Our modernization work starts from the opposite assumption: keep the system running, replace what slows you down first, and show progress every week.
Keeping debt under control once it is repaid
Debt comes back unless someone owns it: a maintenance plan with time set aside for it is what keeps a system cheap to change. The UK government’s guidance on purchasing technology makes the same point for public buyers: “To maintain a product and avoid creating technical debt and legacy technology, consider how you can do continuous improvement planning,” for example by automating deployment and testing the product regularly.
In practice, that means four habits: automated tests on the parts that matter, dependencies updated on a calendar, a debt register reviewed with the roadmap, and a share of each budget kept for cleanup. An application maintenance contract can carry all four, with the code, accounts and rights staying in your name. If you are deciding what to build next, our guide to custom software development cost shows the market’s ranges for maintenance as well as for the build.
Not sure how much debt your software carries? In a free 30-minute assessment, we look at your system with you, ask the four questions above and tell you where the interest is highest. The scope and price of any audit or modernization are then fixed in writing before we start. Book your free 30-minute assessment: we reply within one business day.
Frequently asked questions
What is technical debt in simple terms?
It is the gap between how a piece of software is built and how it should be built to change easily. Every shortcut, missing test or outdated component adds to the gap. The "interest" is the extra time each new change takes. Martin Fowler gives the example of a feature that would take four days in clean code and takes six: two days of interest.
Is technical debt always bad?
No. Debt taken on deliberately, to meet a launch date, can be the right call if the team knows it and plans to repay it. Ward Cunningham’s original point was that "a little debt speeds development so long as it is paid back promptly." Debt becomes a problem when nobody tracks it and it piles up in the code that changes most.
How do you measure technical debt?
Static analysis tools estimate the effort needed to fix maintainability issues. SonarQube, for instance, divides that effort by the estimated cost of writing the code and rates the result from A, at 5% or less, to E, at 50% or more. Add what tools cannot see: outdated dependencies, missing documentation, and how long changes take and how often they break.
What is an example of technical debt?
An application still running on a framework version that no longer receives security fixes. PHP, for example, supports each release branch for four years in total; after that, it reaches end of life and gets no more security patches. Moving to a supported version later, across many dependencies at once, costs far more than steady upgrades would have.
Should we rewrite the software to get rid of technical debt?
Rarely as a first move. A full rewrite freezes new features for months and often recreates old problems. The usual path is to measure, fix the debt in the parts that change most, replace the riskiest components one at a time, and keep the system running throughout. A rewrite makes sense when the platform itself is unsupported and the code cannot be upgraded.
Who is responsible for technical debt: developers or management?
Both. Developers create and see it; management decides whether time is set aside to repay it. The UK government’s review of 2025 reports that every organization it profiled cited not having enough appropriate funding to manage legacy technology and technical debt, and that most mentioned budgets favoring new programs over continuous improvement. Repaying it therefore needs a line in the budget.
Sources
- The WyCash Portfolio Management System (OOPSLA ’92 experience report), Ward Cunningham, c2.com, dated March 26, 1992, accessed October 1, 2026.
- Technical Debt, Martin Fowler, martinfowler.com, first published October 1, 2003, rewritten and dated May 21, 2019, accessed October 1, 2026.
- Technical Debt Quadrant, Martin Fowler, martinfowler.com, published October 14, 2009, accessed October 1, 2026.
- The Developer Coefficient: Software engineering efficiency and its $3 trillion impact on global GDP, Stripe, with Harris Poll, September 2018, accessed October 1, 2026.
- State of digital government review (CP 1251), UK Department for Science, Innovation and Technology, January 2025, accessed October 1, 2026.
- Understanding measures and metrics, SonarQube Server documentation, Sonar, accessed October 1, 2026.
- Supported Versions, The PHP Group, php.net, accessed October 1, 2026.
- Windows 10 support has ended on October 14, 2025, Microsoft Support, accessed October 1, 2026.
- Define your purchasing strategy (Technology Code of Practice, point 11), Government Digital Service and Central Digital and Data Office, GOV.UK, updated September 3, 2026, accessed October 1, 2026.