Technical debt – what it is and how much it costs your business

Technical debt – what it is and how much it costs your business

Every software project starts "carrying weight" after a certain time. New features come in slower, fixes generate more bugs, and programmers talk more often about "cleaning up". These are the effects of technical debt – on the vollelabs blog we explain what it is, where it comes from, and what to do with it before it starts generating losses.

What exactly is technical debt?

The term was coined by Ward Cunningham in 1992. He was searching for a way to explain to non-technical people in the company why it's necessary to spend time fixing existing code instead of building new features.

The metaphor is simple: technical debt works like a loan. When a team of programmers chooses a fast solution at the expense of quality – it "borrows time". A form of "debt" is created that has to be paid back in the future, and which – like financial debt – incurs "interest": future changes become harder, slower, and more expensive.

A simple example: an online store needs discount code support for yesterday. The programmer hard-codes the logic in one place, without separating a designated module. Does it work? It works. But three months later, when you have to add multi-use codes, percentage codes, and time limits – this piece of code turns into a minefield. Any change risks breaking something else.

Where does it come from?

Technical debt is not always the result of laziness. It can be conscious and unconscious.

Conscious debt – the team deliberately chooses a simpler solution to hit the market faster. Teams knowingly pick faster solutions to make a deadline, with a plan to refactor later. This approach can generate business value if managed well.

Unconscious debt – accumulates through knowledge gaps, bad practices, or lack of documentation. Due to its unplanned nature, this form typically generates higher long-term costs and grows faster.

There are also systemic factors: business pressure for fast results, team turnover (the new programmer doesn't know the context of their predecessor's decisions), lack of code reviews, and recently – also automatic code generation by AI without proper verification.

How much does it cost? Data from reports

Before you wave it off – some numbers.

According to the Stripe "The Developer Coefficient" report from 2018 (more recent data on such a scale is not publicly available), an average programmer spends 13.5 hours answering technical debt and an additional 3.8 hours fixing bad code weekly. That's a total of 17.3 hours out of a 40-hour work week – about 42% of the time.

According to Accenture, in the United States alone, technical debt costs $2.41 trillion annually, and fixing it would require $1.52 trillion. Data comes from the Digital Core report published on accenture.com.

In turn, a study by Pegasystems from October 2025 (a survey among over 500 IT decision-makers worldwide, conducted by Savanta) shows that the average global enterprise loses over $370 million annually due to the inability to efficiently modernize outdated systems.

And if you run a smaller company? A Sonar study from 2023, based on an analysis of over 200 projects, calculated that the attributable cost of technical debt is $306,000 per year for a project the size of a million lines of code. This is the equivalent of 5,500 programming hours that could have been spent on new features.

How much budget should be allocated for repayment?

According to Accenture research, companies should allocate about 15% of their IT budget to fixing technical debt, especially for new projects. An Oliver Wyman analysis showed that only a few companies reserve the recommended 15–20% of their budget for this purpose. Most companies take no action until the problem grows, and then they have to spend even 30–40% of their budget on massive transformation programs.

Conclusion: regular repayment is cheaper than a one-time rescue.

How to measure technical debt yourself

This is a section you can apply today. We've divided it into two levels: what you can do yourself, and what requires a specialist.

Level 1: Do it yourself (without a programmer's help)

Step 1 – Ask the team. At the next meeting, ask one question: "What percentage of your time is spent fixing old things instead of building new things?". Write down the answer. If you hear "30% or more" – it's an alarm bell.

Step 2 – Check data in Jira / GitHub Issues. Review tasks from the last 3 months. How many of them have the label "bug", "rework", or "tech debt"? Tools like Jira or GitHub Issues allow you to track tasks marked as "technical debt" or "rework", helping you estimate the time spent on debt repayment.

Step 3 – Calculate a simple ratio. Divide the number of hours spent on fixes and maintenance by the total number of developer hours. If 40% of the team's time goes to maintenance and half of that stems from technical debt, your interest rate is 20%. Sample formula: %Loss = (maintenance hours / total development hours) × (% resulting from technical debt).

Level 2: Analysis with tools (programmer needed)

SonarQube – a free open-source tool for static code analysis. It calculates the Technical Debt Ratio as the ratio of repair cost to code creation cost, according to the formula: technical debt / (cost of writing one line × number of lines of code). After connecting the repository to SonarQube, you receive a rating from A (best) to E (worst) in three categories: reliability, security, and maintainability.

How to run it:

1. Download SonarQube Community Edition from sonarqube.org.
2. Start the server locally (docker run -d --name sonarqube -p 9000:9000 sonarqube:community).
3. Create a project, add SonarScanner to your CI/CD pipeline.
4. After the first scan – open the "Measures" → "Maintainability" tab. There you will see the debt expressed in hours and the Technical Debt Ratio in percentages.

Alongside SonarQube, it is worth exploring DORA (DevOps Research and Assessment) metrics: deployment frequency, lead time for changes, change failure rate, and time to restore service – drops in these metrics point to growing friction resulting from technical debt.

What to do – the repayment strategy

You don't have to halt product development to repay the debt. Three approaches work best:

1. The "clean what you touch" rule – If a programmer modifies a piece of code, they should leave it in a better state than they found it. A slight refactor alongside every task. Sonar calls this approach "Clean as You Code": organizations should implement this methodology to catch issues in code being added or changed – before they hit production. This frees programmers from having to dedicate cycles to fixing old code and lets them focus on new features.

2. Dedicated budget in every sprint – reserve 15–20% of the team's capacity for tasks that are typically "repayments". Not as a separate project, but a constant element of planning.

3. Large surgical interventions – sometimes one module is so indebted that small patches won't cut it. Then a dedicated sprint is needed to rewrite that part of the system.

What you shouldn't do on your own

Some things require experience:

• The rewrite vs. refactor decision – poorly drawing the line leads either to wasting time patching something that should be thrown away, or rewriting code that just needed to be cleaned up.
• Architectural debt assessment – problems at the system structure level (e.g. a monolith that should be broken down into services) are not visible in SonarQube. Here you need an audit from someone who knows your tech stack.
• Repayment prioritization – not every debt is worth paying off. A module that won't be developed further can live "in debt" with no consequences. A business evaluation, not just technical, is needed.

Frequently asked questions

What is technical debt in simple terms? It's the cost of future repair work that arises when a team of programmers chooses a faster but lower-quality solution. Analogy: it's like a loan – you borrow time now, but you pay it back later with interest in the form of slower development and more frequent bugs.

How do I check if my project has technical debt? The simplest test: ask programmers what percentage of their time they spend fixing old problems instead of building new features. If the answer exceeds 25–30%, the debt is getting serious. For a more detailed analysis, connect your project to SonarQube – the tool will show your Technical Debt Ratio and pinpoint specific places in the code to fix.

Can technical debt be completely eliminated? No, and that's not the goal. A certain level of debt is natural in every project – just like companies use loans to grow. The problem starts when the debt grows faster than the team's ability to pay it off. The goal is to keep it at a controlled level.