Technical debt

Technical debt describes the effort created when a quick solution is chosen over a clean one. The term comes from software development and does not mean sloppiness: a shortcut can be the right call when a deadline matters. It becomes debt because it carries interest. Every later change in that place takes longer, every extension needs a detour, and eventually a small adjustment costs half a day.

On a website it rarely shows up as a fault; it shows up as friction. A content management system in which nobody from the business can add a page without breaking the layout. A dozen extensions, three of which do the same job and two of which are no longer maintained. A programming language on a version that will soon stop receiving security fixes, while an old extension cannot cope with the newer one. None of this is broken today; each of them turns into a project on a specific date.

The debt becomes visible when you write it down instead of feeling it. A workable register has four columns: what the shortcut is, why it was taken, what it costs in daily work, and how you will know it is falling due. It almost always falls due from the outside, through an update, a new requirement or a vendor who stops. Noting those triggers in advance turns a surprise into a date.