Technical Debt

Technical debt is the extra cost of maintainability that accumulates when shortcuts are taken to speed up development in the short term — it has to be 'repaid' with extra time and effort later.

Technical debt isn't just a vague way of saying 'the code is messy' — it has a measurable cost: per McKinsey's CIO survey, companies redirect an average of 10-20% of their new-product tech budget to technical-debt-related issues, CIOs estimate debt at 20-40% of total tech asset value, and 60% of CIOs say debt has risen noticeably over the past three years. Common sources include missing tests, rushed architecture decisions, and incomplete documentation — especially likely in projects delivered by a single freelancer and passed through several different engineers afterward. There's a simple rule of thumb for whether to patch or rebuild: once a given area's technical debt exceeds 50% of its tech-asset value, rebuilding's payoff starts to outweigh continued patching — most situations haven't hit that threshold yet, so patching usually beats a full rewrite. Picture a trading company running an eight-year-old system: rather than spending heavily on a full rewrite, it's more efficient to first map which modules are actually slowing new feature work and pay down debt there specifically. A common misconception is that technical debt only affects engineering morale — in reality it directly slows future feature development and amplifies risk during scaling or a team handoff, a real cost that shows up in quotes and launch timelines, not just code review comments.