Technical debt for non-engineers: what it is and when it's actually fine

Every software decision trades speed now against ease later. Ship fast with shortcuts and you've borrowed time — that's technical debt. Debt isn't automatically bad: the loan that carried your product to its first paying customers was worth it. The trouble is debt nobody tracked.

Debt that compounds: missing tests on money flows, undocumented business logic that lives in one person's head, hand-configured servers nobody can reproduce, and copy-pasted modules that fix one bug in five places. These get more expensive every month, invisibly — until a launch or an audit surfaces the bill.

Debt that never matters: the ugly naming in a module you'll delete, the slightly hacky one-off report, the 'temporary' script that's run twice a year for three years. Chasing perfection here is spending real money to feel tidy.

The conversation to have with your team is simple: which parts of the system make money, and what's their debt? For revenue-critical flows, schedule repayment deliberately — tests, docs, refactors as line items, not favours. For the rest, leave it alone. And when you inherit a codebase, an audit that separates the compounding debt from the cosmetic kind is the first £/₹ you should spend on it.