BYD TechThe short answer
Technical debt is the future work created when software is built the quick way instead of the sound way. Like a loan, it lets you ship sooner, and like a loan it charges interest: every later change takes longer and breaks more. Some debt is a sensible trade, especially in a first version. It becomes a problem when nobody chose it, nobody tracks it, and nobody plans to repay it.
Key points
- Debt is the gap between how the code is and how it would need to be to change easily.
- The "interest" is slower changes and more bugs.
- Deliberate, recorded debt can be a good decision. Accidental debt rarely is.
- The signs are visible to a non-technical founder.
- Pay it down steadily, starting where the product changes most.
Where the idea comes from
The term was coined by the programmer Ward Cunningham, who compared shipping imperfect code to taking on debt: useful for moving fast, as long as you repay it. Martin Fowler describes the interest as the extra effort every future change needs because of the mess left behind.
The comparison is helpful because it is neutral. Debt is not a failure. Businesses borrow on purpose all the time. What matters is whether the borrowing was a decision, and whether anyone is keeping track.
Deliberate and accidental debt
| Kind | Example | Verdict |
|---|---|---|
| Deliberate and recorded | Handling refunds by hand in v1, with a note to automate later | Often a good trade |
| Deliberate and forgotten | A temporary fix nobody wrote down | Becomes a surprise |
| Accidental | Code written without understanding the problem well | Expensive, and hard to see |
| From age | Libraries and platforms that have moved on | Unavoidable, needs routine upkeep |
Fowler’s technical debt quadrant makes the same point with two questions: was it deliberate or inadvertent, and was it prudent or reckless? Prudent, deliberate debt is a tool. Reckless debt is just damage.
Signs it is hurting, without reading the code
- Small changes take much longer than they used to.
- Fixing one thing breaks another.
- Only one person dares to touch certain parts.
- New developers take a long time to become useful.
- Releases are stressful, so they happen less often.
- The same bugs keep coming back.
These show up as business symptoms first: features slip, estimates grow, and customers notice bugs. That is the interest being paid.
AI-generated code and debt
AI tools can produce a great deal of working code very quickly, which makes it easy to take on a great deal of debt very quickly. Code that nobody on the team has read is debt by definition, however well it runs today. The common problems, and what to check first, are in Vibe coding to production.
How to pay it down
- Make it visible. Keep a short list of known shortcuts, each with what it costs you.
- Prioritize by change, not by ugliness. Fix the parts of the product you modify most.
- Repay as you go. Improve code whenever you are already working in that area.
- Add tests around the risky parts first, so changes stop breaking things.
- Keep dependencies current as routine work, not as an emergency.
- Avoid the full rewrite unless the foundations are truly unsound. Rewrites take longer than expected and deliver nothing until the end.
What a founder should ask
- What shortcuts did we take on purpose, and where are they written down?
- Which part of the product is slowest to change, and why?
- How much of each release goes to upkeep?
- Could another engineer take this over from the repository and its notes?
In a first version some debt is the right call, as long as it is chosen and recorded. That is why, in MVP development, we write down the reason for each technical choice, and review what exists in writing before any rebuild.
Sources
Checked when this guide was written.
