lessons from practice
When technical debt becomes business debt
Most of the time, technical debt is an engineering problem — it makes work slower and riskier, and it stays inside the engineering department. But there is a threshold where it crosses over. When debt starts affecting acquisition, conversion, reliability, or speed, it stops being technical debt and becomes business debt. At that point the conversation has to change.
The usual framing undersells the risk
The standard metaphor — "we're taking a loan against future velocity" — is accurate but quiet. It makes debt sound like an internal accounting problem, something engineering settles with itself during quarterly planning.
What I saw at Sheypoor was louder than that. A significant traffic decline had been running for roughly eight months when I joined. The investigation eventually pointed at several distinct technical problems: SEO issues tied significantly to a custom server-side rendering implementation, deep-link problems that broke the path into the app, push notification issues that needed a new Android release. Each one was accumulated technical debt. Each one had already become a business number.
Traffic was the top of the funnel for the entire company. The debt wasn't slowing engineers down — it was draining customers out.
The four crossings
In my experience, technical debt becomes business debt when it reaches one of four systems:
- Acquisition — the market can no longer find or reach the product. SEO decay is the classic case: invisible, gradual, compounding.
- Conversion — users arrive but the journey leaks. Broken deep links and slow, failing flows are debt expressing itself as revenue friction.
- Reliability — the product fails in ways customers notice. Every unreleased fix is a promise the product can't keep.
- Speed — not page speed alone, but the speed at which the business can act. When releasing takes months, the business loses the ability to respond to anything.
The first two take money directly from the top line. The second two take it indirectly, by freezing the organisation while the market moves.
What changes when you see it that way
Once debt has crossed, the discussion stops being "should we invest in paying this down" and becomes "which business problem are we choosing to have". That reframing matters for leaders, because it changes who belongs in the room. It's no longer an engineering roadmap negotiation; it's a business triage.
At Sheypoor, the decision to rewrite the affected SSR pages with Next.js instead of continuing to repair our custom framework was exactly this kind of decision. The framework had consumed more than a year of effort and was still contributing significantly to the SEO problem. Keeping it meant choosing continued business damage in exchange for sunk-cost pride. The rewrite was technically unglamorous — and it was the right call: roughly 20+ days after launch, Core Web Vitals were passing across the board, and the SEO issues that had been bleeding acquisition were addressed.
How to find the crossings early
Debt never announces its crossing; the instruments do. In our case, Google Search Console, application logs, and ranking data were where the debt showed up as business symptoms. The discipline I'd recommend from that experience:
- Watch business instruments, not just engineering ones — acquisition, conversion, release cadence.
- When a business metric slides for months with no clear cause, assume debt until proven otherwise. We assumed ambiguity; the data eventually spoke.
- Price the debt in the currency it's actually draining: customers, revenue, and time-to-act — not story points.
In retrospect
The hardest part of that period wasn't fixing any single problem — each fix, once identified, was achievable. The hard part was the months where the decline was still happening and the cause was unclear. Debt that has crossed into the business does that: it charges interest in customers while you're still looking for the loan documents.