Choose a monthly retainer when your Rails app is critical to the business and you want steady progress on patches and upgrades. Choose a prepaid block of hours when the app is stable and changes are occasional, and someone on your side will make sure upgrades still get scheduled. Choose on-demand hourly support only for low-risk internal tools where nobody needs to watch production. If the app is central to revenue and you have no in-house technical lead, look for one team that owns maintenance, upgrades and new work together.
This guide compares the three common Rails maintenance models side by side and shows which app each one fits. For what maintenance should include and what drives the budget, see Ruby on Rails maintenance and support: what it includes and how to budget for it.
The three models at a glance
| Monthly retainer | Prepaid block of hours | On-demand, billed hourly | |
|---|---|---|---|
| How it works | A set amount of engineering time each month for maintenance work | Hours bought in advance and drawn down as work happens | You call when you need help |
| Best fit | Critical apps that need steady patching and upgrades | Stable apps with occasional changes | Low-risk internal tools |
| Who watches production | The maintenance team, as part of the work | Usually you, unless monitoring is agreed | Nobody, until you notice a problem |
| Upgrades | Planned against Rails and Ruby support dates | Happen if someone spends hours on them | Usually wait until something breaks |
| Main risk | An incident uses the month's capacity | Upgrades slip because nobody spends hours until something breaks | Slow response and a new person learning the codebase each time |
Monthly retainer
A retainer is a fixed amount of engineering time every month for security and dependency patching, Ruby and Rails upgrades, monitoring, incident response and small fixes. Because the time is there every month, upgrades move forward on a schedule instead of waiting for a quiet week that never comes.
It fits when the app takes payments, serves customers, or runs a process the business stops without. Before you sign, ask whether unused time rolls over and what happens when an incident uses it all: do upgrades pause, or is extra time added, and who approves it?
Prepaid block of hours
You buy a block of hours up front and the team draws it down as work happens. It is flexible and easy to budget for an app that rarely changes.
The weakness is that nothing happens unless someone asks for it. Gem updates and version upgrades are easy to postpone when every hour is visible on an invoice, and the app drifts out of support quietly. If you choose this model, put the upgrade dates in the agreement and agree who checks the error tracker.
On-demand, billed hourly
You call a developer when something breaks or a small change is needed. There is no monthly commitment, and for a low-risk internal tool that is often enough.
For anything customers depend on, it is the riskiest option. No one is watching the app, response time depends on who is free, and each request may start with a developer reading the codebase from scratch. The cost of that learning lands on the urgent day, not a quiet one.
Which app fits which model
| Your app | Likely starting point |
|---|---|
| Customer-facing or revenue-critical, on a supported Rails version | Monthly retainer |
| Several versions behind, few tests | An audit and catch-up phase first, then a retainer |
| Stable internal app with occasional changes | Prepaid hours, with upgrade dates agreed in writing |
| Low-risk internal tool, downtime is an inconvenience | On-demand support |
| Central to revenue, no in-house technical lead | One team that owns maintenance, upgrades and new work |
The size of the app matters less than how far behind it is, how much test coverage it has, and how fast you need someone to respond when it breaks. An app several major versions behind needs a catch-up plan before any steady model works; we cover that in Upgrading an old Rails app without a rewrite.
Not sure which model your app needs? Bring the Rails and Ruby versions and a short description of how it is deployed to a Systems Discovery Call. We will tell you what the first phase should cover.
Signs your current model no longer fits
- Gems are outdated and security patches keep piling up.
- The app runs on an old Rails or Ruby version you are afraid to touch.
- Upgrades wait until something breaks.
- Problems surface when users report them, not before.
- Prepaid hours go unused while the version gap grows.
Rails maintenance runs on a calendar you do not control: each release series gets security fixes for a limited time, so a model that never schedules upgrades eventually leaves you on an unsupported version. Our post on Rails 8.0 end of security support shows what that looks like in practice.
Questions to ask whichever model you choose
- What is in scope, and what is a separate project? Get the boundary in writing.
- How fast will someone respond to a production problem, in business hours and out of hours?
- Who decides the upgrade schedule, and is it tied to the Rails and Ruby support dates?
- What will we receive each month in writing?
- Who else can deploy if the main developer is away?
- Do code, credentials, hosting and monitoring accounts all sit under our company?
How we approach it
We start with an audit of the version gap, the state of the tests, and the riskiest areas, which turns a guess into a plan with a first phase and a steady state. Then we keep the app patched, upgraded on schedule, monitored and fixed, with a short monthly summary in plain language: what shipped, what is at risk, and what decisions are needed from you. Zentap, a Rails platform serving 20,000+ real estate agents, is one we work on long-term. Details are on our Ruby on Rails maintenance and support page, and if the previous developer has left, our Rails app takeover page covers the handover.
Common questions
Is a Rails maintenance retainer worth it for a small app?
If the app is customer-facing or takes payments, usually yes, because the retainer is what keeps upgrades on schedule. For a small internal tool, prepaid hours or on-demand support is often enough.
Can we start with prepaid hours and move to a retainer later?
Yes. You can start with an audit and a block of hours, then move to a monthly arrangement once you see how much work the app needs each month.
Does on-demand support include monitoring?
Usually not. On-demand means someone responds when you call. If you want someone watching errors, uptime and background jobs, that has to be agreed as part of a retainer or a separate scope.
Next step
If you are deciding how to maintain your Rails app, book a Systems Discovery Call. It is 45 minutes on your application, its versions, and what the business depends on. You leave with a clear picture of the first phase and the ongoing work, whether you hire us or not.
Farooq Ch
Nov 2026