Back to blog
4 min read
Maybe just use Rails

We are finally rewriting a legacy B2B SaaS that felt more like a tomb than a product. We want to pivot into another market, with different requirements and handlings. For the pivot, we didn’t overthink it. They say you need ’years of experience’ to pivot a B2B SaaS. We had zero years of Ruby, chose Rails anyway, and we’re already out-shipping teams ten times our size.

I’m a pragmatic guy. I want things to work and I want to enjoy it. Seeing complex features being implemented in a couple lines of code is a joy. Ruby on Rails delivers just that. It’s a reminder that programming isn’t meant to be a chore of boilerplate and configuration. In the backend, Rails is the ultimate partner.

The Beauty of Constraints

There is a profound peace in knowing exactly where things go. Validations, callbacks, migrations.. the fixed structure of Rails is not a cage. It is a foundation. When we need to achieve X, we don’t hold a week-long committee meeting to decide on a pattern. We just follow the path. No brainstorming needed, just a simple: “What’s the Rails way to achieve X?”.

The “Majestic Monolith” isn’t a marketing slogan. It’s a competitive advantage. We spend our brainpower on business logic instead of reinventing the wheel of state management. Or at least, we should be.

The SPA Tax

Despite our love for the backend, we fell for a trap: React. We told ourselves we needed it for the expertise, the massive libraries, and the safety of components like shadcn because we “suck at UI.”. We reached for Inertia.js to bridge the gap.

The result? We are spending 70% of our time in the frontend. That is a failure. It’s a tax we shouldn’t be paying. We’ve traded the simplicity of the server for a tangled web of JSON serialization, prop drilling, and client-side state synchronization. Maybe it’s a “skill issue.” Fine. But if a tool requires you to be a grandmaster just to move a button without breaking production, the tool is the problem, not you.

The Path Forward

We are considering the leap to Hotwire.

Is it the right choice? Maybe, maybe not. Nevertheless, it’s a fact that we need to change something. We need to build features, features that our customers care about. We can’t be battling the frontend when all of the magic lives on the backend. On the other side, we deeply care about UI/UX-Design, that’s why we had reached for the design-crutch called ShadCN. Don’t get me wrong, it’s an awesome project, we just can’t deal with React anymore.

The promise of Rails was always about the “One Person Framework.” It was about the ability to build a whole application without losing your soul to the complexity of a split-stack architecture.

If you find yourself fighting your tools more than you’re fighting your competitors, you’ve taken a wrong turn. Rails for the backend has been exactly what we needed; a masterclass in productivity. Now, it’s time to stop letting the frontend drag us back into the mud.

Maybe just use Rails. All of it.