Most businesses treat software maintenance the same way they treat car maintenance: ignore it until something breaks, then spend more fixing the breakdown than they would have spent on regular service.
I understand the instinct. Maintenance doesn’t feel productive. You’re paying for something and the visible output is “the thing you already have still works.” But the alternative — letting a production Rails application drift — has predictable and expensive consequences.
Here’s what maintenance actually covers and why it matters.
Security Updates
Rails applications depend on dozens of gems. Those gems have known vulnerabilities — some discovered regularly, some occasionally, a few seriously dangerous ones. The Rails core team and gem maintainers issue security patches.
If you’re not applying them, your application is running with known vulnerabilities. Some of those vulnerabilities are exploitable by anyone who knows the CVE number and can reach your application over the internet.
Running bundle audit against a neglected Rails application usually finds several outdated gems with security advisories. The older the app, the worse this gets.
Security maintenance includes:
- Reviewing gems against the Ruby Advisory Database
- Applying security patches in a way that doesn’t break functionality
- Testing after updates to verify nothing changed
- Documenting the update history
Rails Version Upgrades
Rails is a living framework. Major versions (currently 7.x, heading to 8.x) bring significant improvements — performance, new features, and security hardening. Minor versions fix bugs and close vulnerabilities. Patch releases handle immediate security issues.
Running Rails 4 or 5 in 2025 isn’t just missing new features — it means your application depends on code that no longer receives security updates. That’s a real risk.
Upgrading Rails versions takes planning. There are deprecation warnings to address, gem compatibility to check, and database changes to manage. Done correctly, it’s manageable. Done wrong, or ignored until you’re four major versions behind, it becomes a significant project.
Maintenance includes staying on a supported Rails version or, for older applications, creating a roadmap to get there.
Dependency Management
Beyond Rails itself, your application depends on a Gemfile full of third-party libraries. These need regular attention:
Breaking changes. Gem maintainers release new major versions that change APIs. If you update a gem without checking the changelog, you might break something in production.
Abandoned gems. Some gems are no longer maintained. They work until they don’t — until something in Ruby or the OS changes and they fail in a way nobody’s going to fix.
Better alternatives. Sometimes a gem you’re using was the right choice five years ago but has been superseded by something more maintained and more capable.
Staying on top of dependencies is ongoing work — not a one-time cleanup.
Performance Monitoring
A Rails application that’s fast today might not be fast in six months. Query performance degrades as data grows. Traffic patterns change. New features introduce inefficiencies that only show up at scale.
Ongoing maintenance includes monitoring:
- Response time trends on key endpoints
- Database query performance
- Background job queue depth and processing time
- Memory usage and potential leaks
- Error rates and unusual patterns
Tools like Scout APM, Datadog, or even well-configured application logging can catch problems before they affect users. The goal is finding issues during normal monitoring, not during an incident.
Proactive Bug Fixes and Technical Debt
Every production application accumulates technical debt. Code that was written quickly for a deadline. Workarounds for library limitations that no longer apply. Features that were built one way and then requirements changed but the code didn’t fully follow.
Left alone, this debt compounds. It slows down new development because the underlying code is hard to change. It contributes to bugs because the system doesn’t behave the way anyone expects.
Maintenance should include regular, incremental work on technical debt — not a big “tech debt sprint” every year, but small improvements woven into the ongoing work.
What a Maintenance Retainer Looks Like
For most Rails applications in production, a monthly maintenance retainer makes sense. This covers:
- Monthly gem security audit and patching
- Monitoring review and response to any issues
- On-call availability for emergencies during business hours
- Small bug fixes and improvements within the retained hours
- Quarterly review of dependencies and Rails version status
The cost depends on the application’s complexity and the hours needed, but most applications can be well-maintained for a few hundred to a couple thousand dollars per month.
That’s a fraction of what it costs to respond to a security incident or rebuild features that broke because nobody was watching the dependencies.
When Maintenance Is Not Enough
Sometimes I do a maintenance assessment and the honest answer is: this application has accumulated so much debt that maintenance isn’t enough. It needs a more significant investment — a controlled rebuild, a major version upgrade project, or a performance and architecture overhaul.
I’ll tell you that directly, with a clear recommendation for what the path forward looks like. I’d rather give you an accurate assessment of the situation than tell you what you want to hear and collect a maintenance retainer on an application that’s heading for a cliff.
If you have a Rails application in production and aren’t sure whether it’s being properly maintained, let’s have that conversation. I offer assessment calls specifically to help businesses understand the state of their applications without a sales agenda.