Technical Debt: When to Fix It and When to Ignore It

Every codebase has technical debt. Every engineering team argues about it.

Most of those arguments are unproductive. Here’s a framework that actually works.

What Technical Debt Actually Is

Technical debt is the gap between what you built and what you should have built.

But not everything called “tech debt” is actually debt:

Actually debt: Shortcuts that slow you down later. Hacky workarounds. Missing tests for critical paths. Tight coupling that makes changes expensive.

Not debt: Code that’s old. Code that’s not trendy. Code that works fine but isn’t pretty.

The test: Does this thing actively slow down future development? If not, it’s not debt. It’s just code you don’t like.

The Four Types of Technical Debt

Type 1: Reckless and Deliberate

“We don’t have time for good architecture.”

This is usually a mistake. You’re borrowing against a future that may never let you pay it back.

Priority: Avoid creating. Fix when encountered.

Type 2: Reckless and Inadvertent

“We didn’t know that was going to be a problem.”

Happens to everyone. You learn something new and realize past code is problematic.

Priority: Fix the parts that actively hurt. Accept that some will remain.

Type 3: Prudent and Deliberate

“We’ll ship this now and refactor later.”

Often the right choice. Speed to market matters. You know you’re creating debt and plan for it.

Priority: Track it. Schedule time to pay it down. Don’t let it compound.

Type 4: Prudent and Inadvertent

“Now we know how we should have built it.”

Hindsight is 20/20. Every shipped product teaches you what you should have done differently.

Priority: Apply learnings to new code. Don’t rewrite working systems just to apply new knowledge.

How to Prioritize

Not all debt is equal. Here’s the prioritization framework:

Fix Immediately

  • Security vulnerabilities
  • Data loss risks
  • Bugs affecting paying customers
  • Debt that blocks active development

These aren’t “debt cleanup”—they’re urgent issues.

Fix This Quarter

  • Debt that slows down multiple developers regularly
  • Debt in areas with planned feature work
  • Debt that causes recurring incidents

Schedule this work. Make it visible. Don’t let it slip forever.

Fix When You Touch It

  • Debt in stable, rarely-changed areas
  • Code that’s ugly but functional
  • Tests that are flaky but not critical

Boy Scout Rule: Leave code better than you found it. But don’t go looking for cleanup projects.

Accept and Ignore

  • Debt in deprecated features
  • Code that will be replaced soon anyway
  • Debt that would cost more to fix than the benefit

Sometimes the right decision is to not fix it. That’s not failure—that’s prioritization.

The Conversation with Business

Engineers want to fix tech debt. Business wants features.

Both are right. Here’s how to have the conversation:

Don’t say: “We need to pay down tech debt.” Do say: “This debt is slowing down Feature X. Fixing it will take 2 weeks but speed up future work by 30%.”

Quantify the impact. Make it a business case, not a technical preference.

If you can’t quantify the impact, maybe it’s not actually important.

The Refactoring Trap

Some teams refactor forever. Always improving, never shipping.

Warning signs:

  • Refactoring code that isn’t blocking anything
  • Rewriting systems that work fine
  • Perfectionism disguised as quality

The goal is shipping products, not having a pretty codebase. Beautiful code that never ships is worthless.

When to Rewrite vs. Refactor

Refactor when:

  • The existing code mostly works
  • Changes are incremental
  • You can do it alongside feature work

Rewrite when:

  • The existing code is fundamentally broken
  • You’re migrating to a new architecture
  • The refactoring would take longer than rewriting

Rewrites are usually underestimated. That 3-month rewrite will take 9 months. Plan accordingly.

Technical Debt as Investment

Here’s a different frame: Technical debt isn’t always bad. It’s leverage.

Taking on debt to ship faster can be the right choice if:

  • Speed to market matters more than long-term efficiency
  • You’re validating whether the feature even works
  • You have a plan to pay it back

The startup that ships with debt beats the startup that never ships.

Just be intentional about it.

My Framework

  1. Track debt explicitly. We use a “tech-debt” label in Linear. If it’s not tracked, it’s not managed.

  2. Allocate time deliberately. We spend 20% of engineering time on debt and infrastructure. Explicit, not hidden.

  3. Prioritize by impact, not age. Old code isn’t necessarily bad. Recent code isn’t necessarily good.

  4. Accept some debt permanently. Not everything needs fixing. Some debt is fine to carry.

  5. Make it visible to business. If leadership doesn’t know about debt, they can’t make informed tradeoffs.

Technical debt isn’t the enemy. Unmanaged technical debt is. Manage it like any other business obligation.