Development
Technical debt
Also known as: tech debt, code debt
Definition
Technical debt is the accumulated gap between how a system is built and how it should have been built: every shortcut taken to hit a deadline turns into a permanent surcharge on the cost and duration of everything built afterwards.
The debt metaphor is accurate in the part that matters: there is a principal and there is interest. The principal is the shortcut itself: missing tests, copy-pasted code, a data schema shaped around the first use case. The interest is what you pay every sprint: a task that should take a day takes three because you have to work around a limitation, releases need manual verification, a new developer takes a month to become productive instead of a week. The interest is paid whether or not anyone intends to repay the principal.
Debt comes in deliberate and accidental forms, and the difference matters. Deliberate debt is a decision of the shape "we simplify now to hit the launch date and come back in two months", written down, with a deadline and an owner. Accidental debt comes from not knowing better and stays invisible until the system starts behaving strangely. The first kind is manageable and sometimes economically sound, because time to market genuinely can be worth more than code quality. The second just accumulates.
For a business, technical debt is measured not in code beauty but in three observable numbers: how long a typical change takes now compared with six months ago, what share of releases end in a rollback or a hotfix, and how many operations still have to be done by hand. When those numbers rise, the refactoring conversation stops being a matter of taste. The working practice is a standing quota, 10-20% of team capacity allocated to debt repayment inside the plan rather than "when we have time". There is never time.
Related terms
- RefactoringRefactoring is changing the internal structure of code without changing its external behaviour: the functionality before and after is identical, what changes is readability, coupling and the cost of the next change, verified by tests and regression checks.
- Legacy codeLegacy code is working code that is expensive to change: it runs on an outdated stack, has no test coverage or has lost its authors, so every edit means reconstructing the logic from the source and risks breaking something unrelated.
- CI/CDCI/CD is a pipeline that on every commit builds the project automatically, runs tests and checks, and then ships the passing build to a staging environment or to production, removing manual deployment and the human error that comes with it.
- Product backlogA product backlog is a priority-ordered list of everything that could be built into a product: it is not a dated plan, it is continuously revised, and one person, the product owner, is accountable for the order of it.
- MonolithA monolith is an application built and deployed as a single unit: all the code lives in one repository, runs in one process and works against one database, releasing as a whole, which buys simplicity at the cost of coupling.
Related services
- Website support and improvementNot every project needs a rewrite. It is often cheaper to fix the speed, clear the technical SEO errors, add the missing sections and integrations, and end up with a working site without paying for a new build.
- IT consulting and product auditThe most expensive mistakes in software happen before the first line of code: a misread problem, a stack chosen out of a contractor’s habit, and a specification that does not exist. Consulting exists to settle all of that before the development meter starts running: what to build, out of what, at what cost and in which order. The result is a document, not an opinion on a call.
Read more
- Redesigning a Site Without Losing Traffic: Stages, Risks and the SEO Migration ChecklistHalf of all redesign requests are really content, speed or offer problems. How to tell them apart, why a phased rollout beats a big bang launch, and what belongs in the migration checklist so the organic traffic survives.
- How to Choose a Development Contractor: The Question List and the Red FlagsA practical guide to choosing a development vendor: who needs a freelancer and who needs an integrator, the 25 questions for the first call, how to verify portfolio cases and what belongs in the contract.
Need this done, not just defined?
We do this work, not only write about it. Describe the task and we will scope it and send a staged estimate.