Most businesses treat software maintenance like car maintenance: ignore it until something breaks, then pay triple to fix the damage.
I get it. Maintenance doesn’t feel productive. You’re writing a check and the visible output is “the thing you already have still works.” But letting a production Rails app drift has predictable, expensive consequences.
Here’s what maintenance actually covers and why it matters.
Security Updates
Rails applications depend on dozens of gems. Those gems have vulnerabilities — some discovered regularly, some occasionally, a few that are genuinely dangerous. The Rails core team and gem maintainers issue patches.
If you’re not applying them, your application is running with known vulnerabilities. Some are exploitable by anyone who knows the CVE number and can reach your app over the internet.
Run bundle audit against a neglected Rails app and you’ll usually find several outdated gems with security advisories. The older the app, the worse it gets.
Security maintenance includes:
- Reviewing gems against the Ruby Advisory Database
- Applying security patches without breaking 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 real improvements — performance, new features, 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 app depends on code that no longer receives security updates. That’s a real risk.
Upgrading Rails takes planning. Deprecation warnings to address, gem compatibility to check, 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 means staying on a supported Rails version or, for older apps, creating a roadmap to get there.
Dependency Management
Beyond Rails itself, your app depends on a Gemfile full of third-party libraries. These need regular attention:
Breaking changes. Gem maintainers release new major versions that change APIs. Update without checking the changelog and 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 app 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 app accumulates technical debt. Code written quickly for a deadline. Workarounds for library limitations that no longer apply. Features built one way, 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 apps 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 app’s complexity and the hours needed, but most apps 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 app 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 than tell you what you want to hear and collect a maintenance retainer on an app that’s heading for a cliff.
If you have a Rails app 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.