Technical debt is the future cost of shortcuts taken today in software: quick fixes, skipped tests, missing documentation, or structures that suited the first release but not the tenth. Some debt is deliberate and sensible in an early product. It becomes dangerous when every change takes longer than the last, when bugs reappear, when the team avoids parts of the code, or when nobody can say where the debt is. The cure is a written list, a share of every release spent paying it down, and a refusal to let it accumulate unseen.
In plain terms
Technical debt is like a loan taken against the codebase. You borrow time now by building something the quick way, and you pay interest later in the form of slower changes and more bugs. Like a loan, it is useful if taken deliberately for a good reason and repaid on a schedule, and destructive if it accumulates unnoticed until the interest exceeds what the team can produce.
What does it look like?
- Shortcuts in the code. A quick fix that works for now but will break when the data grows or a new case appears.
- Missing tests. Changes cannot be verified automatically, so every change risks breaking something unseen.
- Missing documentation. Knowledge lives in one person's head. When they leave, so does it.
- Outdated dependencies. Libraries and frameworks not updated, accumulating security issues and making eventual upgrades painful.
- Structures that no longer fit. A data model built for one user type when there are now three. A backend built for a hundred users serving a hundred thousand.
- Copy and paste. The same logic in several places, so a fix in one leaves bugs in the others.
Is all technical debt bad?
No. An early product should carry some deliberately. Building a first release to handle scale it does not have, cases it has not seen and integrations it may never need is a different kind of waste. The distinction is between debt that is chosen, recorded and scheduled for repayment, and debt that accumulates because nobody is looking. Investors and experienced engineers expect the first kind and worry about the second. Our post on what investors want to see in your tech explains why a documented debt list is a strength.
When does it become dangerous?
| Sign | What it means |
|---|---|
| Every change takes longer than the last | Interest on the debt is now larger than the work itself |
| Bugs fixed once come back | Duplication or missing tests |
| The team avoids certain parts of the code | Those parts are fragile and nobody fully understands them |
| Simple features are quoted as large projects | The structure no longer fits the product |
| Nobody can list where the debt is | It is unmanaged, which means it is growing |
| Security updates are being skipped | Risk is accumulating along with cost |
How do you manage it?
- Keep a written list. Every known shortcut, with a sentence on why it was taken and a rough cost to fix. This is the single most important step, and it is free.
- Spend a share of every release on repayment. Ten to twenty percent of each development cycle on the highest-interest items. Small, continuous, and invisible to users.
- Pay it down where you are about to build. Before adding a feature to a fragile area, fix the area. It is cheaper than building on sand.
- Keep dependencies current. Small regular updates instead of a large painful one every two years.
- Avoid the big rewrite. A rewrite trades known debt for unknown debt and stops feature work for months. Modernise by slice instead, as described in modernisation without the big bang.
Questions to ask your development team
- Where is our technical debt list, and what is at the top?
- What share of each release goes to paying it down?
- Which parts of the code would you be nervous to change, and why?
- When were dependencies last updated?
Related terms
Frequently asked questions
Does a good development team produce no technical debt?
No. A good team produces deliberate debt, records it, and tells you about it. A team that claims to produce none either does not know where it is or is not telling you.
Should I pay off all technical debt before launching?
No. Pay off what threatens the core journey, security or the ability to change quickly. Leave the rest on the list. Launching is how you find out which debt matters.
How do I know if a rewrite is really necessary?
Rarely is it. Get an independent assessment before agreeing to one. Most products that seem to need a rewrite need targeted modernisation of two or three areas, which costs a fraction and keeps the product shipping meanwhile.