GLOSSARY
Technical debt
Technical debt is the accumulated cost of past shortcuts in how a system was built, quick fixes, skipped documentation, code that works but was never properly structured, that has to eventually be paid down through rework, usually at a higher cost than doing it properly the first time.
Why it matters
Like financial debt, it compounds: a shortcut taken to hit an early deadline makes the next feature harder to build on top of it, and the one after that harder still, until a system that once shipped fast becomes slow and risky to change at all. Ignoring it does not make it go away, it makes the eventual cost larger. It also affects hiring and morale over time: a codebase carrying heavy, unmanaged technical debt is measurably harder and less pleasant to work in, which shows up eventually as slower delivery and higher turnover among the people maintaining it.
What goes wrong when it's handled badly
A plugin-heavy WordPress site is a common, visible form of technical debt: each plugin added to hit an immediate need becomes a long-term liability of updates, compatibility risk and page weight nobody accounted for at the time. A system with enough accumulated technical debt often becomes cheaper to rebuild than to keep patching, which is the point where a rebuild conversation genuinely makes sense. A concrete example is a feature that took two days to add when a codebase was young taking two weeks to add safely five years later, purely because every shortcut taken along the way has made the system progressively more fragile to change. Treating a rebuild as a deliberate decision made once total debt clearly exceeds the cost of continued patching, rather than an emergency reaction to a system finally breaking, is what keeps the transition controlled rather than forced.