We still build with Ruby in 2025

Summary

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 speedNowadays, 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 f...