Technical debt

Technical debt is the accumulated cost of shortcuts in your codebase: the quick hack, the duplicated logic, the half-finished migration, the stub you meant to come back to. Like financial debt it is sometimes worth taking on to move fast, but it charges interest, every future change in that area gets slower and riskier until you pay it down.

A few ways it shows up. Say you're running your dev work in Linear: the debt is real and visible when you've got a column of "refactor later" tickets nobody ever pulls, each one a known shortcut quietly charging interest. Or say you've wired up an automation in Make to move data between tools, and rather than fix a broken field mapping you bolt a second scenario on top to patch around it, now two flows do the job of one, and changing either breaks the other. Or say you're on Supabase and you start a schema migration, ship half of it, and leave the old columns alongside the new, every query now has to know which version it's reading.

AI building makes this sharper, not softer. An agent can generate a working feature in minutes, but it can just as quickly bury three near-duplicate versions of the same thing, or leave the old code beside the new. For a founder, unmanaged debt is what turns a fast-moving codebase into one where every change breaks two other things and momentum dies. The defence is discipline: finish migrations and delete the old, extend existing patterns rather than forking, and never leave a half-version. Debt you take on knowingly and repay is fine; debt you accrue blindly compounds until it owns you.