What Is Technical Debt?
Technical debt is the accumulated cost of expedient engineering shortcuts — deferred refactors, quick-fix patches, out-of-date dependencies, and architectural decisions that no longer fit the product. Like financial debt, it can be a rational choice at the time it is taken on, but it accrues interest in the form of slower velocity, more bugs, and higher onboarding cost until it is paid down.
How it works in practice
Debt enters a codebase in four typical ways. Deliberate debt: the team consciously ships a shortcut to hit a deadline, agreeing to fix it later. Inadvertent debt: the team ships something they thought was correct and later learns is not. Bit-rot debt: dependencies age, browsers evolve, security posture tightens, and code that was fine three years ago is no longer safe or performant. Architectural debt: the shape of the system was right for a five-person team and is wrong for a fifty-person team, but no one has re-cut it. Debt compounds because every new change on top of an unfixed shortcut has to work around the shortcut. Velocity drops slowly, then all at once when a critical change becomes impossible without a rewrite.
When to use it
The concept is useful for framing an honest conversation with executives about why engineering is getting slower. It is misused when it is treated as a moral failing (all software has debt; the question is whether it is under control) or when it is used to justify large rewrites without a business case. The right response to debt is measurement (track it in the same tool as features), triage (pay down the debt that is blocking current work first), and a standing budget (10-20% of every sprint on debt paydown for mature codebases). Rewrites are almost always the wrong response — the second system tends to accumulate its own debt while the first system's users are still depending on it.
Frequently asked questions
- Is all technical debt bad?
- No. Taking on deliberate debt to hit a market window can be the right business call — the same way taking on financial debt to fund growth can be. The rule is that debt should be taken on consciously, tracked, and paid down before it compounds into an obstacle. Debt is bad only when it is invisible or ignored.
- How much technical debt is normal?
- In a mature codebase with a mid-market engineering team, expect 15-25% of engineering time to go to debt paydown, refactors, and dependency upgrades. Codebases where debt work is under 10% are usually accumulating faster than they are paying down; codebases where it is over 40% are usually in rescue mode.
- Should we rewrite instead of paying down debt?
- Almost never. Rewrites underestimate the domain knowledge encoded in the current system, take 2-3x the planned time, and leave you supporting two systems in parallel for months or years. The right response to debt is targeted refactoring behind the current interface, plus discipline about not adding more. Full rewrites are justified only when the underlying platform or language is genuinely at end of life.
Start your project request
Tell us what you're building — engineering capacity, AI, QA, cloud, or a fixed-scope software engagement. Our NYC team responds within one business day.
- Response within 1 business day
- 30-minute discovery conversation
- Recommended engagement model & pricing
- NYC-focused — in-person available
Inbound sales only. All form information is encrypted in transit.