Get your Rails application current while your team keeps shipping your product roadmap
Consistent monthly Rails and Ruby upgrades, dependency updates, security fixes and code-health improvements, using a battle-tested approach: AI-powered agents and human approvals by our senior software engineers.
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
Tech debt compounds until the bill arrives all at once.
- No security patches. Every new advisory becomes yours to backport.
- Your stack falls behind. Stack updates pile up until feature work is blocked.
- Compliance checks catch it first. Security reviews for SOC 2 and HIPAA flag outdated versions before anything else.
- Complexity grows. Upgrades get bigger, riskier and harder to staff with every version you fall behind.
- Advisories don't wait. Vulnerable dependencies get triaged as they show up.
- Your stack stays supported. Dependencies and infrastructure stay current, so feature work keeps moving.
- Always audit-ready. A quarterly report shows supported versions and patched dependencies.
- Staying current becomes routine. The next version ships in its quarter, not three years later.
Your path from outdated to current
This retainer works toward a destination: secure dependencies, performant endpoints, and acceptable levels of technical debt. We tailor priorities and milestones to your project. We confirm the timing after the initial assessment, not before.
Stay current
We start with an assessment and your first upgrade PRs, then shift to ongoing maintenance.
One version at a time
We start with a supported Ruby, compatible dependencies and a plan for your next Rails version, then execute month by month.
A custom plan
We start with a risk map, an upgrade sequence and a budget / timeline to getting back to current. We take a security-first approach and prioritize action items based on your organization's needs and goals.
Agree on the path, then start making progress
In month one, we turn uncertainty into prioritized steps, and progress starts immediately.
Repository and workflow assessment
How the application is built, tested and shipped, and what that means for the upgrade plan.
Compatibility and risk map
What blocks the next version, what's unmaintained, and where the risks hide.
Technical-health scorecard
A scored baseline, so each quarterly report shows real progress in a metrics-driven way.
Upgrade sequence and priorities
You choose the priorities. We map the sequence to get there.
First reviewable pull requests
Progress in month one, backed by changes you can easily review and ship to production.
Choose a pace, not a mystery scope
Most applications two versions behind start with Komono. We confirm the right pace after reviewing your application. You don’t need to diagnose your own codebase to pick a plan.
Throughput ranges are what we typically deliver at each pace. Complexity varies, and 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 broken or unsupportable, we start with a one-week retainer to assess it and write a rescue plan, then agree on next steps.
Continuous analysis. Senior accountability.
Our agents monitor, analyze, prioritize and draft. A senior Rails engineer validates every recommendation and opens every pull request for your final approval.
Upgrade and dependency health
Agents continuously track deprecations, incompatible gems and version gaps. The path to your next Rails and Ruby version is known in advance.
Security and reliability
Advisories are triaged against your Gemfile the day they land, and new errors are grouped and ranked instead of piling up.
Performance and code health
Your APM is tracked for regressions and slow endpoints. The codebase is scored monthly so progress on technical debt remediation is visible and data-driven.
Access and control
- Agents have read access to your repository and existing dashboards (APM, exception tracking, CI and analytics where the optional modules apply).
- Agents never push to protected branches or merge. Write access is limited to the working branches PRs come from.
- Every pull request is opened by a named senior Rails engineer, who documents the reasoning and blast radius.
- You review and merge. Nothing reaches production without your approval and your deploy process.
- Credentials and secrets never leave your systems. We work in your staging environment and CI, scoping access together before anything connects.
The impact of AI in Ruby and Rails upgrades
What once took two senior engineers can now be done by one, paired with a team of AI sub-agents.
Across our customer base, from one-person teams to 100+ engineer organizations, we've seen roughly 50% more pull requests merged per month since January 2026, at the same price and the same senior review on every change.
On the call, we'd rather talk about what matters 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 optimization 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 labeled 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 analyze, 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.