Your Rails app, one version newer, with your tests passing.
A fixed-price upgrade for small Ruby on Rails apps. The work is done by AI agents and checked by your own test suite and a second AI model from a different provider.
See a worked example: an open-source app moved from Rails 7.2 to 8.0. Its tests caught one of the three real problems we found.
Never more than £1,495 to reach the latest Rails from any version, for a small app.
Any Ruby upgrade a step needs is included.
You pay after delivery. If we can't get your tests passing, you pay nothing. No VAT is charged.
Why now
Only Rails 8.0 and 8.1 still get security fixes, and 8.0's end on 7 November 2026. After that, only 8.1 is supported. (Rails maintenance policy)
So most older apps need more than one step. We do them one at a time, and each is tested and merged before the next. We'll tell you up front how many steps yours needs. On Rails 7.2, that's two steps, to 8.0 and then 8.1: £990. From Rails 7.0 or older, it's £1,495 however many steps it takes.
How it works
- Send us your
Gemfile.lock, your Ruby version and the database you run in production. We'll tell you if the job fits, which version step we'd take, and anything you should know first, such as how many steps it takes and whether it needs a newer Ruby. - Give us access to that one repository, or send us a copy. No production passwords, keys or customer data.
- We do the upgrade. We run your full test suite before we start and again after the change. A second AI model, from a different provider, reviews the whole change before you see it.
- You get a pull request with a short report: what changed, what we checked, what we couldn't check, and what to test by hand.
- You review it, try it on your staging site and merge it. You pay within 14 days of delivery. If something we changed breaks within that time, we fix it at no cost.
What we check, and what we don't
We check
- Your test suite passes before we start, and passes after the upgrade.
- Rails' own upgrade steps: changed framework settings and new defaults. We list any new defaults we left switched off.
- Deprecation warnings, before and after.
- The app starts in production mode on our machine.
- Your tests on the database you use in production, where we can. If we can't, the report says so.
- Known silent changes for that version step: things that change behaviour without failing a test.
- Gems are updated only as far as the new version needs.
- A second AI model, from a different provider, reviews the full change.
We don't check
- Anything your tests don't cover. If a feature has no tests, a break there could get past us. We'll point out thin spots we notice.
- Your live site. We never touch your servers, data or deployments.
- Third-party services that need live keys, and performance under real traffic.
- Security. This isn't a security audit.
- A human engineer doesn't review every line of every job.
Limits on every job
- One version step per pull request. Each step is tested, reviewed and merged by you before we start the next.
- Your tests must already pass on your main branch. If they don't, we stop and you pay nothing.
- No production credentials or live data. We work on the code only.
- You review and merge. You stay in control of your app and when it ships.
- Gems with no compatible version. If it's only used in development, we remove it and tell you. If your app needs it to run, we stop and talk to you before going further.
- Small apps. If yours is too big to do well at this price, we'll tell you before we start.
Your code
We treat your code as confidential. AI models from third-party providers process it to do the work; we'll name them in our terms before you share anything. We delete our copy within 30 days of the job ending. You own the result. Written terms are agreed before any work starts.
After the upgrade
We can keep your app on supported versions every month. Ask us.
Rather sell than upgrade? We also buy small Rails apps. Tell us about yours.