Why Rails in 2025

"Rails? In 2025? Seriously?"

I've gotten this reaction a lot. Usually followed by suggestions to use Next.js, or Go, or Rust, or whatever the cool kids are using this month.

Let me tell you why I'm ignoring all of them.

The speed argument

I've been writing Rails since 2012. Thirteen years. I dream in ActiveRecord. I can scaffold a complete feature—model, controller, views, tests—faster than most people can set up a new Next.js project.

That's not bragging. That's just compound experience.

When you're building 31 products as a solo founder, you can't afford to learn new frameworks. You need to move fast. I move fastest in Rails.

"But Rails doesn't scale!"

Shopify handles $10 billion in transactions. On Rails.

GitHub serves millions of developers. On Rails.

Airbnb grew to a $100 billion company. On Rails.

The "Rails doesn't scale" thing was maybe true in 2008. It's definitely not true now. And honestly, it was never about Rails—it was about developers writing slow code.

Rails makes it easy to write slow code. But that's actually fine. You ship fast first, then optimize the 5% of code that actually matters.

Premature optimization is still the root of all evil. Rails embraces that truth.

The Hotwire revolution

The old knock on Rails was the frontend. "You need React for a modern UI."

Then Hotwire came out and killed that argument.

Turbo gives you SPA-like page transitions with zero JavaScript. Stimulus handles the interactive bits. Turbo Streams do real-time updates.

Every Brainz Lab dashboard uses Hotwire. They feel snappy. They look modern. Users have no idea there's no React behind them—and they don't care.

I write server-rendered HTML with sprinkles of Stimulus. It works. It's simple. I can debug it without wanting to throw my laptop out the window.

The AI advantage nobody talks about

Here's the secret weapon: Claude is really good at Rails.

It's seen millions of Rails codebases in its training data. It knows the conventions. It understands ActiveRecord. It can write a complete controller with proper error handling in one shot.

When I pair with Claude on Rails code, it's like working with a senior Rails developer. The suggestions are idiomatic. The patterns are correct. The code just works.

When I've tried other stacks with Claude, it's noticeably worse. More hallucinations. Outdated patterns. More back-and-forth to get something working.

This compounds. Better AI assistance = faster shipping = more products = more learning = even faster shipping.

Rails + Claude is a cheat code. I'm not giving that up.

The "boring technology" advantage

Rails isn't exciting. It doesn't get you Twitter followers. Nobody's writing breathless blog posts about Rails innovations.

That's the point.

I want boring technology. I want technology where all the edge cases are documented. Where Stack Overflow has answers from 2015 that still work. Where the error messages lead to solutions.

Exciting technology means surprises. I don't want surprises. I want to ship.

The confession

Here's the truth: I love Rails.

Not in an objective "it's the best tool for the job" way. In a "this is how my brain works" way.

Rails conventions match how I think about software. Request comes in, controller handles it, model does the logic, view renders the response. Clean. Linear. Understandable.

Could I learn Next.js? Sure. Would I be as productive? Not for years.

Life's too short to fight your tools. I'm building with what I know.

31 products. Rails. Let's go.

— Andres