Technical debt is the extra work a software system will need in the future because of shortcuts, compromises or outdated choices made in its code and design today. Like financial debt, it can be a reasonable way to move faster now, but it carries interest: later changes tend to take longer, break more easily and need more testing until the debt is paid down by improving the code. The term usually refers to software, including custom code, integrations and heavily customized commercial platforms.
At a glance
- Technical debt is the gap between how software is built and how it would need to be built to be changed easily and safely.
- It comes from rushed code, missing tests, poor documentation, outdated components and heavy customization.
- Its “interest” shows up as slower changes, more defects and harder upgrades.
- Some debt is a deliberate, sensible trade-off; untracked debt is the kind that tends to hurt.
- For buyers, it affects what you inherit from vendors and what future changes will cost.
What problem it solves
Software teams constantly trade speed against quality. A deadline is met by skipping tests, a feature is bolted on instead of designed in, or a library is left on an old version because upgrading would take a week. Each choice is defensible on its own. Over time they combine into a codebase where a simple change takes weeks, nobody wants to touch certain areas and fixes cause new problems.
Naming this as technical debt helps non-developers understand why a system has slowed down and why spending money on work that adds no new features can still pay off. It turns a vague complaint, “the code is a mess”, into something that can be listed, estimated and prioritized against new work.
How it works
Where it comes from.
- Deliberate shortcuts: quick fixes taken to hit a date, intended to be revisited.
- Missing tests and documentation: changes become risky because nobody can confirm what they might break.
- Design that no longer fits: the system grew in directions the original design didn’t expect.
- Outdated components: old libraries and frameworks, often surfaced by software composition analysis (SCA), that are hard to upgrade and may carry known vulnerabilities.
- Customization: heavily modified commercial software that breaks or needs rework on vendor upgrades.
How it compounds. Each new feature built on a weak area adds more complexity. Developers spend more time understanding code than changing it. Automated testing in a CI/CD pipeline is harder to add after the fact, so risky changes stay risky.
How it’s managed. Teams record known debt alongside other work, estimate the cost of fixing it and of leaving it, and reserve capacity to pay it down, often a share of each Agile cycle or Scrum sprint. Code reviews, quality gates and agreed standards help limit how much new debt is added and make more of it a deliberate, recorded choice.
When it matters for buyers
- When you inherit code. After an acquisition, a staff departure or a change of development partner, assess the code before committing to timelines for new work.
- When outsourcing development. Fixed-price, deadline-driven projects, including phased Waterfall projects, can create pressure to cut corners. The statement of work (SOW) can set coding standards, test coverage expectations, documentation and handover requirements, and a code review before final acceptance.
- When customizing ERP, CRM or other platforms. Customizations can make future vendor upgrades harder. Our enterprise resource planning (ERP) overview covers how buyers weigh configuration against custom code.
- When change requests take longer and cost more each year. That trend is often the first visible sign of growing debt.
- When security findings repeat. Outdated components and fragile code tend to produce the same findings release after release.
Questions to ask vendors
- What coding standards, test coverage and documentation will the work meet, and how will we verify it?
- How do you track technical debt, and will we see that list?
- How much capacity do you reserve for paying down debt versus new features?
- Will we receive the full source code, build scripts and documentation at handover?
- For platform implementations: how much custom code does your approach need, and how does it affect upgrades?
- Can we commission an independent code review before final acceptance?
How it differs from technology debt
People often use the two terms loosely and interchangeably, but they usually mean different scopes. Technical debt usually refers to shortcuts in software code and design: how hard the code is to understand, test and change. Technology debt is commonly used more broadly, covering aging infrastructure, unsupported products, outdated processes and tangled integrations as well as code. Code-level technical debt is one part of an organization’s technology debt. A useful split for buyers is that technical debt is mostly paid down by developers improving code, while technology debt also needs replacements, upgrades and retirements of systems and hardware.