Identifying Technical Debt Worth Paying Down (Not Everything Needs Refactoring)

One mistake we made early in a growing Rails product:

Trying to refactor too much at once.

Every old module started looking like “technical debt”.

So naturally, the instinct was:
“Let’s clean everything.”

But production reality taught us something different.

Not all technical debt creates business pain.

One legacy module in the system looked messy for years.
But it was stable and rarely changed.

At the same time, a different payment workflow was:
* Causing repeated production bugs
* Slowing feature delivery
* Increasing deployment risk every sprint

That was the real debt.

So instead of refactoring based on code quality alone, we started prioritising based on operational impact.

We focused on:
* Frequently changing workflows
* Incident-prone modules
* Areas slowing delivery or debugging
* Systems affecting customer experience directly

One targeted refactor reduced deployment-related payment issues significantly within a few weeks.

Meanwhile, some “ugly” code was left untouched because it was not hurting the business.

That changed how we think about technical debt.

Refactoring is not a cleanup activity.

It is an engineering investment decision.

The best refactors are usually the ones that improve system behaviour, delivery speed, or operational reliability.