In short
- Technical debt is the extra effort every future change costs because of past shortcuts or decisions.
- Some debt is a sensible trade. Debt nobody chose, tracked, or repaid is what hurts.
- It shows up as slow changes, repeat bugs, and code people are afraid to touch.
- An MVP can take on debt on purpose, as long as each shortcut is written down.
Also called: Tech debt, Code debt.
What technical debt means
Ward Cunningham coined the metaphor in 1992, comparing code shipped before it is fully right to going into debt. Borrowing gets you somewhere faster. Until you go back and improve the code, you pay interest in the form of extra effort on every change that touches it.
The metaphor carries the right intuition. A little debt, repaid promptly, can be a good deal. Debt that piles up without repayment ends with most of a team's time going to interest and little left for new features.
It covers more than messy code. Outdated libraries, missing tests, a data model that no longer fits the product, manual release steps, and choices that made sense for a hundred users and strain at ten thousand all count.
Deliberate and accidental debt
Some debt is chosen and some arrives uninvited. The difference matters when deciding what to do about it.
Two kinds of technical debt
Deliberate
- Chosen knowingly to ship sooner
- Written down when it is taken on
- Has a plan or trigger for repayment
- Common and sensible in an MVP
Accidental
- Comes from inexperience or haste
- Or from the product outgrowing the code
- Usually discovered late
- Rarely tracked or planned for
Some debt is nobody's fault. Code written well for last year's product becomes debt when the product changes direction, or when the frameworks underneath it move on. Every codebase still in use gathers this kind, which is why some upkeep never goes away.
Handoffs are another quiet source. When one person designs a feature and another builds it, the reasoning behind each compromise can get lost between them, and the code inherits shortcuts nobody remembers choosing. That is one reason Choie keeps design decisions and code in the same hands: the reasoning behind a compromise is still known when the code changes later.
Signs technical debt is hurting
Debt rarely announces itself. It shows up as a gradual slowdown that is easy to blame on something else.
- Small changes take days, and estimates for similar work keep growing.
- The same kinds of bugs return in the same parts of the product.
- Developers avoid certain files, or call a change risky without being able to say why.
- New team members take weeks to become productive.
- Framework upgrades get postponed because they keep breaking things.
How to pay it down
Rewriting everything is tempting and usually the wrong move. A rewrite pauses feature work for months and tends to reintroduce problems the old code had already solved. Steady, targeted repayment works better for most products.
- Make it visible. Keep a short list of known debt, where it lives, and what it costs. Debt nobody can see never gets prioritized.
- Pay the expensive debt first. Start with the areas that change most often. Untidy code that nobody touches costs almost nothing.
- Add tests before restructuring. Tests make it safe to change code, and their absence is often the largest debt of all.
- Fix it where you work. When a feature touches a messy area, leave it a little better. Cleanup tied to real work is easier to justify and to check.
- Reserve regular time. Set aside a steady share of each cycle, so repayment does not depend on a quiet month that never comes.
Technical debt and building an MVP quickly
An MVP is meant to be small and fast, and some debt comes with that. Skipping an admin panel, hard-coding a setting, or handling a rare case by hand are reasonable shortcuts while you are still learning what the product should be. The product may change enough that some of them never need fixing.
Other shortcuts are a bad trade even in a first release. Weak security, careless handling of user data, a data model that is hard to change, and no tests on the core workflow all get more expensive with every user you add.
A practical rule
Take shortcuts on features, not on foundations, and write each one down so it can be repaid on purpose.
AI coding tools add a new wrinkle. They produce a lot of code quickly, which makes reviewing it more important, and unreviewed output is an easy way to take on accidental debt. AI-assisted development and vibe coding cover the difference.
How Choie approaches it
At Choie, AI drafts implementation from a decided design, generates repetitive parts, and does mechanical refactors. A senior person reads every line before it ships, and generated code that is not understood is not merged, since code nobody understands is debt from the first day. Once fees are paid, the source code is the client's, and defects in the studio's own work are fixed free for 30 days after launch. See who owns the code and AI-accelerated development.
Common questions
Is technical debt always bad?
No. Debt taken on deliberately to learn faster, and written down, is often a good trade. It becomes a problem when nobody tracks it and the interest starts slowing every change.
How can I tell if my product has too much technical debt?
Watch how long similar changes take over time. If routine work keeps getting slower and the same bugs keep coming back, the debt is costing more than it saved.
Should we rewrite the product from scratch?
Rarely. A full rewrite pauses feature work and often recreates old problems. Replacing the worst parts one at a time, with tests around them, is usually safer and cheaper.
Who decides when to pay down technical debt?
The developers should propose it, and whoever owns product priorities should agree to it. It works best as a regular share of each cycle, so it is not a fresh argument every time. On Choie's monthly plan, the work follows one clear priority at a time, and paying down debt in a busy area can be that priority like any other.