Why I Still Reach for Rails After a Decade

I've spent more than ten years building backends, and I've worked across a fair range of stacks. But when someone hands me a half-formed idea and asks "can we have something working by next week?", I almost always reach for Ruby on Rails. It's not nostalgia. Rails keeps earning that choice. Here's what keeps me coming back.

Convention over configuration is a superpower

Rails made a bet a long time ago: most web apps need the same things, so the framework should make sensible decisions for you. That bet still pays off every single day. I don't spend the first week of a project wiring up folder structures, ORMs, routers, and build tools. I spend it building the actual product.

The result is that going from nothing to a working prototype is genuinely fast:

class CreateArticles < ActiveRecord::Migration[7.1]
  def change
    create_table :articles do |t|
      t.string :title
      t.text :body
      t.references :author, foreign_key: true
      t.timestamps
    end
  end
end

# app/models/article.rb
class Article < ApplicationRecord
  belongs_to :author
  validates :title, presence: true
end

A migration, a model, a few validations — and you have a real, persisted, validated resource. That density is the whole point. Less ceremony, more product.

The gem ecosystem is unmatched

Whatever boring-but-necessary thing you need — authentication, background jobs, file uploads, admin dashboards, payment integrations — there is almost certainly a mature, battle-tested gem for it. I've shipped entire integration services where the hard parts were already solved by libraries that thousands of teams rely on in production.

That ecosystem is a massive multiplier. It means I get to spend my effort on the 20% of the app that's actually unique to the business, instead of reinventing the 80% that every app needs.

Community and longevity

Rails has been around long enough that the answers exist. When I hit a wall, the solution is usually a search away, written by someone who solved it years ago. That maturity is underrated — newer frameworks can be exciting, but you often pay for that excitement in unanswered questions and breaking changes.

I've contributed back to Rails myself, and being even a small part of that community gave me real appreciation for how carefully it's maintained. It's not a framework chasing trends; it's one that takes backward compatibility and developer happiness seriously, release after release.

And yes, it scales

The old "but does it scale?" criticism never really matched reality. Plenty of large, high-traffic products run on Rails. In my experience the bottleneck is almost never the framework — it's database design, N+1 queries, and missing caching, all of which you'd face in any stack. Rails actually gives you good tools to handle each of them.

The trick is that Rails lets you stay productive while you grow, instead of forcing you to over-engineer on day one for a scale you may never reach.

Boring, productive, and still a joy

What I value most about Rails is that it's "boring" in the best way — predictable, well-trodden, and quietly powerful — while still being a genuine pleasure to write. A decade in, it remains the fastest path I know from "I have an idea" to "people are using it." That's a rare combination, and it's why Rails keeps its place in my toolbox.