Ruby on Rails, including the versions nobody wants to touch
We work on Rails applications at every age — greenfield products, ten-year-old monoliths carrying the whole business, and the upgrades in between. We have taken an application from Rails 2 all the way to Rails 8, in production throughout.
Where we come in
A major-version upgrade nobody will start
Rails 2 to 8 is a real path we have walked: staged upgrades, dual-booted gems, and the test coverage added ahead of each jump.
An app whose original team is gone
We read the code and the data, document what it actually does, and get the deploy and test pipeline trustworthy again.
Performance that degraded with the data
N+1s, missing indexes, jobs that grew past their window. We profile first and fix what the traces point at.
Rails rewards boring discipline: readable models, a fast test suite, and upgrades taken in small steps rather than as a heroic project.
Upgrades in increments, in production
Big-bang upgrades stall because they cannot be shipped. We move one version at a time, adding coverage around the areas each jump will touch, and deploy between steps so the risk is spread across months of ordinary releases.
Going from Rails 2 to Rails 8 that way meant the business kept getting features while the framework debt shrank — the alternative, a rewrite, would have frozen the product for a year.
Leave the codebase teachable
We write the kind of Rails a new hire can read: standard patterns, thin controllers, domain logic in objects with names from the business, and decisions recorded where the next engineer will look for them.
Cleverness that only its author understands is a liability in an application that has to live for another decade.
A framework upgrade should be dozens of ordinary deploys, not one frightening weekend.
Work like this usually touches
Have a Rails app that needs upgrading or rescuing?
Send the context you have — a repo, a diagram, or three paragraphs of frustration. We reply within one business day.