What Does Technical Debt Actually Cost?
A common rule of thumb is that technical debt eats 20–40 percent of a development team's time. For a team costing SEK 500,000 a month, that's SEK 100,000–200,000 every month spent handling old code instead of building something new. The debt shows up as slower delivery, more bugs, and higher estimates.
Technical debt never shows up as a line on the invoice – but it gets paid every month. It shows up as features that take three weeks instead of one, bugs that keep coming back, and quotes that get more expensive every year. Here’s how to put numbers on the debt, so it can be prioritized like any other cost.
What technical debt is, in plain business terms
Technical debt is the sum of shortcuts in code and architecture: solutions that were quick to build at the time, but that make every future change slower now. The loan analogy fits well. The shortcut is the principal, and the interest is the extra time the team pays every time they work in that part of the system. Just like with loans, the problem is rarely the debt itself – it’s that no one is tracking the interest.
What it costs: 20–40 percent of development time
A common industry rule of thumb is that 20–40 percent of development time goes toward handling technical debt instead of building new things. Translate that into kronor for your own team:
| Development cost per month | Cost of debt (20–40%) | Per year |
|---|---|---|
| SEK 250,000 (small team) | SEK 50,000–100,000/mo | SEK 0.6–1.2 million |
| SEK 500,000 (mid-size team) | SEK 100,000–200,000/mo | SEK 1.2–2.4 million |
| SEK 1,000,000 (multiple teams) | SEK 200,000–400,000/mo | SEK 2.4–4.8 million |
The numbers are ranges and vary with the codebase’s age and condition – but even the low end equals a full-time developer who does nothing but pay interest, year-round.
How the debt shows up in quotes and invoices
The debt is invisible in the books but fully visible in the patterns, if you know where to look:
- Slower delivery. Changes that “should be simple” take weeks. Lead time for similar tasks grows year after year.
- More bugs. A growing share of billed time goes to fixes and firefighting instead of new functionality.
- Higher estimates. Vendors pricing a tangled codebase add a risk markup – you pay for the uncertainty, not just the work.
- Dependency on individuals. Only one or two people dare touch certain parts of the system. Their calendar becomes your bottleneck.
Worked example: when does refactoring pay off?
Say a type of feature you build often – new integration flows, say – takes three weeks in today’s codebase, and a SEK 300,000 refactoring would bring that down to two weeks. A developer-week at an agency costs roughly SEK 40,000–55,000.
If you build ten such features during the year, the refactoring saves ten developer-weeks, or SEK 400,000–550,000. The investment pays for itself within the year, and after that the saving is pure profit – plus every feature reaches users a week earlier. The same math can flip: if you only build two such features a year, the refactoring isn’t justified yet. That’s how debt should be prioritized – item by item, against actual usage. Run the math per debt item, not for “the debt” as a whole; that’s the difference between a decision basis and a general sigh.
Make the debt visible and manageable
The debt doesn’t disappear if you ignore it, but it doesn’t need to be “paid off” in one big stop-everything project either. Three habits go a long way:
- List the debt. Have the team rank the ten most expensive debt items with an estimated interest rate. Now the debt is a decision basis, not a feeling.
- Set aside a fixed share. A common benchmark is 10–20 percent of each sprint for paying down debt, prioritizing the parts of the code that change most often.
- Measure lead time. Track how long similar changes take over the year. If lead time drops, the refactoring is working; if it rises, the debt is growing faster than you’re paying it down.
At Weapp we work daily in both new and inherited codebases, and the pattern is clear: teams that budget for debt deliver faster over time than those who keep pushing it ahead of them. Want a second opinion on what the debt is costing your system? Get in touch.
Frequently asked questions
Is all technical debt bad?
No. Deliberately taken-on debt can be exactly the right call – a first product version that cuts corners to reach the market fast is a classic and sound trade-off. The problem is unconscious or unmanaged debt: shortcuts no one remembers, that no one budgets for, and that grow with interest.
How do I know how much technical debt we have?
Look at the symptoms rather than the code: lead time for small changes increases, bug fixes eat a growing share of the time, estimates for similar tasks get higher every year, and more and more changes require one specific person. Ask the team to list the ten most expensive debt items with an estimated cost – that's usually enough to decide on.
Should we rewrite the system from scratch instead?
Rarely as a first choice. A full rewrite is expensive, takes a long time, and often freezes further development in the meantime. Incremental refactoring – improving the parts that change most often – pays off sooner and with less risk. A rewrite is justified only once the platform is actively blocking the business.
Why do quotes get more expensive when the codebase carries a lot of debt?
Vendors price uncertainty. A hard-to-read codebase without tests makes every estimate less certain, and that uncertainty ends up as a risk markup in the quote. The debt also means fewer vendors want to bid on the work, which weakens your negotiating position.
Can AI tools reduce the cost of technical debt?
Partly. AI-assisted development can speed up refactoring, test writing, and documenting old code, which lowers the price per debt item resolved. But the tools don't remove the need for prioritization – which debt gets paid down, and when, is still a business decision.