Technical debt in web projects — how it builds and what it costs
Every web project accumulates technical debt over time. That is not a failure — it is inevitable. The question is whether it is managed consciously or left to grow until it becomes an obstacle.
Technical debt is a metaphor borrowed from finance: like financial debt, technical debt accumulates interest. The longer it is left unaddressed, the more expensive it becomes.
What technical debt is
Technical debt is the gap between how something is built and how it should be built. That gap forms through:
- decisions made under time pressure — a tight deadline, a simple solution that works but is not sustainable;
- gaps in knowledge — the best approach known at the time, which later turns out to be wrong;
- changing requirements — the original architecture did not account for later needs;
- unmaintained dependencies — outdated libraries and components that no one has updated.
Technical debt does not only come from poor work. It forms in all projects — including good ones.
What it looks like
In a web project, technical debt can appear in several forms:
Code no one dares to touch. A developer who does not know what a change will actually affect makes a smaller change — which causes a new exception, which is quickly patched, which causes the next exception.
Updates that do not go through. Dependencies are so intertwined that every update breaks something else. Updating has stopped and the system is ageing.
Development that has slowed. Adding a new feature that should take a day takes a week — because first the old code must be understood and then the damage the change caused must be repaired.
No automated tests. No one knows whether a change broke something until a user reports a problem.
Why technical debt is not managed
Technical debt is invisible — to the owner, to management and often to the project manager. It does not appear in an invoice or a report. It shows up indirectly: in higher development costs, extended deadlines, recurring bugs.
Technical debt is also hard to argue for: "we need to rewrite this code even though the user will not see anything change" is difficult to explain. So it gets postponed until it becomes a crisis.
What technical debt costs
A small amount of debt is cheap to resolve. A large amount is expensive — not only in the cost of resolution itself, but because every day it exists slows everything else down.
A practical example: a site that has not been updated for three years is not simply three years of updates in scope. It typically requires several times that, because PHP versions, dependency compatibility, security requirements and architectural assumptions have all changed in the meantime. Updating has turned into partial rewriting.
How to address it
Technical debt is not resolved all at once. It is resolved gradually, through regular work:
- updates are made regularly, not after year-long gaps;
- each new feature includes fixes to adjacent older areas;
- tests are written alongside code, not later "at some point";
- technical debt is assessed and documented, not treated as if it does not exist.
Drupal maintenance includes this approach — regular updates, small remediation work and keeping the platform healthy is cheaper than accumulating large debts and liquidating them in one go.
Kaido Toomingas
WebPro Company OÜ
Need Drupal help?
If the article describes your situation, you do not have to read everything first. A real person will help you choose the next step.