I first started programming in Ruby back in 2008, and when I finally understood what Rails was, I felt genuinely cheated. You see, I had been trying to build something similar in Perl around 2005-2006, but I just didn't have the skills to pull it off. Maybe Perl was the wrong choice, but DHH managed to do it in Ruby—this relatively obscure Japanese language at the time—and he took the magic of Ruby's metaprogramming capabilities and turned it into an amazing framework called Rails. Even today, Rails is really the only thing I program in when I'm doing software development.

The thing about Rails is that yes, it took a long time to mature. The first version came out in the mid-2000s, but it wasn't good for many years. Then it was good, then it was bad again. I'm happy to report that now it is simply awesome.

The most amazing thing about Rails is that it's omakase—as DHH likes to put it, it's opinionated. It has a view on how things should be done. But DHH also says that Rails is a big tent. If you prefer to do things differently with hexagonal architectures or domain-driven design, feel free. It applies no restrictions. But there is this thing called the Rails way, and it is good.

When I see young programmers who think they're writing RESTful routes, but the routes are all updateUser, I feel like telling them to learn Rails. The way Rails teaches you architecture is much better than what you'll arrive at through your own experimentation. Of course, it's not the be-all and end-all of architectures and it's also possible to screw up while doing things the Rails way, and there are still many lessons to learn, but in general, when you arrive at an understanding of the Rails way, it's a solid understanding of how to build web applications.

Even Rails' sophistication when it comes to database migrations and its correct use of foreign keys and cascading deletes to maintain data integrity—all of these are things really worth learning. In fact, Rails powers really big businesses, and in 2025, it's no longer true that Rails doesn't scale. Yes, Ruby is slow, but it's very, very fast to develop in Rails.

When I was at Shaadi, I used to have this desire to hire someone whose job designation would simply be Rails programmer. Just so you'd have someone who could help you understand how to build, for example, authorization systems. In general, for any practice that was to be widely adopted, it's really good to reference how Rails does it because they provide a really solid starting point.

Two Rails Companies I'm Hiring for

I'm happy to announce that I have two Rails companies, both run by really strong founders.

The first is a company called GlomoPay. This is run by Sahil, who was at Gojek/Gopay which became GoTo Financial and has built payment rails (no pun intended) for a long time. His co-founder used to be the CEO of Stripe India. That's an amazing team building global payment infrastructure for India to the world.

The other company is Chatwoot. I love the team here—I think they're excellent programmers. Chatwoot builds an open-source customer support platform along with a hosted version. They're starting to catch serious traction. The code is of the highest quality, and all your work will be open source. Chatwoot is looking for an AI engineer and an engineering leader so that the founder Pranav can focus on bringing in the big deals.

If you're a Ruby/Rails programmer, I'd really recommend taking a look at these roles.

And if you don't know Ruby but are curious about it and want to learn under an amazing mentor, then for GlomoPay, it's great if you have finance/payments experience, and for Chatwoot, it would be amazing if you can work with AI. Check the job descriptions for further details. Both of these skill sets—payments and AI—will give you access to codebases written in Rails, which is something you must experience in your programming lifetime.

Check out the jobs on svsrecruiting here. Chatwoot and Glomopay