In short
Some debt is deliberate: ship the small version now, record the trade-off, and fix it when the evidence supports it. Dangerous debt is silent: nobody remembers the shortcut, but every feature now bends around it.
The practical job is to separate cosmetic cleanup from debt that affects revenue, security, hiring, delivery speed, or due diligence confidence.
Where it bites
Technical debt bites when a simple change needs three estimates, one person holds the whole system in their head, or a buyer asks for evidence the team cannot produce.
What to check
- Which debt item blocks the next commercial goal?
- What breaks more often because this shortcut exists?
- Who owns the decision to pay it down, defer it, or accept it?
Common questions
What is technical debt?
Technical debt is the future cost created by shortcuts, deferred fixes, weak tests, outdated dependencies, or architecture decisions that make later work harder.
Is all technical debt bad?
No. Some debt is a conscious trade-off. It becomes a problem when it is hidden, unpriced, unowned, or blocking the next important change.
What should you check first for technical debt?
Start with the debt that affects uptime, security, delivery speed, customer experience, or a near-term business decision. Do not begin with cosmetic cleanup.