It's the first question a business owner asks, and it's the right one: how much is this going to cost? Behind it lies a very concrete fear — the never-ending quote, the hourly bill that swells week after week without anyone ever knowing where it stops. When someone talks to you about "upgrading your Rails application," you don't hear a technical operation. You hear a blank cheque. This article exists to defuse that: to explain honestly what makes the price vary, and why we charge a fixed price rather than by the hour.
The price depends on three things, not one
There's no such thing as a "Rails upgrade rate" the way there's a price per litre of fuel. The real cost depends on the gap to be bridged and the starting state of your application. Three factors account for most of the bill.
The version gap. Going from Rails 7.1 to 7.2 is a short jump: little changes, and the road is well marked. Bringing an application that has stayed on Rails 5 or 6 up to the current version is another story entirely — you cross several major versions, each with its breaking changes, its dependencies to update along the way, and its behaviours that change silently. The wider the gap, the more ground there is to cover.
The size of the application. An app with ten models and three forms is nothing like a business platform built over several years, with its integrations, its background jobs and its accumulated edge cases. The more code there is, the more surface there is to check after every change.
Whether or not there are tests. This is the factor everyone forgets, and it's often the most decisive one. An application covered by a solid test suite gets upgraded with a safety net: you make a change, you run the tests, and you immediately know if something broke. Without tests, every modification has to be checked by hand, and the risk of a silent regression climbs. An app without tests doesn't cost more because it's being "punished" — it costs more because you have to rebuild the confidence that tests would have given you for free.
Why we charge a fixed price, not by the hour
Hourly billing rests on a simple idea: the more time I spend, the more you pay. That made sense when a developer's time was the scarce resource. But with us, the link between time spent and value produced is broken. We work with AI agents that get through in a few hours what used to take days. If we billed by time, we'd be absurdly penalised for being efficient — and you'd have no visibility on the total.
Fixed pricing flips the logic. You're not paying for our hours, you're paying for a result: an upgraded application, one that runs and has been verified. The risk of overrun is ours to carry, not yours. If the migration turns out to be more tangled than expected, that's not your financial problem — it's ours. It's exactly the opposite of the blank cheque you were dreading.
A three-tier logic
For fixed pricing to hold without nasty surprises for anyone, it has to be set at the right moment. Hence the way we work, in three tiers.
First tier: the fixed-price audit (490 €). We start by looking. We open your application, we measure the version gap, the size of the code, the state of the tests — precisely the three factors above. At the end, you get a clear assessment and an honest quote for what comes next. That amount is known in advance, it doesn't move, and it commits you to nothing further. It's what makes the rest possible: we only quote an upgrade after having looked, never by guesswork.
Second tier: the upgrade at a flat rate. Armed with the audit, we offer you a flat rate for the operation itself. One price, one scope, an upgraded application at the end. You know what you're paying before you say yes.
Third tier: the subscription (from 290 €/month). Once up to date, an application doesn't stay that way on its own — versions keep moving forward, security patches drop every month. The subscription keeps your app up to date over time, to avoid letting a new gap reform and having to pay for a big catch-up again one day. You'll find the details of these plans on our pricing page.
The audit first, the commitment after
The real answer to "how much does it cost" isn't a number thrown out at random before seeing your code — that would be dishonest, and it would take you straight back to the fear of the open-ended bill. The real answer is a fixed-price audit that leads to a clear quote, which you're free to follow or not. You only commit to the upgrade once you know its exact price.
If your Rails application has fallen behind and you finally want a number instead of a worry, start there. Discover our approach on the maintenance page, see the details of the plans on the pricing page, or explore our other articles in the resources.