Engineering Note
Six months of refactoring can still fail if you don't decide what to remove first.
In a long-running Rails application, legacy code rarely exists in one place.
Old callbacks.
Unused gems.
Duplicate business logic.
Deprecated APIs.
Features nobody remembers owning.
The problem isn't just that the code is old.
It's that every change becomes harder to understand and test.
Instead of planning a complete rewrite, I'd break technical debt reduction into six months:
Month 1: Identify
Find unused code, outdated dependencies, duplicated logic and high-risk areas.
Month 2: Prioritise
Focus on code that slows feature delivery, causes incidents or creates security risks.
Months 3–4: Refactor
Remove dead code, simplify complex flows and replace legacy patterns in small steps.
Month 5: Verify
Add missing tests, monitor production behaviour and check that old paths are no longer used.
Month 6: Prevent regression
Add dependency checks, code ownership and regular technical debt reviews.
The important part is that feature development doesn't need to stop for six months.
Refactoring can happen incrementally alongside product work.
Important learning:
Technical debt isn't reduced by rewriting the most code.
It's reduced by removing the code and complexity that create the most ongoing cost.
For a Rails SaaS, the goal isn't a perfect codebase.
It's a codebase where the next change becomes easier and safer.
Old callbacks.
Unused gems.
Duplicate business logic.
Deprecated APIs.
Features nobody remembers owning.
The problem isn't just that the code is old.
It's that every change becomes harder to understand and test.
Instead of planning a complete rewrite, I'd break technical debt reduction into six months:
Month 1: Identify
Find unused code, outdated dependencies, duplicated logic and high-risk areas.
Month 2: Prioritise
Focus on code that slows feature delivery, causes incidents or creates security risks.
Months 3–4: Refactor
Remove dead code, simplify complex flows and replace legacy patterns in small steps.
Month 5: Verify
Add missing tests, monitor production behaviour and check that old paths are no longer used.
Month 6: Prevent regression
Add dependency checks, code ownership and regular technical debt reviews.
The important part is that feature development doesn't need to stop for six months.
Refactoring can happen incrementally alongside product work.
Important learning:
Technical debt isn't reduced by rewriting the most code.
It's reduced by removing the code and complexity that create the most ongoing cost.
For a Rails SaaS, the goal isn't a perfect codebase.
It's a codebase where the next change becomes easier and safer.