Ruby on Rails development and upgrades
We build new Rails products, extend existing codebases and move applications to current Rails and Ruby versions — in small, safe releases, while your team keeps shipping features.
Signs your Rails application needs attention
If your Rails or Ruby version no longer receives security fixes, releases feel risky or pages keep getting slower, the codebase needs planned work — not more workarounds.
Unsupported versions
Rails or Ruby is past its security-support window, and audits start flagging it.
Gem lock-in
Key gems are abandoned or pinned, blocking every other upgrade.
Risky releases
Low test coverage means every deploy needs manual checking.
Slow pages and jobs
N+1 queries, missing indexes and overloaded background queues.
Hard onboarding
New engineers need weeks to understand undocumented code.
Stalled roadmap
Technical debt consumes the time planned for new features.
What a Rails engagement includes
A Rails engagement covers new development, version upgrades or both. The exact scope is agreed in writing before work starts.
Development
- New Rails applications and MVPs
- Features on existing codebases
- APIs and third-party integrations
- Hotwire front-ends (Turbo, Stimulus)
- Performance and database tuning
Upgrades
- Codebase and dependency audit
- Rails and Ruby upgrades, one version at a time
- Gem replacement and removal of dead code
- Test coverage for critical paths
- CI pipeline and security scanning
How a Rails upgrade is delivered
We upgrade one minor version at a time, running the current and next versions side by side in CI, and release every step to production separately.
- 01
Audit
Versions, gems, test coverage, deprecations and risks.
Output: audit report - 02
Upgrade plan
Version path, order of work and an estimate per step.
Output: plan + estimate - 03
Dual boot
The test suite runs on both versions for every pull request.
Output: green CI on both - 04
Incremental releases
Small, reversible releases to production, one version at a time.
Output: release notes - 05
Handover
Runbook, remaining-debt list and optional maintenance.
Output: runbook
What you receive
Every step produces something you can review and keep, even if you continue the work with your own team.
| Deliverable | Format | When |
|---|---|---|
| Audit report | Document with findings and risks | End of audit |
| Upgrade plan & estimate | Version path, effort per step | After the audit |
| Pull requests | Reviewed code in your repository | Every iteration |
| Release notes | Changelog per release | Every release |
| Runbook | Markdown in the repository | At handover |
Tools for Rails work
We use standard, well-maintained Ruby tooling and work within the tools your team already has.
Upgrade
- next_rails (dual boot)
- bundler-audit
- Brakeman
- RuboCop
Testing
- RSpec, Minitest
- Capybara
- FactoryBot
- SimpleCov
Runtime
- PostgreSQL, MySQL
- Redis, Sidekiq
- Solid Queue
- Puma
Front-end
- Hotwire
- Stimulus
- Importmap, jsbundling
- ViewComponent
Rails questions
What teams usually ask before a Rails project.
How long does a Rails upgrade take?
It depends on the starting version, the number of gems and test coverage. The audit gives you an estimate per version step before you commit to the full upgrade.
Do we have to stop feature development?
No. With dual boot, your team keeps working on the current version while we prepare the next one in the same repository.
Can you upgrade an app with almost no tests?
Yes, but we first add tests around the most critical user journeys, so each upgrade step can be verified automatically.
Do you also upgrade Ruby?
Yes. Ruby and Rails upgrades are planned together, because newer Rails versions require newer Ruby versions.
Request a Rails audit
Tell us your current Rails and Ruby versions and what worries you most. We will reply with next steps and an audit proposal.