Ruby on Rails

Rails is what we build when a system genuinely needs per-user state — accounts, permissions, dashboards, transactions, anything where two visitors must see different pages. It is the tool we reach for the moment a static site stops being honest.

Why we still choose it

Rails made a bet in 2004 that a single, opinionated, well-documented framework beats an assembled stack, and two decades later the bet has paid. One repository holds the models, the views, the background jobs, the mailers and the migrations. A new engineer knows where things live before they have read anything, because they live where Rails says they live.

The alternative we are usually replacing is an architecture of six services that exist because a conference talk suggested they should. That shape has real costs — distributed transactions, six deployment pipelines, tracing to work out where a request went — and it buys nothing at all for an organisation serving a few hundred requests per second.

Rails has also absorbed the last decade of front-end fashion without requiring its users to. Hotwire and Turbo give you a responsive interface with server-side rendering, which means one language, one deployment, and no separate front-end build to keep alive.

How we run it

On NixOS, with PostgreSQL, behind nginx, on European hosting. The Ruby version, the gems and the system dependencies are all declared in the same repository as the application, so a new machine or a rollback is one command.

The honest limit

If you need to serve very high request volumes on a small budget, or you have a genuinely CPU-bound core, Rails is not the cheapest way to do it. It is, however, very often the cheapest way to get a correct system that a small team can still maintain in year four — and that is the constraint most organisations are actually under.