Technical debt

In practice

The term comes from software, where a developer borrows speed now by writing quick, imperfect code and pays it back later in harder maintenance ^[1]. On a website it shows up as a pile of plugins nobody dares remove, a theme patched a dozen times, content structures that no longer fit, and a stack only one person understands. Each was a reasonable shortcut once; together they're a tax.

The reason it matters for owners is that a website doesn't hold steady while you defer the rebuild, it decays in place. What looks like a design problem is often a maintenance-debt problem: the site is expensive to change not because it's ugly but because years of patches made every change risky. And you're already paying the interest, in slow updates and things that break when touched.

Technical debt is invisible from the outside, which is why it grows. The site still loads, so nothing forces a reckoning, while the cost compounds underneath: updates take longer, new sections require rebuilding old ones, and the list of "don't touch that" grows. The bill arrives all at once, usually when a needed change turns out to be impossible without a rebuild.

At some point the interest exceeds the principal: you spend more maintaining the old site than a new one would cost to build and run. That's the honest trigger for a redesign rather than a refresh, because a refresh paints over debt while a rebuild clears it. The cost of the rebuild is usually more knowable than the cost of the drift.

A rough gauge: think of the last three changes you wanted on the site (a new service, a fixed page, a design tweak) and ask how each went. If small changes routinely turn into "we can't without a developer" or "that might break something," you're paying interest on technical debt, and it only compounds from here.