What is Technical Debt?
Technical debt is the future cost of a shortcut taken now: code that works but is structured for speed rather than for change. Interest is paid in slower delivery, so a login system hard-coded for one user type charges its first instalment the day a second role is required.
- Category
- Product & Delivery
- Also called
- Tech debt, Code debt, Design debt
- Related
- Minimum Scalable Product (MSP)Staging EnvironmentSprintCustom Software vs Off-the-Shelf Software
- In our work
- Product development
The metaphor is about repayment rather than blame. Debt taken deliberately can be rational — shipping a hard-coded configuration to hit a launch date is a reasonable trade if the decision is recorded and repaid soon after. Accidental debt is the harder kind, accumulated by a team unaware that a better pattern existed, because nobody knows a payment is falling due until delivery slows.
The signal a non-technical owner can read is the estimate curve. When changes of similar size cost steadily more than they did a year ago, and every small request returns with a caveat about touching something else, the interest is visible in the invoice. Outdated dependencies, no automated tests around critical paths, and a deployment only one person knows how to perform are the usual specifics behind it.
Common questions.
Should technical debt always be paid off?
No. Debt in code that rarely changes and works correctly can be left alone; debt in the parts touched every week is what taxes delivery. The practical approach is to repay along the routes new work travels, rather than scheduling a cleanup project with no feature attached, which is hard to justify and tends to be cancelled halfway.
Where it comes up.
Building Fintech in the Philippines: Lessons from the Digital Banking Wave
ArticleA practical guide to fintech development in the Philippines, covering BSP licensing categories, the minimum compliance stack, and what to build versus buy.
Our Developer Disappeared After Launch: Now What?
ArticleWhen your developer disappeared after launch in the Philippines, here is the recovery plan: asset control, code audit, new hire criteria, and prevention.
Related terms.
Minimum Scalable Product (MSP)
Product & DeliveryA minimum scalable product is a first release built narrow in features but sound in architecture, so the same codebase carries the product from launch through growth without a rewrite.
Staging Environment
Product & DeliveryA staging environment is a private copy of a live system, running the same code and configuration, used to test changes before they reach customers.
Sprint
Product & DeliveryA sprint is a fixed working period, commonly one or two weeks, in which a development team commits to a defined set of work and ends with something demonstrable.
Custom Software vs Off-the-Shelf Software
Web & Software EngineeringCustom software is built for one organisation’s specific process; off-the-shelf software is a finished product many organisations subscribe to, such as Shopify or QuickBooks.
Scoping a project?
Reading definitions because you are scoping a project? Skip ahead and just ask.