Architecture Files #27 · Part of Binary and Beyond. LinkedIn newsletter edition follows.
Technical debt is not a sin.
It is a loan.
Sometimes it is a smart loan: ship the wedge, learn, repay when the shape is clear. Sometimes it is a payday loan taken because nobody wanted to name the interest rate. Either way, the economics are the same. You pull value forward and push cost into future change, incidents, and people.
Teams that moralise debt waste energy. Teams that price debt make better bets.
The feature that was "fine for now"
Picture a mid-market platform that hard-coded partner rules into checkout because the contract engine was "phase two."
Phase two slipped six quarters. Each new partner added another branch. Onboarding a seventh partner took a month and two production incidents. Hiring stalled because candidates smelled the tangle in the take-home. Finance still saw revenue. Engineering saw an options book with no amortisation schedule.
The original shortcut was rational under a three-month assumption.
The economics broke when the assumption silently became permanent.
What you are actually trading
Useful debt purchases speed to learning or speed to revenue against:
- Higher cost of the next change
- Higher probability of incident under load
- Higher support load from unexplained behaviour
- Higher cognitive load that slows hiring and onboarding
- Higher coupling that blocks extraction or modernisation (The Problem with Shared Databases, Every Integration Is a Distributed System)
If you cannot name the asset you bought and the interest you accepted, you do not have a strategy.
You have avoidance.
Good debt vs junk debt
Good debt: deliberate, time-bounded, visible, with a repayment trigger (volume, partner count, regulation date).
Junk debt: accidental complexity, copy-paste forever, shared databases used as integration, retries without keys, pending states that exist only in Slack (Why Retries Make Bugs Worse, Why Every Workflow Is Really a State Machine).
Refactor vanity is the opposite failure: paying down debt that is not on the critical path while the real interest compounds in the integration layer.
Pricing in language executives understand
Stop saying "we need to clean this up."
Say:
- This path adds N days to every partner onboarding
- This module is in the top incident cluster
- This design blocks extracting billing to its own service
- This gap will fail the next audit
Interest must be narrated as delivery and risk, not taste.
How this shows up in delivery
On legacy modernisation programmes, we treat debt as a portfolio: which loans buy near-term revenue, which loans block the roadmap, which loans are now more expensive than rewrite for a bounded slice. The goal is not purity. It is a repayment plan tied to business triggers.
A checklist before you take or keep a loan
- What decision does this debt buy this quarter?
- What trigger forces repayment (scale, partners, regulation)?
- Where does interest show up: incidents, cycle time, hiring, audit?
- Who owns the repayment item on the roadmap?
- Are we compounding junk debt adjacent to good debt?
- What is the smallest repayment that collapses the interest rate?
If there is no trigger and no owner, the loan is already in default. You just have not received the collection call.
Compound interest in integrations
The most expensive debt in enterprise stacks is rarely an ugly function.
It is an implicit protocol between systems: shared tables, undocumented status meanings, retries without keys, sync jobs that only one person understands. Each new feature pays interest by touching the protocol carefully. Each incident pays interest in archaeology.
Modernisation programmes fail when they try to repay everything. They work when they isolate the highest-interest loans: the couplings that tax every release, and repay those first with explicit contracts and ownership.
Debt portfolio management is product strategy wearing an engineering vocabulary.
Related reading
- The Problem with Shared Databases
- Why CRUD Stops Scaling Before Databases Do
- Building Systems That Recover Instead of Restart
- Why Enterprise Software Feels Slow (and Why That's Often Correct)
Architecture Files #27 · Part of Binary and Beyond. LinkedIn newsletter edition follows. Pricing and repaying technical debt against real roadmap triggers? Start a conversation.