When we started Lago, we picked Ruby on Rails for our core API. The choice was obvious because our founding team had decade of Rails experience. Rails was the fastest way we could build an API product.

Today, we’ve receive millions of API calls a day. We’ve upgraded through multiple Ruby/Rails versions. Maybe that sounds silly in a world where young, Python/Go/JS-wielding entitlements have never even heard of Ruby.

We do admit that we’ve added Go and Rust where it makes sense.

But if we were starting today, in 2025, we’d still choose Rails.

The boring superpower: shipping speed

Nowadays, the companies championing Ruby are no longer fast-growing startups run by CEOs in their 20s. They’re mature enterprises run by middle-aged dads:

Shopify, Basecamp, GitHub, GitLab… they’re not exactly trendy AI startups. You could deduce that Rails is outdated, but another view on that fact is that it has great longevity.

When we started, we frankly chose Rails for a practical reason: We had the most experience with it. And I think that’s an important lesson: Don’t choose your tech stack based on your YC batch mates or whatever the trendiest startup uses. Choose it based on how *you* can deliver the best product.

So that’s what we did. We started Lago with Rails’ API-only mode, which trims the middleware stack, skips view rendering, and keeps the good stuff: migrations, validations, Active Record, background jobs. That meant less time gluing things together and more time shipping product.

But what about scaling?

One of the biggest criticisms of Rails is that it doesn’t scale. Especially in an age where companies only take months to grow to dozens of millions in ARR, scaling is important. But scale is an architecture and operations problem, not a framework limit.

Even at our scale—processing millions of events and API requests—we’re nowhere near the limits (and that’s true for Shopify, GitHub, GitLab etc. too). There are a few reasons for this:

- Rails 8 made operations simpler. We can go from code to production containers without a PaaS tax.
- Redis + Sidekiq is battle-tested and highly scalable
- We’re starting to implement Ruby Fibers to add asynchronous concurrency
- Rails with Puma, autoscaling, and sane caching make the framework extremely scalable.

Velocity still matters most than almost anything when you’re building a product company. Rails gives us that without demanding microservice sprawl.

But that doesn’t mean Rails is perfect. There are tradeoffs.

The Rails imperfections we live with

Some things require discipline on Ruby:

- Performance & memory: Do the wrong things and you’ll pay for it.
- Concurrency: CRuby’s Global VM Lock means only one thread runs Ruby code at a time. This is where we sometimes offload to Go/Rust.
- Magic: Rails can be too fancy. That’s why we favor explicit, boring code and avoid gem dependencies.

Every programming language has its downsides. Knowing them takes experience. We love Rails because we know it so well that we understand the downsides, how to avoid them—and when to offload tasks.

How we diversify programming languages

We don’t force Rails to be everything. It’s just not great at some things. We’re willing to accept that.

- Rails handles our API, domain logic, and billing workflows.
- Go powers services that need high I/O concurrency or long-lived network connections.
- Rust handles CPU-bound jobs.

This approach keeps our core productive and lets us optimize the hot paths without attempting a painful rewrite.

Hiring isn’t a blocker

As a startup, we always need great talent. And young graduates don’t exactly leave school excited about Rails. So far, we’ve not had a problem with the talent pool.

That’s mainly because we’re not hiring hundreds of engineers and are extremely selective with new hires. There’s still a big amount of Ruby engineers, many of whom can run production at scale. So far, we haven’t run out of people to hire.

Would we choose Rails again in 2025?

Yes. A programming language isn’t a religion you follow. It’s a tool you use to help you ship a great product quickly. And that’s what it allows our team to do.

‍