Somebody promised you speed and named Ruby on Rails

A framework that already made the decisions

Rails is a web framework written in the Ruby language, and it runs on a server rather than in your visitor's browser. It holds the records, decides what happens when somebody submits a form, and builds the page that comes back. It's open source under the MIT licence, so there's no licence to buy and nobody to renew with.

What separates it from most names in that part of a quote is how much it settles before anyone starts. Where files go. What the database table is called. Which web address reaches which piece of code. All fixed in advance, by the framework, rather than argued out by whoever is typing.

The phrase for that is convention over configuration, and it's the thing to understand about the tool. A team that accepts the conventions writes almost no arrangement code and spends its time on your product. A team that fights them writes a great deal of both.

It was pulled out of a real product, and it shows

Rails wasn't designed as a framework and then applied to something. David Heinemeier Hansson extracted it from Basecamp, a product he was already building, and released it in 2004. That origin explains most of how it behaves.

The problem it solved wasn't technical. It was that a very small team shipping a real product has no time to hold opinions about where files belong. So Rails holds them for you, and the project's published doctrine puts optimising for the programmer's happiness at the top of its list, ahead of things most engineering documents would rank first.

You can find that unserious and still want the result. Two decades on, every Rails application is arranged the same way, so a developer who has never seen your codebase can open it and know where to look.

What arrives in the box

The speed isn't the language. It's that most of a web application is already written, and already wired to the rest of it.

Reading and writing the database, changing its structure safely as the product changes, sending email, running work in the background, accepting file uploads, and a testing setup. All included, all expecting to be used together. On a lighter toolkit somebody picks each of those separately, then spends real time making them agree.

Age helps here. The awkward cases have been hit by other people, the answers are written down, and there's a library for most things you'd otherwise commission. Shopify and GitHub both run very large applications on Rails, which settles whether it holds up at size.

It isn't alone in this category. If your proposal had said Django or Laravel instead, most of this page would read the same in a different language, and none of the three is the wrong answer for ordinary business software.

Where the opinions start costing you

The conventions are a bargain, and the bill arrives when your problem isn't the shape Rails expects. It expects records that mostly belong to one owner, forms that create and change them, and pages that list them. Accounts, invoices, bookings, approvals, permissions. Most business software, in other words, and inside that shape it's very hard to beat.

Outside it you're doing two jobs: building the thing, and negotiating with a framework that has a view about it. That shows up around unusual data models, anything heavily live or streaming, and any product where the calculation is the point rather than the record of it. Ruby is not where the data and machine learning libraries live, so a product built around those runs two languages and staffs both.

There's a raw speed question too, and it's smaller than the internet suggests. Ruby is slower per request than a compiled language, recent versions have narrowed that, and for almost all business software the database and the network decide the response time anyway. Teams that genuinely hit the language's ceiling tend to be at a size where the hosting bill is the argument, not a page that feels slow.

Who has to be around afterwards

The technical questions are the easy half of this decision. Rails moves. New versions arrive regularly, older series stop receiving security fixes after a published window, and every library the application depends on runs to its own timetable. Left alone for two years, the upgrade stops being a task somebody schedules and becomes a quote somebody dreads.

Hiring is the honest constraint. Ruby isn't where most new developers start now, and the pool of working Ruby developers is a fraction of the JavaScript or Python pool. That isn't a dead end. It's a smaller market, a longer search to fill a role, and a shorter list of firms who can take the work over.

The same fact has an upside. The people still writing Rails mostly chose it rather than fell into it, so the pool skews experienced. And because the arrangement is the same everywhere, whoever picks yours up next doesn't have to learn your last developer's personal filing system first.

So settle that before you settle the framework. Name the person who owns this codebase in year two, or accept that the answer is nobody.