Why we still build with Ruby in 2026 - Lago Blog

## The boring superpower: shipping speed ... 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: … ## 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.