Skip to content
Glossary term

Technical debt

Technical debt is the extra work that comes back later from shortcuts taken in software. Like a loan, it carries interest: the longer a shortcut stays unfixed, the slower and more expensive every new feature becomes. Some debt is normal. What matters is taking it on knowingly and tracking it.

What is technical debt?

Technical debt is the built-up cost of shortcuts taken to move fast in software. A feature shipped without tests, code copied and pasted, a library left un-updated, a fix labelled "good enough for now": all of these are technical debt. They save time today. The interest is paid later.

Here is an everyday case. Your online store calculates discounts in five separate places. At launch that was quick. Now you want a new type of campaign. The developer has to find all five places, change them and test each one. A one-day job takes a week. If one is missed, the basket shows one price and the invoice another.

Why does it matter?

Technical debt is invisible, but its symptoms are not. Small changes take ages. Fixing one thing breaks another. A new developer struggles to understand the code. Debt never reaches zero, but it can be managed: shortcuts are taken on purpose, written down, and part of the list is paid off in every work plan. When we pick up an unfinished project or one from another team, we start by measuring this debt. See our project takeover service and how to rescue an unfinished software project.

Frequently asked questions

01

Is technical debt always bad?

No. Debt taken on knowingly to test an idea quickly can make sense. The problem is debt nobody knows about and nobody ever pays back.

02

How can I tell if my software has technical debt?

If small changes take longer than expected, every update brings new bugs and the team avoids touching certain parts, there is probably built-up debt.

03

Do we need to rewrite everything to fix it?

Usually not. Debt is paid down piece by piece, starting with the part that causes the most trouble. A rewrite only makes sense when nothing can be safely added to the existing code.

Contact

Tell us about your project.

We reply within one business day. Three sentences are enough.

Write to us

723563

You know the code.

The door is open. One email is enough, we take it from there.