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 exactly what 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’ll find five different ways to structure the same application, and three of them will be in use simultaneously by year two. Rails solves that by having opinions. Good opinions, built from years of real-world use.
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’s 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 stitching together a dozen half-finished packages and hoping they play nice.
The Rails standard library — ActiveRecord, ActiveJob, Action Cable for WebSockets, Action Mailer, Active Storage — covers most of what business apps need out of the box.
Productivity Per Developer Is Still Best-in-Class
I can take a Rails developer who’s been doing it for two years and drop them into any Rails codebase in the world. 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 over years of development is real.
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 Rails country.
Your team is small and the deadline is real. You can’t 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 runs on Rails. Shopify is Rails. Basecamp is Rails. Airbnb started on Rails. These companies 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 most applications will never see. If you’re worried about Rails performance before you have users, you’re 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.