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
Why it matters when your prototype goes to production
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.
How you notice it
- 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.
Paying it down
You do not pay it all at once. Put tests around the parts people rely on, then refactor the ones you change most. Inkwave is an example: its code arrived in seven repositories and now lives in one monorepo of 14 apps and packages, with its test count up from 326 to 2,978 in eight weeks.
Looph shows the other half: stop new debt while you pay down the old. At handover its lint reported 19,849 problems, so a real one was invisible. Now every check runs in CI against a recorded baseline, and a count that goes up fails the build.
Common questions
Is technical debt always bad?
No. Taken on deliberately, it buys speed. It becomes a problem when nobody knows it is there, or when the interest, the time lost on every change, is never paid down.
Does AI-generated code create technical debt?
It can, quickly, because nobody reads it closely. Reviews, tests and one agreed way of doing each thing keep it in check.
Related terms
Read next
Sources
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.