You have a quote for monthly Rails maintenance in your inbox, or you’re about to ask for one, and the proposal is vague about what actually arrives each month. “Ongoing support and updates” could describe a team actively managing your application’s health, or it could describe a loosely tracked pool of hours that gets billed whether or not anything useful happens, and from the proposal alone the two read the same. Here’s what a well-run retainer contains, month by month, so you can judge any offer on the table, including ours. If you’re still weighing whether maintenance is worth paying for at all, we’ve written separately about the real cost of an unmaintained Rails app; this piece assumes you’ve already decided it is, and want to know what you’re buying.

Whoever you hire, the scope should cover four areas: dependency and security patching, Ruby and Rails upgrades planned against the framework’s release calendar, performance and error monitoring, and a steady stream of small fixes and hardening work as the application evolves.

The upgrade work is the part with a clock attached, and it anchors everything else. Rails maintains each minor release series on a published schedule: bug fixes for one year after the first release in the series, security fixes for two years, and then the series reaches end-of-life. From that point on, any bug or security issue in your version is yours to deal with. New feature versions arrive roughly every six months, so an application that stands still drifts toward that edge on a timetable you can read off a calendar. A retainer exists to keep your application inside those support windows without you having to track any of it.

Be wary of a retainer that starts with someone writing code on day one, because it means they’re changing an application they don’t understand yet. Our engagements open with an audit of the codebase, infrastructure, and dependencies; the audit becomes a prioritized roadmap, and from there we embed as your long-term technical team. That sequence, audit to roadmap to embedded team, is the same one we describe on our Ruby on Rails services page. We’ve written in detail about what a week-one codebase audit actually finds, so we won’t repeat it here; the short version is that the roadmap comes out of what the audit found.

Whichever provider you choose, expect the same shape: they look first, they write down what they found and the order they plan to fix it in, and the steady monthly work starts after that.

Once an engagement reaches steady state, you should be able to see the retainer working without having to ask. A typical month, from your side of the table, includes:

• Pull requests you can read, each reviewed by a senior engineer before it merges.
• Upgrade progress measured against the Rails support windows, so an end-of-life deadline never surprises anyone. Our working guide to upgrading Rails 7 to 8 shows what that work involves on a real upgrade path.
• Security and dependency patches applied close to their release dates, while they’re still small and routine.
• A written summary in plain language: what changed, what comes next, and what needs a decision from you.

For our own retainers, the scope areas are the ones on the services page: Rails upgrades, performance optimization, security and dependency management, test coverage and CI/CD, code review and quality, and infrastructure and scaling. Two commitments worth holding us to: we keep client projects at 80 to 90 percent test coverage, and we deliver major Rails and Ruby upgrades with zero downtime.

Maintenance keeps an existing application healthy. Larger work, like a major feature build, a redesign, or a full rescue of an application that’s years behind, is scoped as its own project: a discovery conversation first, then an estimate and a proposal with defined scope and clear pricing. That separation protects you as much as it protects the provider. A retainer that quietly absorbs feature work stops doing maintenance. The hours meant for patching and upgrades get eaten by the feature backlog, and six months later the application is behind again even though the invoices never stopped. So when a proposal draws this line explicitly, read it as a good sign.

Every buyer eventually asks some version of the same question: if nothing broke this month, what did I pay for? It’s fair to ask, and the answer sits in the release calendar. With a new Rails feature version arriving roughly every six months and each series carrying a two-year security window, there’s always scheduled work in the queue. A quiet month is when your application gets ahead of those deadlines instead of falling behind them: the next upgrade moves forward before it’s urgent, dependencies get updated while the diffs are small, and test coverage grows around the code that will be touched next. The expensive alternative is an application that only receives attention when something forces the issue.

These questions separate a real maintenance operation from a bucket of hours. A good provider will have ready answers for all of them.

1. Who reviews the code before it merges? The answer should name a role: a senior engineer who did not write the change. If the entire service is one developer with nobody behind them, you’re buying a single point of failure.
2. What test coverage do you hold yourselves to? Any concrete number beats “we write tests”. Ours is 80 to 90 percent on client projects.
3. What is the upgrade cadence, and who decides it? Look for an answer tied to the Rails support calendar, because upgrades that wait for a quiet moment tend to wait forever.
4. What arrives in writing each month? You want named deliverables, a summary or a report you could forward to a board member. If communication is promised but never specified, you’ll end up being the one who asks for updates.
5. Who else can deploy if your lead engineer is unavailable? The deploy process should live in a pipeline that more than one person can run.
6. What would make you recommend a rewrite? The question is a deliberate trap. A provider whose first instinct on seeing an older codebase is a full rewrite is selling you their largest project. The better answer treats rewrites as rare and specific, with incremental upgrades as the default for an application that’s already serving customers.

If you want a quick read on where your own application stands before talking to anyone, the economics post ends with a five-minute self-assessment you can run today. And when you’re ready to measure a real offer against everything above, our Ruby on Rails services page describes how we run these engagements. You’ll be dealing with senior, US-based technical leadership, and we reply within one business day.