Technical debt on a website: what it is and how it grows
What technical debt means for a business website, how everyday shortcuts create it, and how it is paid down without a rebuild.
The short answer
Technical debt is the accumulated cost of shortcuts taken in building and changing a website: the quick fix instead of the right one, the plugin instead of the proper feature, the update skipped because it might break something, the styling override added on top of the last override, the copy of a component instead of a variant, the test not written. Each shortcut saves time when it is taken and charges interest afterwards, in two forms of slowness: pages that load slower as weight accumulates, and changes that take longer as every new change must work around the old shortcuts. It grows fastest when nobody owns the site, when changes bypass review and a pipeline, and when the business asks for speed on every request and never for tidying. On sound foundations it is paid down continuously, a little each month, and the business notices only that the site is getting faster and changes easier. Only a site whose foundations are themselves the debt needs a rebuild to clear it.
How debt is created and what it costs
| Shortcut | Why it was taken | The interest it charges |
|---|---|---|
| A plugin for a small feature | Faster than building it | Weight on every page, a security surface, an update to manage, a dependency on its author |
| A styling override | Faster than changing the component | Fragile rules that break on updates; nobody knows which wins |
| Copying a component | Faster than adding a variant | Two things to fix every time; drift between them |
| Skipping an update | It might break something | Security exposure; a bigger, riskier update later |
| No tests for a change | Faster to ship | Regressions found by visitors; fear of changing anything |
| A quick fix in production | Faster than the pipeline | Unrecorded change; the same bug returns; a mixed state |
| Hard-coding a value | Faster than a setting | A hunt through the code every time it changes |
| Leaving unused code and content | Removing takes time | Confusion, weight, and risk in what nobody understands |
Paying it down
- Make it visible: an audit that lists the debt by kind, and a monthly report that tracks the count.
- Stop adding: every change goes through the pipeline, review and tests; shortcuts are recorded when taken deliberately.
- Budget a share of every month’s work for repayment, alongside requests.
- Update dependencies continuously so no single update is frightening.
- Consolidate: variants instead of copies, tokens instead of overrides, features instead of plugins.
- Remove: unused code, plugins, content and scripts.
- Guard: performance budgets and accessibility checks in the pipeline so debt cannot silently return.
The business’s part
Ask for the debt to be visible in the monthly report. Accept that a share of each month goes to repayment even when it produces nothing visible, because it is what keeps the visible things cheap. When a genuine deadline demands a shortcut, agree it explicitly and schedule its repayment. And treat a partner who says a request needs to be done properly rather than quickly as protecting the next five years of requests.
What this means for you
Technical debt is the interest charged by earlier shortcuts, and it shows up as a slower site and slower changes. Keep it visible, stop adding it through a pipeline and review, repay a share every month, update continuously, consolidate and remove, and guard against its return. On sound foundations that keeps a site cheap to change for years; only a site whose foundations are the debt needs a rebuild, and that is worth knowing early.
Frequently asked questions
Is technical debt always bad?
No. Taking a shortcut deliberately to meet a real deadline, with the intention and the budget to fix it afterwards, is a reasonable trade, like any short-term loan. The debt that harms is the kind nobody chose and nobody tracks: shortcuts taken under pressure and forgotten, until the site is slow and every change is expensive. The difference is whether it is visible and being repaid.
How do we know how much our site has?
Signs the business can see: changes that used to take an hour now take a day; a mobile speed score that keeps dropping; the developer saying a small request is complicated; a fear of updating anything; features that break other features. Signs a partner can measure: outdated dependencies, failing or missing tests, override counts, duplicated components, unused code and plugins. An audit lists them; the monthly report tracks them.
Do we need a rebuild to fix it?
Usually not, if the foundations are sound: owned code, version control, a pipeline. Debt on those foundations is paid down incrementally, a portion of each month's work, without the business noticing more than the site getting faster and changes getting easier. A rebuild is for sites whose foundations are the debt, such as a theme with years of overrides on a platform nobody maintains, where repaying is more expensive than starting on solid ground.