What is Rails-way?

I have been working with Rails for the last 16 years, and I have spent the majority of my time extending clients’ teams, so I have had the opportunity to see plenty of Rails applications across different industries and varying levels of complexity. I can tell one thing: they all shared the same foundations but dealt differently with the complexity.

For me, this is the Rails-way. It’s flexibility. We all start the same way, accelerate thanks to conventions over configuration, and have plenty of useful built-in features that Rails provides. Some applications stay relatively small or semi-complex; others grow and become more complex, and this is the moment when different companies handle them differently.

You might think that the Rails way is the official way promoted by 37signals, but I don't think that’s true. Here is why.

There were no guides for handling complexity

Recently, we have been lucky to inspect open-source applications from the creators of Rails, 37signals: Fizzy, Campfire, and Writebook. The code there is super interesting and reveals the approach of the people building the core of Rails. We finally see what their way of handling the business logic in small and semi-complex apps:

• Writebook - 7k lines of code
• Campfire - 29k lines of code
• Fizzy - 89k lines of code

But it was not always the case. Before 2025, we had a few videos from DHH on how to write software well, as well as excellent posts on various topics on the 37signals dev blog. Official Rails guides taught thousands of Ruby developers how to launch their first MVP within weeks (with AI, we may be talking about days), but there were no guides regarding handling complexity.

This is the reason why I don’t think the approach promoted by 37signals can be called Rails-way. It’s Vanilla Rails, a way to build Rails applications by leveraging the batteries included in the framework itself. Rails-way is the community-driven approach to building Rails applications, where people build their own path through complexity based on their past experiences or recent findings.

Bold signs that you are dealing with the Rails-way

Andrzej recently wrote an excellent post about The Rails way in 2026. He pointed out some behaviors that are common for the apps that are trying to handle complexity. He mentioned the following patterns that are no longer working:

• Models that mix entity state with the process state via enums. If you have an Order model with a status enum, the value paid is not the entity's state; it’s a state of the process the entity is going through.
• Database columns like confirmation_email_sent_at are not properties of the entity; they are checkpoints in a workflow.

In past years, I would have had a hard time understanding this, but after digging deeper into Domain-Driven Design, I see the difference and how such a design makes complexity harder to handle. How about the other signs? I think you probably saw them many times:

• Two "God" models - one usually User and the other related to the business domain in which the app is operating. For the blogging app, it will be Article or Post; for the calendar app, it will be Event; and so on.
• Plenty of service objects; they sometimes follow the single responsibility principle, sometimes not. They usually trigger background jobs, and in fewer cases, they act as small wrappers or abstractions that are really unnecessary but do not make models fatter.
• The vocabulary used in the code differs from that used by business people.
• Complex ActiveRecord queries with multiple joins that span multiple different bounded contexts.
• Plenty of design patterns like form objects, facades, service objects, builders, strategies, decorators, and presenters mixed

Just to name a few patterns that I saw over and over again in Rails applications over the last dozen or so years. What worked earlier, when the app was smaller, now just makes things worse and painful to work with.

Rails-way is the real wild

I will mention this once again: Rails-way for the complex apps is the real wild. Often, the architecture itself is the result of multiple people working on it over multiple years, each with a different approach and experience, not strictly following a single approach.

Of course, there are plenty of apps with well-maintained codebases. Still, there are many where it becomes increasingly difficult to maintain the code as the codebase grows and developers' confidence shrinks in direct proportion.

Flexibility is always a double-edged sword, just like AI. It multiplies its input. In the next article, I will explore when and why the Rails-way no longer works and when you need a different approach.