IT Glossary
What is technical debt?
The shortcuts and compromises accumulated inside an application — a loan whose interest is repaid at every future change.
You notice it on the invoice long before anyone names it. A change that took two days last year now takes two weeks, the estimate for a small feature arrives after an uncomfortable pause, and the developer explains that touching one screen breaks three others. That gap between what a change ought to cost and what it actually costs is technical debt: the accumulated effect of decisions that were fast at the time — copied code instead of shared code, no tests, an outdated framework nobody dared upgrade, a database design bent to fit an emergency. Some of it was rational. Shipping in six weeks to win a contract is a legitimate trade, exactly as borrowing money is. The danger is debt taken without a decision and never repaid, because the interest compounds silently until every change is quoted as a rewrite. For an owner the practical value of the term is that it converts a vague engineering complaint into something a budget conversation can handle: how much are we paying in interest, and which repayment buys the biggest reduction.
Let’s talk about your project
Message us on WhatsApp or send an email — you talk directly to a developer.
office@northdan.com · +40 752 070 247
Why it matters for your business
Change costs stay predictable
Debt kept visible and repaid on a schedule stops the slow drift where every quote grows and nobody can explain why.
Fewer surprise defects
Most repeat bugs cluster in the oldest, least tested corners of a system — repaying there removes the source, not the symptom.
Business decisions made with facts
Naming the interest turns rewrite-or-repair into a comparison of numbers rather than a contest of confidence between suppliers.
Frequently asked questions
As a non-technical owner, how do I spot heavy technical debt?
Watch the estimates rather than the code. Small changes quoted in weeks, releases that need a weekend and a war room, the same defect returning after each fix, a supplier reluctant to let anyone else read the system, and nobody able to set up a copy for testing — those five signals together describe an application whose maintenance cost is about to dominate its value.
Is a full rewrite worth it to escape the debt?
Rarely as a first move. Rewrites restart at zero features and typically overrun, and the habits that created the debt tend to recreate it. The better path is usually strangling the old system gradually: build new capability alongside it, move users module by module, retire pieces as they empty. Rewrite outright only when the platform is unsupported or nobody can be hired for it.
How do we avoid accumulating debt on a new project?
Insist on automated tests from the first sprint, code review as a rule rather than a courtesy, and a written architecture decision log. Then reserve roughly a fifth of each iteration for maintenance work and defend that budget when deadlines press. Debt is not prevented by good intentions; it is prevented by capacity booked before anyone needs it.
Let’s talk about your project
Message us on WhatsApp or send an email — you talk directly to a developer.
office@northdan.com · +40 752 070 247