Technical debt

The metaphor, introduced by programmer Ward Cunningham, works like financial debt. Taking a shortcut to launch sooner is borrowing. Every later change that has to work around the shortcut is interest. Some debt is a sensible trade, such as launching a simple version to test demand; the problem is debt nobody tracks, which compounds quietly.

Technical debt is not the same as bugs. A site can work perfectly for visitors and still carry heavy debt: outdated plugins, copied-and-pasted code, missing documentation or a framework version nearing the end of its support. The visitor sees nothing until a change becomes unexpectedly expensive.

How it works

Debt builds up in a few predictable ways. Deliberate shortcuts are taken to meet a deadline: hard-coding a price instead of making it editable, skipping tests, duplicating a template instead of making it reusable. Accidental debt comes from decisions that made sense with less knowledge. Ageing debt arrives with time alone, as the software a site depends on releases new versions and the old ones lose support.

The interest shows up as friction. A change that should take an hour takes a day because the same code exists in five places. Developers avoid touching fragile parts. Upgrading one plugin requires upgrading three others first. New developers need weeks to understand the system. Eventually the cheapest option is a rebuild.

Paying it down means setting aside time to refactor, which is restructuring code without changing what it does, alongside upgrading dependencies, removing unused features, writing missing documentation and adding tests. Teams that do a little continually spend far less than teams that wait for a crisis. The first step is simply making the debt visible: a short written list of known shortcuts, outdated components and fragile areas, each with a rough size and risk, so that decisions about what to fix are made on purpose rather than in an emergency.

Example

A clinic's site was launched quickly with the opening hours typed into the header, footer, contact page and three service pages separately. Each time the hours change, someone has to remember all six places, and one is always missed, so patients see conflicting information.

Over the same years, the site gathered plugins that nobody remembers installing, some no longer maintained. When the host announces it is dropping the old PHP version the site needs, the owner discovers that the upgrade requires replacing four plugins and reworking the theme. What could have been a few small updates spread over three years arrives as one urgent project at the worst time.

Why it matters for your business

Technical debt turns into money through slower and more expensive changes, security exposure from outdated software, and the eventual cost of a rebuild. It is often invisible in quotes: a cheap build may carry debt that makes every future change cost more. Not all debt needs paying off; a site you will replace next year may not justify cleanup. The useful habit is to ask your developer, once or twice a year, what the main debts are, which are risky and what it would cost to fix them, and to budget maintenance accordingly.

Common mistakes

• Treating every shortcut as free because the site still looks fine to visitors.
• Comparing build quotes on price alone without asking what will make later changes expensive.
• Postponing all updates until a host or platform forces a large, rushed upgrade.
• Rebuilding from scratch when steady refactoring would have kept the existing site healthy for less.

Questions people ask

Is technical debt always bad?

No. Taking on debt knowingly can be the right call, such as launching a simple version to test an idea before investing more. It becomes harmful when nobody records it, it is never paid down and the interest, in slower changes and higher risk, keeps growing.

How can I tell if my website has technical debt?

Signs include simple changes taking surprisingly long, developers reluctant to touch certain parts, many outdated or abandoned plugins, warnings about old PHP or framework versions and no documentation. Asking a developer for a short code and dependency review gives a clearer picture.

How much time should go into paying down technical debt?

There is no fixed rule. Many teams reserve a regular slice of each work cycle for upgrades and cleanup, so debt never builds into a crisis. For a small business site, an annual review with planned updates is a practical minimum.