The Framework Nobody’s Excited About
Nobody tweets about choosing Rails anymore. No breathless blog posts. No conference keynotes announcing “we’re rewriting everything in Ruby.”
That’s the point.
Rails is the framework you pick when you’d rather ship features than debate architecture. And in B2B SaaS, shipping features is the whole game.
We’ve built SaaS platforms, internal tools, and client-facing applications on Rails for years. We’ve also worked with Node.js, Python, and Go. We keep coming back to Rails.
Not out of loyalty. Out of velocity.
This isn’t a love letter. It’s a practical argument for why convention-over-configuration still wins when you’re building software that needs to make money.
Shopify Settled This Debate Already
When people ask if Rails scales, the answer is a company processing $14.6 billion in merchant sales on a single Black Friday weekend. Shopify’s Rails monolith handled 489 million requests per minute at peak.
Their codebase: 2.8 million lines of Ruby, maintained by over 3,100 engineers.
That’s not a toy framework. That’s infrastructure powering a chunk of global commerce.
GitHub runs on Rails. So does Basecamp, HEY, and Stripe’s core billing systems. Over 667,000 companies use Rails globally.
The framework isn’t dying. It’s just boring. Boring is what you want underneath your revenue.
Lago, an open-source billing platform processing millions of API calls daily, wrote about this recently. Their take: “Scale is an architecture and operations problem, not a framework limit.”
They use Go for I/O-heavy services and Rust for CPU-intensive work, but the core product stays on Rails. That’s where their team ships fastest.
What Actually Matters for B2B SaaS
B2B SaaS is 90% CRUD. Users create records, update them, query lists, run reports. There’s a dashboard, roles, permissions, a billing integration.
A few webhooks if you’re fancy.
None of this is hard. All of it takes time.
Rails collapses that time. Active Record handles your data layer. Action Mailer sends transactional emails.
Active Job processes background work.
Devise manages auth. Pundit handles authorization. Stripe-rails wraps billing.
One developer on Rails can build what takes three in a typical TypeScript stack: separate API server, separate frontend app, separate worker process. Three deployment pipelines. Three sets of dependencies.
Sound exaggerated? We’ve seen it happen. A client came to us after spending four months building a Next.js frontend with a NestJS backend for what was essentially a multi-tenant invoicing tool. Four months, and they had user login plus a single form working.
We rebuilt the same scope in Rails in six weeks. Stripe billing, role-based access, tenant onboarding flow. All of it.
The difference wasn’t talent. Their team was sharp. The difference was the framework’s opinion about how applications should work.
Rails 8 Changed the Deployment Story
The biggest legitimate criticism of Rails was always deployment. Heroku made it easy but expensive. AWS made it powerful but complex.
Docker helped but still required orchestration knowledge.
Rails 8 fixed this with Kamal 2. One command: kamal setup. Point it at a fresh Linux server, and it handles Docker, SSL via Let’s Encrypt, zero-downtime deploys, and health checks. Your €20/month Hetzner VPS becomes a production environment in under two minutes.
That’s not a joke. HEY (37signals’ email product with hundreds of thousands of users) runs on this stack.
Rails 8 also shipped the Solid Trifecta. Three database-backed adapters that replace Redis entirely for most applications:
Solid Queue processes 20 million jobs per day at HEY. No Redis. No Sidekiq. Just your existing PostgreSQL database running your background jobs.
Solid Cache stores 10 terabytes of cached data at Basecamp. It cut their P95 render times in half. Again, no Redis required.
Solid Cable handles WebSocket connections through the database. Real-time features without adding another piece of infrastructure.
For a B2B SaaS startup, this means your entire application runs on a single server with a single database. Web server, background jobs, caching, WebSockets. All of it.
Your monthly infrastructure bill: roughly €40. Try that with a Next.js + Redis + BullMQ + separate WebSocket server setup.
Ruby Got Fast While Nobody Was Watching
Ruby used to be slow. That’s genuine history, not a myth. But it’s outdated history.
YJIT, Shopify’s just-in-time compiler that ships with Ruby, is now 92% faster than the standard interpreter on production benchmarks. Real-world Rails applications see 15-25% speed improvements with YJIT enabled.
CPU-intensive workloads gain over 40%.
Ruby 4.0 (released December 2025) went further. It introduced ZJIT, a next-generation compiler that already beats the interpreter. The Ruby core team has made performance a first-class priority, backed by Shopify’s engineering resources.
Is Ruby as fast as Go or Rust? No. It never will be. Does it matter for your B2B SaaS serving 500 concurrent users? Not even close. Your bottleneck is the database, not the language runtime. It always is.
When We Don’t Pick Rails
We’re opinionated, not religious. Rails isn’t the answer to everything.
If you’re building a real-time collaboration tool (think Figma or Miro), you need something that handles WebSocket connections at scale. Go or Elixir is a better fit for that specific layer.
If your application is primarily a single-page app with complex client-side state (drag-and-drop editors, canvas-based tools), React with a lightweight API backend makes more sense. Rails can be that API, but you’re not using most of what makes Rails productive.
If your team doesn’t know Ruby. This matters more than any technical argument. A Python team shipping Django will beat a team learning Rails every time.
The best framework is the one your people can think in.
If you need to hire 50 developers fast. The JavaScript talent pool is larger. Period.
For a startup hiring its first three or four engineers, this doesn’t matter. Rails developers exist in every major city. For a scale-up building a 50-person engineering org, it becomes a real constraint.
The “Back to Rails” Pattern
We’re not the only ones noticing this. Hardcover, a book-tracking platform, recently published a detailed account of migrating from Next.js back to Rails with Inertia.js.
Their reasons: unclear caching in Next.js, rising infrastructure costs, and slower development speed as the application grew.
They kept React for the frontend but moved the entire backend to Rails. Page load times improved. Google PageSpeed scores went up.
Development velocity increased.
This pattern is showing up everywhere. The pendulum swung hard toward JavaScript-everything around 2020. Now it’s swinging back.
Not because JavaScript is bad. Because many teams discovered they were paying a complexity tax that bought them nothing.
42% of organizations that adopted microservices are consolidating back toward simpler architectures. The industry is learning what Rails developers have known for 20 years: most applications are better as a well-structured monolith.
Our Stack, Specifically
For B2B SaaS projects, here’s what we typically deploy:
Ruby on Rails 8 with PostgreSQL. Hotwire (Turbo + Stimulus) for interactive UI without a separate frontend. Tailwind CSS for styling.
Solid Queue for background jobs. Kamal for deployment to Hetzner Cloud or your preferred EU data center.
Total infrastructure cost for an early-stage SaaS: €40-80/month. Time from project kickoff to working MVP: 6-10 weeks depending on scope.
When clients need a richer frontend (complex dashboards, heavy interactivity), we pair Rails as an API with React or Vue via Inertia.js. You get Rails’ backend productivity with a modern component-based frontend. No separate API layer. No CORS headaches. No duplicated routing.
The whole point is shipping your product, not building infrastructure. Rails lets a small team punch above its weight. For B2B SaaS, that’s the only metric that matters.
For a broader look at how we think about technology choices, read our tech stack decision framework. And if you’re weighing whether to build custom or buy off-the-shelf, our build vs. buy framework walks through the real math.
Building a B2B SaaS product and wondering which stack to choose? Let’s talk through it. We’ll look at your requirements, your team, and your timeline, and give you an honest recommendation.
