Skip to content

Engineering

Technical Debt

The future cost of a shortcut taken today, code that works now but will slow every change until it is addressed.

Technical debt is the accumulated cost of decisions that were expedient at the time but make the system harder to change later: the quick fix that was never revisited, the abstraction that no longer fits, the test that was skipped. Like financial debt it is not inherently bad (taking some on to ship sooner is often the right call), but it charges interest, in the form of every future change taking longer.

The danger is debt that is invisible until it is overwhelming. A healthy team names it, tracks it, and pays it down deliberately, rather than letting it compound until a small change becomes a large, risky one. Most "we need a rewrite" situations are really "we ignored the debt for years".

Working out whether you need Technical Debt?

Definitions are the easy part. If you are trying to decide whether Technical Debt belongs in your system, describe what you are building and a senior engineer will give you a straight answer, including when the answer is that you do not need it.

  1. 01A senior engineer reads it. Not a form queue, and not an account manager.
  2. 02We reply either with questions or with a straight answer that we are not the right fit.
  3. 03If it looks like a fit, a technical call with the person who would actually run the delivery.
  4. 04Then scope, effort and risk in writing, before anyone signs anything.

Two fields required. We reply to real enquiries. No list, no sequence.