Technical Debt: What It Costs and How to Pay It Down

Two years ago, your development team could deliver a feature in two weeks. Today it takes six. The team is the same, the project is the same, and yet everything is slower. That is not laziness, that is technical debt.

Software systems in mid-sized companies are often between five and fifteen years old. They were built on the assumptions of their time and maintained with the tools of the developer generation that worked on them. The consequences usually become visible only when they hurt. In maintenance costs, in delivery times, in attrition, in growing dependence on a few people who still understand the system.

This article is a stocktake of technical debt in mid-sized companies, with verified numbers, clear definitions, and realistic paydown strategies. It is not an introduction to refactoring patterns, not a call for a complete rewrite, and not a polemic against legacy systems. It is an honest look at what tech debt really costs, how to recognize it, and which mechanisms actually help.

What Tech Debt Really Is

The original metaphor comes from Ward Cunningham in 1992. Technical debt is like financial debt. Taken on, it enables quick action. Not paid down, it accrues interest that grows disproportionately over time. Whoever ignores the interest ends up paying more than the original principal.

That is the metaphor. The boundary is more important, because the term is used too generously in everyday work. Not every bug is tech debt. Not every piece of complexity is tech debt. Not every line of old code is tech debt. Code that has been running stably for fifteen years and does its job is not a debt. It may be unfashionable, but that is a different question. Tech debt is also not everything that could be done better. Otherwise every piece of software would be in debt at every moment.

Tech debt is code or architecture whose continued maintenance is systematically more expensive than necessary. Decisions that were acceptable at the time but whose follow-on costs now weigh on the team. Documentation gaps, missing tests, hardcoded assumptions that no longer hold. In other words: friction that could demonstrably be reduced and where the reduction pays for itself. If both are not given, it is not a debt but a property.

Martin Fowler's Tech Debt Quadrant

The most important classification in this field comes from Martin Fowler. He divides tech debt into four quadrants along two axes. Deliberate versus inadvertent on one axis, prudent versus reckless on the other.

	Prudent	Reckless
Deliberate	"We ship now, refactor later, and we have a plan for it"	"We don't have time for design"
Inadvertent	"Now we understand how it should be done"	"What is layered architecture?"

Deliberate and prudent is legitimate tech debt. Time-to-market over code beauty, with a paydown plan, a window, and a budget. This debt often pays off. A company that polishes architecture for six months while the competitor sells the product has a bigger problem than code built too quickly.

Deliberate and reckless is the most common source after failed projects. Speed without a plan, without responsibility, without a return mechanism. "We'll do this quickly and take care of it later" rarely becomes "we actually took care of it later".

Inadvertent and prudent is the unavoidable variant. The team builds something, learns while working, and realizes at the end that a different architecture would have been better. That is normal learning. This debt is not avoidable but part of honest software development.

Inadvertent and reckless is the stomachache class. The team does not know what it does not know. It typically occurs in heavily understaffed teams, with junior developers without mentors, or in AI-generated codebases without review. The debt is often discovered only years later, usually by someone who did not cause it.

The central insight: not every tech debt is equally problematic. Deliberate-prudent is legitimate. Inadvertent-prudent is learning. Deliberate-reckless should never happen. Inadvertent-reckless is what quietly breaks companies over years.

What Tech Debt Really Costs

Research from the past years delivers consistent numbers from various sources. They are uncomfortable, but precise.

McKinsey estimates that tech debt accounts for twenty to forty percent of total tech-estate value before depreciation. For companies with low tech debt, revenue growth is up to twenty percent above comparable companies with high tech debt. Actively managed tech debt allows engineering teams to spend up to fifty percent more time on business-critical work, according to McKinsey. That is not an efficiency statistic, that is a balance-sheet statement.

The Stripe Developer Coefficient from 2018, methodologically one of the most solid studies of its kind, shows that thirty-three percent of developer time goes into maintenance, and up to forty-two percent in growth-stage startups. The original study estimated the global productivity loss at around three hundred billion US dollars per year. The number is old, but the pattern is consistent.

The JetBrains State of Developer Ecosystem 2025 confirms this with more recent data. Engineers lose between two and five working days per month to tech debt, the equivalent of up to twenty-five percent of the engineering budget. The Stack Overflow Developer Survey 2024 adds the qualitative side. Sixty-two percent of developers name tech debt as their biggest frustration on the job. Frustration is not an engineering metric, but it is a reliable indicator of attrition risk.

A CISQ estimate expects that by the end of 2025, around forty percent of IT budgets will be consumed by maintaining existing technical debt. A 2024 survey by Morning Consult and Unqork shows that at eighty percent of enterprises, tech debt actively slows innovation.

The numbers are not milder in the German Mittelstand. A Bitkom study on digitization 2024/2025 shows that fifty-nine percent of mid-sized companies struggle with outdated IT infrastructure, while at the same time sixty-eight percent find it hard to hire qualified IT staff. This combination makes tech debt structurally more expensive in mid-sized companies than in large corporations with dedicated platform teams. Those who have the problem also do not have the people to solve it.

The direct costs (developer time) are only one part. Add slower time-to-market, higher error rates, harder hiring (good developers flee from legacy stacks), and in regulated industries a growing compliance risk because security patches on old stacks become harder to enforce. The balance sheet regularly turns out worse than the engineering view suggests.

The Five Most Common Sources in Mid-Sized Companies

Tech debt does not arise by accident. In the German Mittelstand, five sources account for most of the problem.

The grown ERP add-on. Over five to ten years, custom development accumulates on SAP, Microsoft Dynamics, abas, or comparable systems. Custom code lives in reports, workflows, and integrations that nobody fully understands anymore. The paydown difficulty is high because the ERP is business-critical and every change carries risk. At the same time, tech debt is particularly expensive here, because a major upgrade or migration depends on the level of customization.

The home-grown platform from 2014 to 2017. PHP, Ruby on Rails, Java, or .NET Framework. Built when the business was still "small", today production-critical. Tests are rare, documentation is outdated, the original architect now works somewhere else. This source is the textbook case for the Strangler Fig Pattern.

The quick MVPs that were never reworked. "We'll just build this in two weeks" became production software. Often missing: authentication hardening, logging, monitoring, backup strategy. The question of build versus buy gets asked retroactively about these systems, often with uncomfortable answers.

Vibe coding results (a new class since 2023). Code generated with AI assistants without deep review. This source has its own symptoms and dynamics that fill a dedicated article on code quality in AI-generated code. Important: quickly produced code is not automatically worse, but unreviewed code regularly is, because nobody has checked the implicit assumptions.

The overlooked dependency gap. Frameworks, libraries, and language versions are years behind the current state. Security patches are not applied because the major upgrade means effort. Typical symptoms: PHP 7.4 in production (end of life November 2022), Node 16 (end of life September 2023), .NET Framework 4.x without migration to .NET 8. Standards and language versions are not a wellness topic for exactly this reason. They are a balance-sheet position.

How to Recognize Tech Debt in Daily Operations

Tech debt does not show up in code review. It shows up in the team's daily work. Seven reliable symptoms appear regularly.

First, "nobody dares to touch this". A specific module or file area is systematically avoided. Tasks in that area always land with the same senior developer or stay forever in the backlog.

Second, bug fixes lead to new bugs. The error rate per fix grows over time. Fixing one bug introduces, on average, half another. That is a direct symptom of coupling and missing tests.

Third, time-to-market grows by twenty to fifty percent per year. What took two weeks three years ago now takes six. If it is not explained by a recognizable increase in complexity, it is tech debt.

Fourth, manual releases instead of CI/CD. If deployment is "experience-based", it is tech debt. If only one person understands the release script, it is tech debt with an added personnel risk.

Fifth, senior developers quit. Good people flee from stagnation. High turnover in senior ranks is a symptom, not a personnel problem.

Sixth, onboarding takes four months instead of four weeks. New hires need disproportionately long to become productive. Code clarity and documentation quality show up directly in this number.

Seventh, "we can't change this without breaking X". The list of sentences starting with "we can't" grows longer. Each of these constraints is an implicit debt position.

Whoever observes three or more of these symptoms in their own team has substantial tech debt, regardless of whether it is officially named as such.

How to Measure and Account for Tech Debt

Without measurement, no management. Tech debt without numbers remains an engineering complaint that loses in the budget conversation. Six metrics work pragmatically in mid-sized companies.

Cycle time per feature is the most important. How long does the team take from idea to production, measured over six months? A rising trend is a warning, a doubling over twelve months is an alarm.

Change failure rate, the share of deployments that lead to rollbacks or hotfixes. Industry-typical numbers should stay below fifteen percent. Whoever is above usually has a testing or architecture problem.

Time-to-first-commit for new hires. An indicator for code clarity and onboarding quality. A senior developer who has not made a productive commit after eight weeks says more about the codebase than about the hire.

Share of sprint capacity going into unplanned bug fixes. Above twenty percent is a warning sign. Above forty percent is a clear signal that engineering spends most of its time repairing problems built yesterday.

Static analysis results. SonarQube, CodeScene, Codecov, or comparable tools deliver imperfect but consistent numbers. The absolute value matters less than the trend over time.

Dependency lag. How many major versions is the team behind the current state for each critical library? Measure per library, sum them. This number is surprisingly informative and brings security risks into the conversation as well.

Balance-sheet view: Tech debt should appear in IT governance as a dedicated position. McKinsey recommends carrying it on the tech balance sheet parallel to asset value. In mid-sized companies a quarterly document with three columns is usually enough. Identified debt, estimated effort for paydown, risk if not paid down. This document is the basis for every budget conversation about refactoring or modernization.

Strategies That Actually Work

Four mechanisms are consistently successful in both research and practice. They share one property: they are structural, not episodic.

Boy Scout Rule

The rule: leave every file cleaner than you found it. No dedicated refactoring sprints, no stakeholder approval, just incremental improvement in every pull request. Works particularly well in teams that do code review per PR anyway.

Realistic effect: five to fifteen percent reduction of tech debt per year without additional budget, purely through a changed team norm. The rule is banal, but that is exactly why it works. It needs no approval, no project, no meeting. It needs only discipline in the team and code reviewers who insist on it.

Strangler Fig Pattern

Coined by Martin Fowler. Instead of a risky big-bang rewrite with six to twelve months of feature freeze, the new system is built incrementally around the old one. Specific traffic flows are redirected step by step, the old system is shut down section by section.

Advantages: significantly higher success rate than a rewrite, business operations continue, the new architecture is validated with real traffic before the full cut-over. This is the standard solution for the "platform from 2014" source. It is also the pattern that comes into play in many modernization projects on the LEMP stack, when old PHP applications are decoupled step by step.

The name comes from the strangler fig, a tree that wraps itself around a host, uses it until it can stand on its own, and then lets the original tree die. That is visually unpleasant and conceptually precise.

20 Percent Time Allocation

Fifteen to twenty percent of every sprint's capacity is reserved for tech debt, refactoring, test coverage, dependency upgrades, documentation, and CI/CD improvements. Not for features.

This works only with two conditions. First, that management understands the twenty percent as an investment, not a loss. Second, that the twenty percent happen in every sprint, not "when it gets quieter". Whoever drives the share permanently to zero accrues further debt linearly.

The temptation to drop the share to zero under delivery pressure is strong and usually wrong. Over twelve months, the non-reduction of tech debt costs more delivery capacity than the twenty percent would have cost. That is the unpleasant arithmetic that regularly gets lost in budget discussions.

Architectural Decision Records

A written practice: every significant architecture decision is captured in a short document with date, context, considered alternatives, and rationale. This prevents two common tech-debt sources. Repetition of the same mistakes and loss of the knowledge of why a decision was made the way it was.

Effort per ADR: thirty minutes. Benefit: over years. Management or technical leadership wanting to know why an architecture looks the way it does finds the answer in the ADR instead of in the heads of people who have long left the company.

When Tech Debt Is OK

Not every tech debt should be paid down immediately. Three situations where it is legitimate.

In the market-entry phase, time-to-market beats architectural elegance. With a clear paydown plan in the backlog, with an owner, with a window. A company that achieves market entry in twelve months with three refactoring weeks in the second year regularly beats the company delivering a technically perfect product after eighteen months.

In hypothesis validation, MVP, prototype, and proof-of-concept are the standard. Code that will likely be thrown away does not need to be built to SOLID principles. The only thing that matters is that the team knows this code is throwaway code and does not secretly survive for the next five years.

For sunsetting components, investment in code that will be turned off in twelve months is wasted. Security patches and stabilizing measures yes, structural improvements no.

The rule: tech debt is OK when it is deliberately taken on, documented, and paired with a paydown plan. It is not OK when it is the result of recklessness, time pressure, or ignorance.

Anti-Patterns

Seven patterns that recur and regularly fail.

The big-bang rewrite. Three to fifteen months of feature freeze, ending in a new system with its own bugs. The success rate in the research literature is below thirty percent. Typical course: the project takes twice as long as planned, the old system keeps running, the new system has its own tech debt, the team is exhausted.

Refactoring weeks without follow-up. One week per quarter where "the debt gets paid down", without structural anchoring. After the refactoring week, features are delivered, new debt arises, the backlog grows. Theater.

Tech-debt backlog without an owner. A growing list in Jira that nobody prioritizes. Tickets expire, new ones come in, the backlog becomes a cemetery list.

Outsourcing the paydown. External developers pay down the tech debt without knowledge transfer to the internal team. The knowledge leaves the company with the contract. The tech-debt problem returns after twelve months because the internal team understands the new architecture as little as the old one.

Framing tech debt as a pure engineering problem. If management does not understand tech debt, it does not provide budget. Without budget, no paydown. Whoever does not translate tech debt into balance-sheet language will not get it financed.

"We'll do it in the next sprint". The honest balance after eighteen months shows that "the next sprint" never came. This statement is a reliable indicator that the debt will not be paid down.

Best-practice adoption without context. Microservices decomposition of a mid-sized application because "Netflix does it that way". Most mid-sized companies need two to five clean services, not distributed monolith chaos. Whoever copies Netflix without having Netflix problems builds next-generation tech debt.

The Mid-Sized Reality: Who Owns It?

Recognizing tech debt is an engineering task. Assessing tech debt is a technical leadership task. Paying down tech debt is a management decision.

When these three roles are not clearly assigned, the usual happens. Developers complain, the tech lead prioritizes internally, management sees symptoms like slow delivery without recognizing the cause in old substance. The discussion goes in circles, the budget stays absent, the debt grows.

The responsibility for architecture and IT strategy in mid-sized companies rests with technical leadership that translates between the three layers. Engineering knowledge into management language, management priorities into engineering roadmap. This translation is the central task and in many mid-sized companies the missing role.

Without this translation, tech debt becomes a generational mortgage. Each generation of developers works on paying down the debt of the previous one, without anyone strategically deciding what stays and what goes. The result is a codebase that gets partially understood every few years through staff changes but never systematically renovated.

Seven Questions for a Status Check

These seven questions sort out the situation in practice, often better than a longer audit.

1. When was your most important software component built, and how much of it is still actively in use today?
2. What share of sprint capacity flows today into unplanned bug fixes and maintenance?
3. Which three components does your team systematically avoid, and which people can still safely touch them?
4. How many major versions are your most important frameworks and libraries behind the current state?
5. Does your organization have a documented process for architecture decisions (ADRs), or do these live in individual heads?
6. Which tech-debt items have you identified, with effort estimates and risk if not paid down?
7. Who in your organization is responsible for allocating sprint capacity to tech-debt paydown, and how is the budget justified?

Whoever cannot give a credible answer to five or more of these questions has substantial blind spots in the tech-debt balance sheet. That is not an accusation, it is a diagnosis.

Conclusion

Tech debt is reality, not failure. It is the consequence of decisions that made sense at the time. The cited studies are uncomfortable, but precise. Twenty to forty percent of tech-estate value and thirty-three to forty-two percent of developer time typically go into maintenance instead of innovation.

In mid-sized companies, the structural hurdles add skilled-labor shortages and grown systems from the 2010s. Whoever runs an old ERP, a home-grown platform, or a PHP application from 2015 often has the double problem. Too much tech debt and too few people to pay it down.

Paydown does not work through refactoring weeks or big-bang rewrites. It works through structural mechanisms. Boy Scout Rule, Strangler Fig Pattern, a fixed sprint share, documented decisions. The most important question is not "how do we get to a hundred percent clean codebase", but "how do we prevent the debt from slowing down the business model over the next two years".

Whoever does not measure tech debt cannot pay it down. Whoever does not communicate it does not get budget. Whoever does not define accountability pushes it onto the next generation. These three sentences are banal and regularly overlooked in practice.

---

You have the impression that your software is getting slower without knowing why, or you are planning a modernization project? Contact me for a technical audit that clarifies tech-debt balance, paydown strategy, and budget frame in two to three days.