Every year someone writes the obituary for Ruby on Rails. Every year Rails keeps shipping software. I’ve been building with it since version 1.2, and the question I get most often from clients is: why still Rails?
It’s a fair question. The landscape has changed enormously. Node.js, Go, Python/Django, and a dozen JavaScript frameworks have matured into legitimate options. But I keep coming back to Rails for one simple reason: it lets me build more, faster, with fewer surprises in production.
Let me explain what that actually means in practice.
Rails Is Opinionated, and That’s a Feature
Every Rails application follows the same conventions. Models in app/models. Controllers in app/controllers. Background jobs in app/jobs. Mailers in app/mailers. Anyone who’s worked with Rails for more than a month knows exactly where to look for anything.
When I pick up a legacy Rails app — even one I’ve never seen before — I can navigate it in minutes. When a client needs to add a developer to a project, the new person doesn’t need three weeks to map out the codebase. The map is already there, built into the framework.
That convention over configuration philosophy means less time making decisions about structure and more time solving actual business problems.
ActiveRecord Is Genuinely Excellent
I’ve used a lot of ORMs across different stacks. ActiveRecord isn’t perfect, but it’s the most productive ORM I’ve worked with for business applications.
The combination of readable queries, associations, validations, callbacks, and migrations that actually work — it’s hard to overstate how much time this saves. When I’m building an inventory management system or a CRM for a mid-market manufacturer, I’m not fighting the database abstraction layer. It gets out of my way.
The pitfalls are real — N+1 queries, callbacks that create hidden dependencies, fat models. But these are problems you avoid with discipline and good code review, not problems that require a different ORM.
The Testing Ecosystem Is Unmatched
If you’ve worked in Rails for any length of time, you’ve used RSpec. The testing culture in the Rails community is serious, and the tooling reflects that.
Factory Bot for test data. Shoulda Matchers for readable assertions. VCR for recording and replaying HTTP interactions. RSwag for API documentation generated from tests. The ecosystem around testing Rails applications is deep and battle-tested.
For business software, this matters enormously. Clients need software that works, and works consistently. A strong test suite is the difference between a codebase you can modify with confidence and one where every change is a gamble.
Active Job and Background Processing
Nearly every real business application needs to do things in the background. Send emails without making users wait. Process uploaded files. Sync data with third-party services. Rails’ Active Job provides a clean abstraction over queuing backends, and the combination with Sidekiq is rock-solid.
I’ve had Sidekiq queues running in production for years without significant issues. The monitoring, retry logic, and scheduling capabilities are everything you need for production-grade background processing.
When Rails Isn’t the Right Call
I’d rather talk you out of Rails when it’s not a fit than oversell it. Here’s when I’d recommend something else:
High-concurrency, low-latency APIs. If you’re building an API that needs to handle thousands of concurrent connections with sub-10ms response times, Go or Node.js are better tools. Rails’ threading model and Ruby’s GVL make this harder than it needs to be.
Real-time, event-driven systems. Action Cable exists, but if your entire application is built around real-time events — something like a trading platform or a live collaboration tool — you’ll fight Rails constantly. Elixir/Phoenix is genuinely better for this.
Tiny microservices. If you’re building a service that does one thing and has no meaningful domain model, Rails’ overhead isn’t worth it. A simple Sinatra app or a Go service is more appropriate.
Teams that don’t know Ruby. Rails’ productivity benefits assume a team that knows Ruby. Putting a JavaScript team on a Rails project because “it’s just MVC” is a recipe for pain.
What Rails Is Actually Good For
Rails excels at what most businesses actually need: applications with real domain complexity, multiple models with relationships, background processing, email, admin interfaces, third-party integrations, and user authentication.
Manufacturing inventory systems. Client portals. Order management. CRM tools. Reporting dashboards. Internal tools. These are the kinds of applications Rails has been knocking out of the park for twenty years, and it’s still doing it.
The productivity gains are real. I can deliver working software faster in Rails than in any other stack I’ve used. For clients who are paying by the week, that matters. For clients who need to launch before a competitor, that matters. For clients who need to iterate quickly based on real user feedback, that matters.
The Long Game
Businesses don’t want to rewrite their software every three years because the framework went out of fashion. Rails applications from 2010 are still running in production today. The upgrade path from version to version is well-documented. The community is stable and active.
When I build a Rails application for a client, I’m building something they can maintain, hire developers for, and extend over a 5-10 year horizon. That’s what most businesses actually need — not the latest hot framework, but something that still works when the trend has moved on.
That’s why I still bet on Rails.
Building something? I work with manufacturers and mid-market businesses that need software built right, not built fast and forgotten. Let’s talk.