Get your Rails application current without taking your team off the roadmap
Reviewable Rails and Ruby upgrades, dependency updates, security fixes and code-health improvements every month. Purpose-built agents do the continuous analysis. Senior Rails engineers approve every change.
Plans start at $1,950 per month. No long-term commitment.
- SoundCloud
- Procore
- ReadyTech
- Power Home Remodeling
- doxo
- Smile.io
- TitleLeaf
- Epassi
- SoundCloud
- Procore
- ReadyTech
- Power Home Remodeling
- doxo
- Smile.io
- TitleLeaf
- Epassi
- SoundCloud
- Procore
- ReadyTech
- Power Home Remodeling
- doxo
- Smile.io
- TitleLeaf
- Epassi
What staying behind actually costs you
Falling behind is not a plateau. It compounds, and the bill arrives all at once.
- Security stops arriving. An unsupported Rails version stops receiving patches, so every new advisory becomes yours to backport.
- The roadmap gets blocked. Gems that dropped support for your version start blocking the features and integrations you planned.
- Infrastructure ages out. Cloud runtimes, database and Ruby versions age out from under you, turning routine work into a migration.
- Audits raise it first. Unsupported versions put your SOC 2 and HIPAA posture at risk, and it is the finding enterprise security reviews raise first.
- The eventual upgrade grows. Every version you fall further behind makes it longer, riskier and harder to staff.
- Advisories triaged as they land. Checked against your actual Gemfile the day they are published, not at audit time.
- Dependencies keep moving. The backlog gets worked down every month instead of accumulating into a wall.
- Infrastructure stays supportable. Ruby, database and runtime versions move with the application, not years behind it.
- A compliance story you can show. Supported versions, patched dependencies, and a quarterly report that documents the movement.
- The next version is a month, not a project. Handled in the quarter it ships rather than three years later.
Your path from outdated to current
This is a retainer with a destination, not maintenance without end. Where you start decides the sequence. We confirm the timing after the initial assessment, not before.
Monthly maintenance keeps you there
First milestone: a compatibility assessment and the first upgrade pull requests. After that the work turns into staying current, which is much cheaper than catching up.
A sequenced roadmap, one version at a time
First milestone: a supported Ruby, compatible dependencies and a written plan for the next Rails version. Then we work the sequence month by month.
A short assessment, then a custom plan
Heavily customised, operationally fragile or unpatched for years. First milestone: a risk map, an upgrade sequence, and a budget and timeline range.
Know the path, then start making progress
In the first month we turn an uncertain upgrade into a ranked plan and start delivering reviewable improvements. Here is exactly what you get for the first invoice.
Repository and workflow assessment
How the application is built, tested and deployed, and what that means for upgrading it safely.
Compatibility and risk map
Which dependencies block the next version, which are unmaintained, and where the sharp edges are.
Technical-health scorecard
A scored baseline for the codebase, so each quarterly report shows movement rather than opinion.
Upgrade sequence and priorities
The order of work, agreed with you. You decide what goes first. We tell you what it depends on.
First reviewable pull requests
Real merged progress inside the first month, plus a shared async channel and a monthly huddle.
Choose a pace, not a mystery scope
Most applications two versions behind begin with Komono. We confirm the right pace after reviewing your application. You don’t have to diagnose your own codebase to pick a plan.
Throughput ranges are what we typically deliver at each pace. Complexity varies, and the assessment in month one tells us where your application sits. Plan names are bonsai types, because pruning a tree and paying down debt work the same way.
- Capacity
- 2 days per month
- Typical pace
- Up to 4 PRs / mo
- Cadence
- Monthly huddle + quarterly report
Fits: a smaller application, close to current, or a team that would be overwhelmed by more than a handful of pull requests a month.
Start here →- Capacity
- 3 days per month
- Typical pace
- 4–6 PRs / mo
- Cadence
- Monthly huddle + quarterly report
Fits: one or two versions behind, a test suite that needs attention, and a real intention to get current this year.
Start here →- Capacity
- 4–5 days per month
- Typical pace
- Up to 8 PRs / mo
- Cadence
- Monthly huddle + quarterly report
Fits: a large application several versions behind, a flaky suite, or a deadline. Twice the throughput of Shohin.
Start here →For a large, complex application, several codebases, or a fixed deadline. We set the pace and the priorities together after the assessment, and the plan can move up or down as the work changes.
Talk through a custom plan →Commitment and cancellation
Month to month. Change tier or cancel with 30 days’ notice. Unused capacity does not roll over. The value is the steady rhythm, not banked hours.
Separately scoped: strategic projects
A feature, an infrastructure migration, a stack of bug fixes. We quote it hourly before starting, you approve it, and it does not consume your maintenance capacity.
Separately scoped: rescue work
If the application is actively broken or unsupportable, we start with a one-week retainer to assess it and write a rescue plan, then agree what comes next.
Continuous analysis. Senior accountability.
Our agents monitor, analyse, prioritise and draft. A senior Rails engineer validates every recommendation and opens every pull request. Nothing merges unless your team approves it.
Upgrade and dependency health
Agents track deprecation warnings, gem compatibility and the version gap continuously, so the path to the next Rails and Ruby version is known before you commit to it.
Security and reliability
Advisories are triaged against your actual Gemfile the day they land, and new exceptions in your error tracker are grouped and ranked instead of piling up.
Performance and code health
We read your APM for regressions and slow endpoints, and score the codebase each month so progress on debt is visible rather than asserted.
Access and control
- Agents have read access to the repository and to the dashboards you already run: APM, exception tracking, CI, and analytics where the optional modules apply.
- Agents never push to a protected branch and never merge. Write access is limited to the working branches we open pull requests from.
- A named senior Rails engineer reviews the work and opens every pull request, with the reasoning and the blast radius written down.
- Your team reviews and merges. Nothing reaches production without your approval and your deploy process.
- Credentials and secrets stay in your systems. We work against your staging environment and your CI, and we scope access with you before anything is connected.
The impact of AI in Ruby and Rails upgrades
What could once be delivered by two senior software engineers can now be accomplished by pairing one senior software engineer with a team of AI sub-agents.
This is what we have observed across our current customer base, from one-person engineering teams to 100+ engineer organisations in the corporate world: roughly 50% more pull requests merged per month since January 2026, at the same monthly price and with the same senior review on every change.
On the call we would rather talk about the metrics that matter to you: versions closed, vulnerabilities resolved, dependency backlog cleared, and how much of your team’s time it took.
Accessibility (WCAG) and search and generative-engine optimisation are available as optional modules on Komono and above, for teams who need them.
The agents build on the open-source tooling we maintain for the Rails community:
- next_rails Dual boot an app and compare gem compatibility between Rails versions.
- skunk Score technical debt by combining code quality with churn.
- RubyCritic Code quality reports that show where a codebase hurts most.
- RailsBump Check which gem versions are compatible with which Rails versions.
- bundler-leak Scan a Gemfile for gem versions with known memory leaks.
- RubyMem The public database of leaky gem versions behind bundler-leak.
- Rails Upgrade Skill Our upgrade playbook, packaged as a Claude Code skill.
- Tech Debt Skill A Claude Code skill that finds and ranks technical debt.
Results, by engagement type
Not every result below came from a retainer. Each one is labelled with the engagement that produced it.
TitleLeaf — a one-person SaaS, current and compliant since 2023
A twenty-year-old content platform for educational book publishers, a few Rails versions behind, run by a solo founder with no team to spare. He started on the monthly plan in 2023 and is still on it.
What it produced: the codebase updated in stages, security patched, server compatibility kept solid, technical debt reduced without disrupting his publishers, plus PCI compliance and API updates scoped separately when his customers required them. Some months are light, some intensive. His involvement is a monthly huddle and a review before he deploys to production.
What really stands out to me is how little communication is needed. The Bonsai team sends regular reports, we huddle each month and after a quick review, I can go off and do my job. Their services are as essential as hosting: a non-negotiable.
Ruby 1.9 to 2.5 on a monolith nobody had dared patch in years. Eight months, two phases, zero disruptions or outages during rollout. Memory capacity up 25%, fewer application servers, lower infrastructure cost.
Read the case study →Average page load time on a self-described monolithic CRM/ERP application, cut by 40% after our Tune Report identified where the time was going.
Read the case study →Ruby 2.5 to 2.7 alongside it, in two phases, without pulling twenty engineers off the roadmap. We also rescaled their web servers, so performance went up on fewer machines.
Read the case study →Measurable outcomes, not vague praise.
An incredible partner from start to finish. Their engineers felt like a true extension of our team, working independently and consistently delivering ahead of schedule.
The team adapted to our environment and kept a clear focus on the goal, resisting the temptation of feature-type distractions. Their effort allowed us to keep up to date with Rails versions without detracting from progress on other goals.
In addition to producing high quality code they also suggest improvements to our development processes and mentor our new engineers.
Upgraded our legacy application to Rails 8.1 and Ruby 3.4 on time and on budget. They went beyond expectations and made the transition invisible to our users, without any negative business impact.
Before you book the call
It depends on how far behind you are and how much your test suite can carry. One version behind is usually a matter of months at the Komono pace. Two or three versions behind is a sequence we plan version by version. We give you a range after the month-one assessment, with what it assumes, rather than a number before we have read the code.
A repository and workflow assessment, a compatibility and risk map of your dependencies, a technical-health scorecard, an upgrade sequence agreed with you, and the first reviewable pull requests. You also get the shared channel and the monthly huddle that the engagement runs on from then.
No. Agents never push to a protected branch and never merge. They analyse, rank and draft. A senior Rails engineer validates the work and opens every pull request. Your team reviews and merges it. Two humans see every change before it can reach production.
The repository, and read access to the dashboards you already run: APM, exception tracking and CI, plus Search Console and analytics if you take the optional SEO module. Read-only wherever read-only is enough, write access limited to our working branches, and we scope all of it with you before anything is connected.
We will walk you through our data-handling policy on the call: which model providers are involved, what is sent to them, how long anything is retained, and the contractual terms that prevent your code being used for training. If your security team needs to review it first, ask and we will send it before the call.
That is the normal starting point, and it is what month one is for. Anyone with a Ruby or Rails application and some technical debt qualifies, whether you have a ranked list of pressing issues or no idea what is in there.
Most of the applications we take on are in that position. We add the coverage we need around whatever we are changing, and we tell you plainly where the suite is too weak to move safely. That assessment is part of the first month, not a surprise later.
We have worked on everything from MVPs to 500,000-line monoliths. Applications like that go on a custom plan, so the pace and the priorities match what your team can absorb and what the codebase will tolerate.
A shared async channel, a monthly huddle, and prompt review of our pull requests. We work with teams of one and teams of fifty. The only hard requirement is that someone on your side reviews and merges.
Included: Ruby and Rails upgrades, dependency management, security patching, tech debt work, performance and code health, and the quarterly technical-debt report. Separately scoped and quoted before we start: one-off strategic projects such as features or infrastructure migrations, and rescue work, which begins with a one-week assessment retainer.
Yes. It is month to month with 30 days’ notice to change tier or stop. Teams routinely move up for a heavy stretch of upgrade work and back down once they are current. Unused capacity does not roll over.
Most teams drop to a lighter plan and stay on it, because staying current is far cheaper than catching up: patches as they land, dependencies kept moving, and the next Rails version handled in the quarter it ships rather than three years later.
Find out what it will take to get current.
Thirty minutes with a Rails engineer to discuss the likely upgrade sequence, the first-month priorities, and the plan that fits your application. No sales script and no obligation.
- Reply within one business day
- Talk directly to senior engineers
- No pushy sales process
Plan my upgrade path
Tell us where your application is today. A Rails engineer comes to the call prepared to discuss the likely sequence, the major risks and the right starting plan.