How do I handle technical debt without stopping feature work?

Short answer: make debt visible, connect it to business impact, and pay it down continuously in small pieces rather than asking for a big rewrite.

Understand the debt

Not all debt is equal. Separate:

• Deliberate and recorded: a shortcut you took on purpose to ship.
• Accidental: you learned a better design later.
• Neglect: outdated dependencies, missing tests, unclear code. Debt matters when it slows changes, causes bugs or creates risk.

Make it visible

Keep a debt list in your tracker, with a short description, the area affected, the cost of leaving it and a rough size. Tag work that was slowed by it.

Speak the business language

Instead of "the code is ugly", say "changes to checkout take twice as long because of X, and caused three incidents this quarter". Time lost and risk are persuasive.

Strategies that work

1. Boy Scout rule. Leave code a little better each time you touch it.
2. Allocate a steady share. For example reserve a fraction of each sprint for maintenance.
3. Refactor next to features. When a feature needs a messy module, clean it first, then build.
4. Add tests before refactoring, so you can change safely.
5. Prioritise by pain: hot spots that change often and break often first.
6. Avoid big-bang rewrites. Prefer incremental replacement, one module at a time.
7. Automate upkeep: dependency updates, linting and CI.

Pitfalls

• Refactoring code that rarely changes.
• Gold-plating; stop when the pain is gone.
• A debt list nobody reads.

Small, regular repayments keep velocity from degrading, and they are much easier to defend than a freeze on features.