Technical Debt: Your Secret Weapon for Hypergrowth

I hate the term Technical Debt. It implies you eventually pay it back. You won't.

Let's be real: 90% of "debt" is just undocumented risk that you're praying doesn't explode before your vesting cliff.

Last year, I joined a Series B startup that was "moving fast". Their backend was a terrifying spaghetti monster of 3,000 LoC controllers and raw SQL queries. The CTO called it "leverage". I called it a time bomb.

But here is the twist: The CTO was right.

The Math of Ignoring It

Standard advice says: "Pay it down sprint by sprint". This is a lie.

If you try to refactor a system while shipping features, you will fail at both. The business doesn't care about your clean code. The business cares that the checkout button works.

Let's look at the numbers.

• Rewrite Cost: 2 Engineers x 2 Months = $60,000.
• Cost of the Bug: Customer support spends 2 hours/week manually fixing data = $5,000/year.

It would take 12 years for that rewrite to pay off. If you rewrite this, you are not being a "good engineer". You are being fiscally irresponsible.

The "Strangler" Protocol

Instead of these incremental cleanups that go nowhere, I propose a more brutal approach: The Technical Bankruptcy Declaration.

1. Ring-fence the Garbage Don't touch the legacy mess. Wrap it in an API layer. Treat it like a 3rd party black box service that you hate but can't fire. Use type guards at the boundary and assume everything coming out of it is toxic.

2. Build the New Path Parallel All NEW features go into a separate, clean service/module. No exceptions.

   • New feature? New module.
   • Modifying old feature? Duplicate logic into new module, then kill old path.
   • This is known as the Strangler Fig pattern.

3. Kill the Zombies If code hasn't been executed in 90 days, delete it. Don't deprecate it. DELETE IT. If it breaks, good. Now you know who was using it.

Why Engineers Fail at This

We engineers are obsessed with "correctness". We want to fix the root cause. But in a high-growth environment, survival > correctness.

Reference: Facebook didn't rewrite PHP because it was bad. They built Hack on top of it because rewriting would have killed them.

The Hard Truth

If you have debt that isn't causing immediate customer pain or blocking revenue, it is not debt. It's a feature of your history. Leave it alone.

Stop feeling guilty about bad code. Start worrying about slow delivery.

My Stack

• Vultr — Because I'm done debugging AWS IAM roles. Simple, fast infrastructure.
• Linear — The only project management tool that doesn't make me want to quit tech.
• Supabase — Because writing your own auth in 2026 is a fireable offense.