Technical debt is the extra cost of change caused by shortcuts in software: rushed code, skipped tests, outdated libraries or quick fixes that were never revisited. Like financial debt, it charges interest. Every new feature takes longer, bugs reappear and staff work around problems. You can estimate the cost by measuring how much developer and staff time goes on rework.
The term was coined by programmer Ward Cunningham to explain to non-technical colleagues why speed today can mean slowness later. It is not automatically bad. Taking on some debt to launch quickly can be a smart business decision, provided you know you have borrowed and plan to repay. The trouble starts when nobody is tracking it. Our complete 2026 guide to custom software explains where debt fits into planning and budgeting a build.
What does technical debt look like in a real business?
From the outside, technical debt looks like friction. Owners rarely see the code, but they see the consequences.
Common signs include:
- a "small change" that the developer estimates in weeks rather than days;
- the same bug coming back after being fixed;
- one developer being the only person who dares touch part of the system;
- staff keeping spreadsheets alongside the software because they do not trust it;
- slow pages that nobody can explain;
- security updates postponed because they "might break something".
If your team has started saying "we can't change that", you are paying interest.
What kinds of technical debt are there?
Technical debt comes in several forms, and the type tells you how expensive it is to fix.
- Code debt. Duplicated, tangled or unclear code that is hard to change safely.
- Design or architecture debt. The overall structure no longer fits how the business works, for example a system designed for one location now serving ten.
- Dependency debt. Frameworks and libraries that have fallen several versions behind, which eventually stop receiving security patches.
- Testing debt. Little or no automated testing, so every change has to be checked by hand or risks breaking something unseen.
- Documentation debt. Knowledge lives in one person's head.
- Infrastructure debt. Manual deployments, no backups you have tested, or servers configured by hand that nobody can rebuild.
It is also useful to separate deliberate debt ("we'll hard-code this for launch and fix it next month") from accidental debt (the team did not know a better approach at the time). Deliberate debt is a business decision. Accidental debt is a discovery.
How do you estimate what technical debt is costing you?
Estimate it by measuring lost time, then putting a price on that time. You do not need a perfect figure; a reasonable estimate is enough to make a decision.
Work through these steps with your developer or agency:
- Measure rework. For the last two or three months, roughly what share of development time went on fixing bugs, working around old code or redoing things, rather than building new value?
- Price that time. Multiply that share by what you spend on development over the same period.
- Add staff workarounds. How many hours a week do non-technical staff spend on manual steps, double entry or checking the system's output?
- Add incident costs. Downtime, lost orders, refunds or emergency fixes in the period.
- Add opportunity cost. Features you postponed because changes were too risky or slow.
A worked illustration, using made-up round numbers to show the method: suppose you spend $10,000 a month on development and your developer reckons about a third of that goes on rework. That is roughly $3,300 a month of interest, before counting staff time. If a targeted clean-up costing $15,000 would halve the rework, it pays for itself in about nine months, and every month after that is saved money.
Use your own figures. The point is to turn a vague frustration into a number you can compare with the cost of fixing it.
What does technical debt look like on a real project?
Our own website gave us a useful lesson. Over time, several kinds of debt had built up, none of them dramatic on their own:
| Debt we found on grww.tech | Type | Business cost if left alone | What we did |
|---|---|---|---|
| Login rate limit trusted an IP header visitors could spoof | Code and security debt | Brute-force protection could be bypassed | Fixed the logic so the limit could not be bypassed this way |
Content Security Policy allowed unsafe-eval | Security debt | Weaker protection against injected scripts | Removed unsafe-eval from the policy |
| Portfolio images totalled 1.66 MB | Performance debt | Slower pages, especially on mobile | Converted to WebP, bringing them down to 456 KB |
| Analytics loaded before the page content | Performance debt | Slower first paint | Loaded analytics after the page |
| 167 templated city pages | Content and SEO debt | Risk under Google's scaled-content policies | Set them to noindex |
| Canonical tags pointed at an old domain | Configuration debt | Search engines could credit the wrong site | Corrected the canonical tags |
None of these required a rebuild. Each was a targeted fix once someone looked. That is typical: most technical debt is paid down in small, specific repayments, not one big rewrite.
Should you always pay technical debt down?
No. Pay down debt where the interest is high, and leave it where it is cheap or the code will soon be retired.
Prioritise debt that:
- sits in parts of the system you change often;
- creates security or data-protection risk;
- blocks a feature with clear business value;
- slows down every new developer who joins.
Leave debt alone when:
- the code is rarely touched and works reliably;
- the feature or system will be replaced within months;
- it lives in a prototype built only to test an idea.
If you are unsure whether the right answer is fixing what you have or starting fresh, our explainer on when custom software actually pays for itself can help frame the build-versus-buy side of that decision.
How do you stop technical debt building up again?
Make repayment part of normal work rather than an occasional rescue project. A few habits make a big difference:
- Reserve capacity. Set aside a regular slice of each development cycle for clean-up and upgrades. We suggest agreeing an amount with your team rather than leaving it to whatever time is left over.
- Keep a debt list. Every deliberate shortcut gets written down with a reason and a rough cost to fix.
- Update dependencies on a schedule. Small, regular upgrades are far cheaper than one large jump after years of neglect.
- Insist on automated tests for core logic. They let developers change things without fear.
- Budget for maintenance from day one. As a planning figure, set aside roughly 15–25% of the build cost each year for maintenance.
A well-run build process bakes these in from the start. Our step-by-step guide to the custom software development process shows where testing, code review and documentation belong. Debt also explains why rushed timelines are a false economy; see our guide to realistic custom software timelines for what a sensible schedule looks like.
Frequently asked questions
Is technical debt always the developer's fault?
No. Much technical debt comes from business decisions, such as launching before a deadline, or from requirements changing after the code was written. Some comes from the industry moving on. What matters is whether it is acknowledged and managed.
How do I know how much technical debt my software has?
Ask for a short code and infrastructure review. A competent developer can assess dependency versions, test coverage, code structure, deployment process and security settings in a few days, and give you a prioritised list with rough costs.
Can technical debt cause security problems?
Yes. Outdated libraries miss security patches, and old shortcuts can leave gaps, like the spoofable IP header in our own login rate limit. Security-related debt should usually go to the top of the list.
Does technical debt mean I need to rebuild my software?
Rarely. Most debt can be reduced through targeted refactoring, which means improving the internal structure of code without changing what it does. A rebuild only makes sense when the architecture no longer fits the business at all.
How much should I spend on reducing technical debt?
Compare the cost of fixing a specific piece of debt with the monthly cost it creates, using the estimation method above. If a fix pays for itself within a year or removes a security risk, it is usually worth doing.
Want to know what your debt is costing?
If your software has started to feel slow to change, a focused review can tell you where the expensive debt is and what to fix first. See the kind of software and websites we build, or get in touch for a review and fixed-price plan.