What is Ruby on Rails and why should I use it?

I have written Rails applications for more than fifteen years and contributed to the framework itself, so I am not a neutral observer. But the question in the title comes up in almost every first call with a new client, and it deserves a straight answer rather than a sales pitch.

What Ruby on Rails actually is

Rails is a web application framework written in Ruby, a dynamic, object-oriented language designed to be readable by humans first. Rails organises an application into models that talk to the database, views that render HTML or JSON, and controllers that connect the two. That pattern, Model-View-Controller, is old and well understood, which is part of the appeal.

The framework is opinionated. It decides where files live, how database tables are named, how URLs map to code and how tests are structured. You can override almost all of it, but you rarely need to. This is what Rails calls convention over configuration: the framework makes the common decisions so you can spend your time on the parts of the product that are actually different.

What comes in the box

• Active Record for the database: migrations, associations, validations and a query interface that reads like English.
• Action Mailer and Active Job for email and background work, with Solid Queue as the default queue backend since Rails 8.
• Active Storage for file uploads to S3, Google Cloud or disk, with image variants built in.
• Hotwire for fast, dynamic interfaces without a separate JavaScript build.
• Authentication generator, caching, WebSockets, internationalisation and a full test framework, all following the same conventions.
• Kamal for deploying to any server with Docker in a single command.

The point is not that any one of these is unique. It is that they are designed together, upgraded together and documented together. You are not assembling a stack from twenty libraries and hoping their versions agree.

Why teams still choose it

Speed to a working product

A Rails developer can have authentication, a data model, an admin interface and a deployable application in days, not weeks. For a startup validating an idea, or a business replacing a spreadsheet with software, that speed is the whole game.

Maturity

Rails has been in production since 2004. The problems you will hit have been hit before, and the answers are in the guides, on Stack Overflow, or in a well-maintained gem. Security patches arrive promptly and upgrades between versions are documented in detail.

Readable code

Ruby optimises for the person reading the code, which is usually not the person who wrote it. Six months later, a new developer can open a Rails application and find their way around, because every Rails application is laid out the same way.

Proven at scale

GitHub, Shopify, Basecamp, GitLab and Airbnb have all run on Rails at serious scale. The framework is not the bottleneck for the vast majority of products; the database and the architecture around it are, and those are the same problems in any language.

Rails calls itself the one-person framework for a reason. A single experienced developer can build and run a real business on it.

When I would not use it

Rails is a poor fit for heavy numerical computation, machine learning pipelines or anything where raw CPU throughput is the product. It is overkill for a brochure site with no database, where a static site generator is simpler. And if your team already has deep expertise in Django, Laravel or Node, switching frameworks to gain Rails' conveniences rarely pays off. The best stack is usually the one your team can move fastest in.

What to do next

If you are starting a new product, read my guide on starting a Rails project the right way and the stack I reach for today. If you have an existing Rails application that needs an upgrade or a second pair of hands, get in touch and tell me where it hurts.