What is technical debt?
A metaphor from 1992 that every founder meets eventually. Here is what it means in money and time.
In short
Technical debt is the extra cost you pay later for shortcuts taken in software now: code that works but is hard to change, missing tests, duplicated logic, decisions nobody wrote down. Like financial debt, it charges interest, because every future change takes longer, until the shortcut is paid down by refactoring. Ward Cunningham coined the term in 1992.
Also called: Tech debt, Code debt
When does technical debt become a problem?
Some debt is a good trade: a prototype should take shortcuts, because its job is to learn fast. The problem is debt nobody knows about. AI-generated code tends to solve each prompt on its own terms, so an app can end up with several ways of doing the same thing and no tests to say which one is right.
It works until the day a change in one place breaks another. If that day has come for your app, our vibe coding rescue reviews what exists, then fixes what is risky, with every change tested.
What are the signs an app is carrying technical debt?
The signs show up as time and fear rather than as errors on screen. Small changes take far longer than they should, fixes bring old bugs back, knowledge sits with one person or one prompt history, and nobody dares touch the dependencies. Any one of these means interest is already being paid:
- Small changes take days, and nobody can say why.
- Fixing one bug brings back another.
- Only one person, or one prompt history, understands a part of the app.
- Nobody dares upgrade a dependency.
How do you pay down technical debt a piece at a time?
You do not pay it all at once. Put tests around the parts people rely on, then refactor the ones you change most, a piece at a time, while the app keeps shipping. At the same time, stop new debt from piling up, so the balance only goes down. The two halves look like this on real products:
What do interest and principal mean in technical debt?
Interest is the extra time every change costs because the code is messy. Principal is the cost of cleaning that mess up. Martin Fowler's example: a feature that would take four days in clean code takes six, so two days are interest. Paying principal only makes sense where you keep paying interest.
That is why Fowler suggests paying down debt in the parts of the code you change most, where interest is highest. A messy module that nobody touches costs little, because interest only comes due when you work in it. The cleanup itself is refactoring, made safe by regression tests.
Which kinds of technical debt are there?
Fowler's Technical Debt Quadrant sorts debt along two lines: deliberate or inadvertent, and prudent or reckless. Prudent, deliberate debt is a known trade, such as a shortcut to hit a release. Reckless debt is quick and dirty work, or a mess made by not knowing better. Each needs a different response.
- Prudent and deliberate: the team weighs the shortcut against the cost of repaying it, and plans to repay.
- Reckless and deliberate: the team knows better but goes quick and dirty anyway.
- Reckless and inadvertent: the team does not know good design, so debt piles up unseen.
- Prudent and inadvertent: a good team only learns the better design later, which Fowler calls inevitable.
An app built quickly with AI tools can hold all four at once. A production readiness check is one way to see which risks matter before real users arrive.
Common questions
Is technical debt always bad?
No. Taken on deliberately, it buys speed; Martin Fowler calls some of it prudent: a known shortcut to hit a release. It becomes a problem when nobody knows it is there, or when the interest, the time lost on every change, is never paid down.
How do you measure technical debt?
There is no exact number; Fowler notes productivity is hard to measure. A practical signal is interest: how much longer changes take in one part of the code than they should. Counting lint problems, failing tests or untested files against a recorded baseline also shows the trend.
Should you fix all technical debt before launch?
No. Fix debt in the parts you keep changing and the parts carrying risk, such as access control and payments. Fowler points out that messy code nobody touches costs little, because interest only comes due when you work in it. Leave stable corners alone until you need them.
Does AI-generated code create technical debt?
It can, quickly, because nobody reads it closely. AI-generated code tends to solve each prompt on its own terms, so an app can end up with several ways of doing the same thing. Reviews, tests and one agreed way of doing each thing keep that debt in check.
Go deeper
Refactor or rebuild your AI-built app?Refactor or rebuild an AI-built app? A six-area scorecard, the signs a rebuild is right, and how to replace an app piece by piece without stopping it.
Related terms
Read next
Sources
- Ward Cunningham, The WyCash Portfolio Management System (OOPSLA 1992)
- Martin Fowler: Technical Debt (May 21, 2019)
- Martin Fowler: Technical Debt Quadrant (October 14, 2009)
Sources checked October 24, 2026
More on this: Product strategy & scoping · All glossary terms
Built something in Lovable you want people to rely on?
We are the engineers who take it the rest of the way — secured, tested, released and supported.
