Framework

When should you fix technical debt?

A framework for prioritizing technical debt based on business impact. When technical debt becomes business debt, and how to decide what to fix first.

When technical debt becomes business debt.

Technical debt isn't just an engineering problem. Left unaddressed, it constrains revenue, slows product velocity, and limits your options at exactly the wrong time.

But not all debt is created equal. Some slows you down today. Some will matter in six months. Some never matters at all.

The question isn't "should we fix this?"—it's "what happens to the business if we don't?"

Technical Debt Triage gives you a framework to answer that question systematically. It translates engineering concerns into business decisions.

The Triage Matrix.

Every piece of technical debt falls into one of four quadrants. Each quadrant has a different action.

High Business Impact · Low Effort

Fix immediately

This is blocking revenue, slowing critical features, or creating security risk—and it's quick to fix. Drop everything. Ship the fix this sprint.

High Business Impact · High Effort

Plan and schedule

This will hurt the business if you ignore it, but it takes weeks to fix. Add it to the roadmap. Allocate dedicated time. Break it into phases if possible.

Low Business Impact · Low Effort

Fix opportunistically

Not urgent, but easy. Fix it when you're already touching that code. Add it to the backlog. Let engineers clean it up during feature work.

Low Business Impact · High Effort

Accept or defer

This might be "messy" code, but it doesn't slow you down and fixing it would take weeks. Accept it. Revisit if business context changes.

Five principles.

The framework only works if you apply these rules consistently.

  • 1

    Business impact first.

    Technical elegance isn't the goal—business velocity is. Prioritize debt that blocks revenue, slows critical features, or creates security risk. Ignore debt that's just "not pretty."

  • 2

    Not all debt is equal.

    Some debt is strategic—you took a shortcut to ship fast, knowing you'd revisit later. Some debt is just mess. Strategic debt can wait. Accumulated mess compounds and slows everything.

  • 3

    Make it visible.

    Stakeholders can't see tech debt the way they see features. Translate it: "This slows every new feature by 2 days." "This creates a 10% failure rate on checkout." Make the cost concrete.

  • 4

    Pay down incrementally.

    Big rewrites usually fail. Instead of "we need 3 months to rewrite the auth system," break it into phases. Fix the highest-impact parts first. Ship improvements iteratively.

  • 5

    Accept some debt.

    Perfect code serves no users. Some "debt" will never matter. A messy script that runs once a month? Leave it. A feature only 3 customers use? Accept the mess. Focus on what slows you down.

When to use this.

This works when:

  • You have a backlog of tech debt and limited engineering time
  • Stakeholders ask "why are we fixing old code instead of shipping features?"
  • Engineers disagree on what to prioritize
  • You need to justify tech debt work to non-technical leadership
  • Your team is mature enough to have accumulated debt worth triaging

This doesn't work when:

  • You're a pre-product startup (ship features, worry about debt later)
  • Your codebase is so broken that nothing works reliably
  • You're trying to avoid making hard prioritization decisions
  • You use "tech debt" as an excuse to avoid shipping
  • You lack the data to assess business impact
← Explore all frameworks

Need help triaging your tech debt?

I help engineering teams translate technical concerns into business decisions—and build roadmaps that balance velocity with sustainability.

Let's talk about your codebase →