Every few years someone publishes a “Rails is dead” post. Then a bunch of companies quietly ship their products on Rails, make money, and never write a blog post about it. That’s the Rails story in a nutshell.
I’ve been building on Rails since 2007. I’ve also built things in Node, Django, Laravel, and more Go than I’d like to admit. Here’s my honest take on where Rails stands in 2025 and why it’s still often the right call.
Convention Over Configuration Is Actually a Superpower
The thing people mock about Rails — that it makes decisions for you — is the thing that makes teams fast. When you join a Rails project, you know where things live. Models here. Controllers here. Views here. Routes in one file. Background jobs in one place.
In a Node project, you might have five different ways to structure the same application, and three of them will be in use simultaneously by the time you hit year two. Rails solves that by having opinions baked in. Those opinions are good opinions, built from years of real-world use by a large community.
Convention over configuration means less time debating architecture and more time building features. For a startup burning runway, that matters.
The Ecosystem Is Deeper Than People Think
Need user authentication? Devise. Background jobs? Sidekiq. File uploads? Active Storage with direct S3 support built in. Payments? Stripe-Ruby. Full-text search? Searchkick on top of Elasticsearch. Multi-tenancy? Apartment. API versioning? Versionist.
There is almost nothing a business application needs to do that doesn’t have a well-maintained, battle-tested gem for it. Compare that to the JavaScript ecosystem where you’re often stitching together a dozen half-finished packages and hoping they play nice together.
The Rails standard library — ActiveRecord, ActiveJob, Action Cable for WebSockets, Action Mailer, Active Storage — covers the majority of what most business apps need without reaching for anything external.
Productivity Per Developer Is Still Best-in-Class
I can take a Rails developer who’s been doing it for two years and put them on any Rails codebase in the world and they’ll be productive by end of day one. The mental model transfers almost completely.
That’s not true of most Node or Python codebases, where every team has invented their own architecture. The productivity compounding effect over years of development is significant.
The Real-World Case for Choosing Rails
Here’s when Rails makes sense:
You’re building a web application with a database. This is Rails’ native habitat. CRUD apps, SaaS platforms, internal tools, marketplaces, e-commerce — all of this is Rails country.
Your team is small and the deadline is real. You cannot afford to spend three weeks setting up infrastructure. Rails gives you a working app skeleton in an afternoon.
You need to change things fast. Startups pivot. Customer requirements change. Rails is designed to be changed. Migrations, the MVC structure, the test framework — all of it supports rapid iteration.
You want boring technology that works. Boring is underrated. GitHub ran on Rails. Shopify is Rails. Basecamp is Rails. Airbnb started on Rails. These are companies that had the resources to switch at any point and chose to stay.
Where Rails Is Not the Right Call
I’ll be straight about this. Rails is not ideal if:
- You’re building something that is primarily real-time event streaming at massive scale (though Action Cable handles most reasonable real-time needs)
- Your team has zero Ruby experience and you have a six-week deadline
- You’re building a pure API consumed by a mobile app and have strong Node expertise already on the team
Rails is not magic. It won’t fix a bad team or bad requirements. But it will get a good team to production faster than almost any alternative.
Performance Is a Non-Issue for Most Applications
“Rails doesn’t scale” is the perennial complaint from people who’ve never actually had to scale anything. The truth: Rails scales fine for the vast majority of business applications. GitHub serves millions of developers on Rails. Shopify processes billions in transactions on Rails.
The performance ceiling you’ll hit in Rails requires a level of traffic that most applications will never see. If you’re worried about Rails performance before you have users, you are optimizing for the wrong problem.
When you actually need to scale, you scale horizontally — more servers. That’s true of any framework. Before that point, Rails gives you the developer productivity to build features users actually want.
The Bottom Line
In 2025, Rails is mature, productive, and well-supported. The team at 37signals (Basecamp, Hey) continues to drive it forward. The community is active. The ecosystem is rich.
If you’re building a web application and you want to ship fast, maintain sanity, and not spend the next year arguing about which ORM to use — Rails is still the answer. Not because it’s trendy (it isn’t), but because it’s battle-tested and it works.
We build in Rails at Hamilton Development Company because it’s the best tool for most of the work our clients need done. If you’re considering a Rails project, let’s talk about what you’re building.