What Is Technical Debt? Causes, Costs and Fixes

Every software system carries some technical debt. The question for a business is not whether you have it, but whether you know where it is and whether it was taken on purpose.

What technical debt means, and where the term comes from

The metaphor comes from Ward Cunningham, one of the authors of the Agile Manifesto. As Martin Fowler summarises it, shortcuts in code are like borrowed money: you gain speed now, and you pay interest later as extra effort every time you work in that part of the system.

You can pay down the principal by cleaning the code up, or keep paying the interest.

The metaphor is useful because it moves the conversation from "the developers want to refactor" to a business decision: what did we borrow, what is it costing us, and when do we pay it back?

The four kinds of technical debt

Fowler's Technical Debt Quadrant sorts debt by two questions: was it taken deliberately or by accident, and was it prudent or reckless?

Only the prudent, deliberate kind is a real loan with known terms. The other three are where most of the cost hides, because nobody knows the debt exists until it slows something down.

What it looks like on a website

Technical debt is not only a problem for large software products. On a business website or web application it usually looks like this:

• Package sprawl. Dependencies added to solve one problem each, several years out of date.
• Copy-pasted components. The same button or form implemented five times, each slightly different.
• Hard-coded content. Prices, phone numbers or text inside templates that only a developer can change.
• A late second language. Arabic bolted onto an English layout, with fixes for each broken page. See bilingual architecture.
• Untyped, undocumented code. No types, tests or documentation, so every change depends on the memory of whoever wrote the code.
• Manual deployments. A release depends on one person following steps nobody wrote down.

What it costs

The interest on technical debt is paid in time and risk, not in a line on an invoice. The common symptoms:

1. Simple changes take longer than they should: a new field on a form becomes a week of work.
2. Fixes cause new bugs: parts of the system are connected in ways nobody can see.
3. Releases feel risky: teams delay updates, so dependencies fall further behind.
4. New developers take long to become productive: knowledge lives in people, not in the code or the docs.
5. Security updates get postponed: outdated packages are the hardest kind of debt to see and the most expensive kind to ignore.

There is no honest universal figure for how much this costs. It depends on the system and how often you change it. What you can do is measure it in your own system.

How to measure it

No single number captures technical debt. Use a few indicators and watch the trend rather than the absolute value:

• Time per routine change. How long does a small, well-defined change take from request to release?
• Change failure. How often does a release need a fix or a rollback?
• Dependency age. How far behind are your frameworks and packages, and are any unsupported?
• Areas people avoid. Which files or features does everyone hesitate to touch?
• Automated signals. Static analysis tools can flag duplication, complexity and known vulnerabilities. Treat their output as a starting list, not a verdict.

Want these indicators read on your own system? Start with a technical audit.

How to manage it

You will never reach zero, and you should not try. The aim is to keep debt visible and deliberate.

1. Write it down. Keep a debt register in the same place as your other work items. Each entry says what was borrowed, why, and what it costs.
2. Decide per item. Pay it now, schedule it, or accept it. Accepting is a valid choice when the code rarely changes.
3. Clean as you go. Clean up the parts you are about to change anyway; they are where the interest is highest.
4. Reserve steady capacity. A small, regular share of each cycle for debt is easier to protect than a one-off "cleanup sprint".
5. Prevent the reckless kind. Strict typing, code review, written decisions and a regular update schedule stop most accidental debt before it starts.

A register entry can be short:

Debt: Checkout form validation duplicated in three places
Why: Shipped before launch; shared validation planned for after
Cost: Every rule change must be made three times; one copy is already out of sync
Decision: Pay down before the next checkout change

Refactor, or rebuild?

Refactoring pays debt down while the system keeps running. A rebuild replaces the system. Rebuilds are tempting because they promise a clean start, but they carry their own risk: the new system can inherit the same unclear requirements in cleaner code.

Refactor when the architecture still fits the business and the debt is local. Consider a rebuild when the platform itself is the limit, or the cost of every change is dominated by working around it. If you cannot tell which case you are in, a technical audit before a rebuild is cheaper than finding out halfway through one.

How we keep debt visible in our own builds

We cannot promise a codebase with no debt; nobody can. What we do is make it hard to take on by accident and easy to see:

• While building: strict typing, documentation and a structure another developer can follow, as the FAQ describes.
• At handover: the source code, the database schema with its migration history, a guide to environment variables and secrets, and deployment documentation, so the system does not depend on anyone's memory.
• After launch: under a maintenance plan, monitoring, backups and security updates are part of the regular work, not an afterthought.

Technical debt: common questions

Is technical debt always bad?

No. Deliberate, recorded debt can be a good business decision, for example to meet a launch date. It becomes harmful when it is invisible or when the interest is never reviewed.

Who is responsible for technical debt?

The decision to take it on is a business decision, so the business owns it. The engineering team is responsible for making it visible and explaining the cost in plain terms.

How do you explain technical debt to non-technical stakeholders?

Use the loan comparison and real examples: "Adding this field took four days instead of one because the form logic is duplicated." Concrete delays are more persuasive than code-quality scores.

Can a technical audit find technical debt?

Yes. A good audit lists where the debt sits, what it costs, and in what order to pay it down. Ours returns written findings and a roadmap any developer can use.

Finding the debt in your own system

If your current system is slowing every change down, start with a technical audit: you get a written list of where the debt is and what to do first. If you need steady upkeep instead, see what website maintenance covers.