Technical Debt: When to Pay It Off vs When to Ignore It

"We need to refactor this" can become an unproductive discussion if it is not connected to a concrete problem.

Not all technical debt needs immediate attention. Prioritize the debt that creates meaningful delivery, reliability, or data risks.

• **Debt that matters:**
• Repeatedly slows delivery of important features
• Creates production incidents or data integrity risks
• Makes hiring hard (new developers can't understand the code)
• Blocks a specific roadmap initiative

• **Debt that doesn't:**
• Is messy but fast
• Is in code that rarely changes
• Is understood only by one person (hire them well and it's fine)
• Lives in non-critical systems

**The test:** Would fixing it remove a concrete delivery bottleneck or unblock an important roadmap item? If so, compare the cost and risk of remediation with the expected benefit. If the only benefit is cosmetic cleanliness, defer it.

**When to prioritize it:** Q: "Are we blocked by this debt?" If yes, assess the impact and prioritize remediation against other product and operational work.

If no — ship features and keep a log of what slows you down. When the answer becomes yes, pay it then.

Track where debt creates friction and address it strategically alongside product work.