Technical debt is the extra work created when software is built or changed in a way that is quicker today but makes future changes slower, riskier or more expensive. The term compares shortcuts to borrowing money. You get something sooner, then pay "interest" every time someone has to work around the shortcut, until the underlying problem is fixed.
For a business that commissions a website, app or internal system, technical debt affects how quickly you can respond to customers, how much each change costs and how safely the system can be kept up to date.
Where technical debt comes from
Most systems carry some debt. It builds up from ordinary decisions, for example:
- Rushed deadlines: a feature is launched with a quick workaround, planned to be tidied up later, and later never arrives.
- No automated tests: without tests, every change has to be checked by hand, so developers avoid touching fragile areas.
- Outdated frameworks and dependencies: libraries, frameworks and server software keep moving. Each skipped update makes the next one bigger.
- Copy-paste code: the same logic is duplicated in several places, so one rule change has to be made, and tested, several times.
- Missing documentation: knowledge of how the system works sits with one person or one former vendor.
- Unsupported plugins and themes: common on websites. When a plugin is abandoned by its author, it stops receiving fixes, including security fixes.
Symptoms a non-technical owner will notice
You do not need to read code to spot technical debt. Common signs include:
- small changes, such as a new form field or a price rule, take far longer than expected;
- fixing one problem breaks a feature somewhere else;
- new developers need a long time before they can make changes safely;
- security patches and version upgrades are postponed because "it might break something".
Deliberate and accidental debt
Not all technical debt is a mistake. Deliberate debt is a conscious trade-off: for example, launching an MVP with a simpler design to test demand, knowing that part will be rebuilt if the idea works. This can be a sensible business decision if it is written down and planned for.
Accidental debt builds up without anyone choosing it: the team did not know a better approach, requirements changed after the design was set, or the software simply aged. It is usually harder to manage because nobody has recorded where it is.
How to manage technical debt
The aim is not zero debt, but debt that is known, limited and paid down on purpose. Practical habits include:
- Keep an inventory: a simple list of known shortcuts, outdated components and fragile areas, with the business impact of each.
- Budget time each release: reserve part of each development cycle for clean-up rather than waiting for a large project.
- Add automated tests: regression testing on key flows makes it safer to change and refactor code.
- Update dependencies regularly: small, frequent updates are easier to test than one large jump after years.
- Refactor: improve the structure of existing code without changing what it does, ideally in small steps alongside feature work.
- Document: record how the system is set up, deployed and connected to other services.
- Use code review and automation: a second developer reviewing changes, plus a CI/CD pipeline that runs tests automatically, helps stop new debt slipping in.
Repay, live with it, or rebuild?
Not every piece of debt needs fixing. A useful way to decide:
- Repay when the debt sits in a part of the system you change often, or when it blocks security updates.
- Live with it when the affected area is stable, rarely changed and low risk. Note it in the inventory and review it later.
- Rebuild when the core platform is no longer supported, most changes are slow and risky, and repairs would cost close to a new build. A rebuild carries its own risks, so it is usually safer to replace the system in stages and keep the old one running until each part is proven.
How to discuss technical debt with your vendor
Ask your developer or support provider to explain debt in business terms. Useful questions include:
- Which parts of the system are hardest or riskiest to change, and why?
- Which frameworks, plugins or server components are out of date or unsupported?
- What would you fix first, and what would it make faster or safer?
- How much time per release do you suggest for maintenance and clean-up?
- How are tests, documentation and code reviews handled today?
If you have an ongoing support agreement, it helps to state who is responsible for dependency updates and security patches. Our article on software support SLAs covers what such agreements usually include, and our Managed Support and SLA service handles this kind of ongoing maintenance.
Frequently asked questions
Is technical debt always bad?
No. Taking on debt deliberately, for example to launch sooner and test an idea, can be the right choice. Problems arise when debt is not recorded and never repaid.
Can a non-technical owner measure technical debt?
Not precisely, but you can watch the signs: how long small changes take, how often releases cause new problems, and how many components are past their supported versions. Ask your vendor to report these regularly.
Will a rebuild remove technical debt?
Only for a while. A new system starts with less debt, but without tests, documentation, updates and review it will build up again.
Does technical debt affect security?
It can. Outdated dependencies and unsupported plugins may stop receiving security fixes, and fragile code makes teams slower to apply patches.