I’m going to say something that might get me in trouble with the Ruby purists. The framework you choose for your next project probably doesn’t matter. There. I said it.
For years, I’ve seen developers and founders agonize over this decision. Should we use Rails? What about Hanami? Or maybe that new, super-fast framework that just came out last week? We spend weeks, sometimes months, creating benchmarks, comparing features, and reading every article we can find. I’ve done it myself. And you know what I’ve learned after two exits and investing in over 200 companies? It’s mostly a waste of time.
The Framework Trap
We’ve all been there. You’re starting a new project, and the first thing you do is open up a dozen tabs to compare every framework under the sun. You look at request-per-second benchmarks, memory usage, and which one has the most elegant syntax. You read think-pieces about why monoliths are dead and why microservices are the future. Or is it the other way around this week? It’s easy to get caught up in the hype. I get it. We’re engineers. We love to optimize. But here’s the thing: for a startup, optimizing for the “perfect” framework is often a form of premature optimization. You’re focusing on a problem you don’t have yet.
When I was building RemoteTeam, we used Rails. Was it the “best” framework out there? I have no idea. But it was the framework my team and I knew inside and out. We could build and ship features at a ridiculous pace. And that’s what mattered. We weren’t worried about whether we could handle a million concurrent users. We were worried about getting our first ten customers. And then our first hundred. By the time we were acquired by Gusto, we had a successful product and a happy team. The framework we used was a footnote, not the headline.
What Actually Matters
So if the framework doesn’t matter, what does? I’m glad you asked. Here’s what I’ve seen make or break companies, both as a founder and as an investor in companies like Anthropic and Scale AI.
Speed of iteration. Can you get an idea from your head to a deployed feature in a matter of hours? Can you A/B test a new feature and get feedback from real users before your competition even finishes their sprint planning? This is where the rubber meets the road. The faster you can learn, the faster you can build something people actually want. And that’s the whole game.
Team expertise. Do you have a team of developers who are experts in a particular framework? If so, that’s your secret weapon. Don’t throw that away to chase the latest trend. A team of experienced Rails developers will build a better product faster than a team of novices learning a new framework, no matter how “good” that new framework is. I’ve seen this play out time and time again. A-plus developers with a B-minus framework will always beat B-minus developers with an A-plus framework.
Ecosystem and community. How big is the community around the framework? Are there a ton of libraries and tools available? Can you find answers to your questions on Stack Overflow? When you’re a small startup, you don’t have time to reinvent the wheel. You need to be able to stand on the shoulders of giants. A mature ecosystem is a massive advantage. This is one of the reasons why Rails has been so successful for so long. The community is huge, and there’s a gem for just about everything.
When the Framework Does Matter
Now, am I saying that the framework never matters? Of course not. There are certain situations where the choice of framework can have a significant impact. If you’re building a real-time, high-frequency trading platform, you’re probably not going to use Rails. If you’re building a machine learning-heavy application, you might want to look at something like Python with Django or Flask. The key is to understand the specific constraints of your problem domain.
But for the vast majority of web applications, the framework is not the bottleneck. The bottleneck is your ability to understand your customers and build a product that solves their problems. I’ve seen companies with beautiful, elegant codebases fail because they built something nobody wanted. And I’ve seen companies with messy, legacy codebases succeed because they were relentless in their pursuit of product-market fit.
My Advice to Founders
So, what’s my advice to founders who are in the early stages of building a company? Stop worrying about the framework. Pick one that your team knows well, or one that has a large and active community. And then get to work. Build something. Ship it. Get feedback. Repeat. The faster you can get through this loop, the higher your chances of success.
And for the love of all that is holy, don’t write your own framework. I’ve seen this happen a few times, and it’s almost always a disaster. You’re a startup. You don’t have the time or resources to build and maintain a framework. Use something that’s already out there and has been battle-tested by thousands of other companies.
At the end of the day, your customers don’t care what framework you’re using. They care about whether your product solves their problem. So focus on that. The rest is just noise.
A Tale of Two Startups: The MovieLaLa Story
Let me tell you a story. Back when we were building MovieLaLa, we were obsessed with speed. Not just performance speed, but the speed of shipping. We were a small team, and we were competing with giants. We knew we couldn't out-spend them, so we had to out-think and out-hustle them. Our weapon of choice? A simple, straightforward Rails stack.
I remember one particular week. We had a crazy idea for a new feature that would let users create and share movie-themed quizzes. It was a big bet. It would require a lot of new code, and we had no idea if users would even like it. A more “careful” team might have spent a month debating the idea, another month speccing it out, and a third month building it. We built it in a week.
Was the code perfect? Absolutely not. It was messy. It was full of hacks. But it worked. And we shipped it. The response was incredible. Users loved it. It became one of our most popular features and a huge driver of growth. We would have never gotten there if we had been stuck in framework analysis paralysis. We won because we were fast. We won because we focused on shipping, not on having the most pristine codebase.
Contrast that with a startup I advised a few years ago. They were a brilliant team, some of the smartest engineers I’ve ever met. They were building a new social network, and they were determined to build it on the “perfect” stack. They spent six months debating the merits of different frameworks, different databases, and different architectural patterns. They wrote a beautiful, elegant, and scalable system. But by the time they launched, the market had moved on. A competitor had launched a similar product six months earlier and had already captured the market. The brilliant team with the perfect stack went out of business.
The Siren Song of the New and Shiny
I see it all the time. A new framework comes out, and it’s all anyone can talk about on Hacker News. It’s 10x faster! It’s written in a cool new language! It has a revolutionary new feature that will change everything! It’s tempting, I know. As engineers, we’re drawn to the new and shiny. We want to be on the cutting edge. We want to be using the best tools for the job.
But here’s the problem: the new and shiny often comes with a hidden cost. The documentation is sparse. The community is small. There are no libraries or tools to help you. You’re on your own. And when you’re a startup, that’s a very dangerous place to be.
I once invested in a company that fell into this trap. They were building a new e-commerce platform, and they decided to build it on a brand-new, unproven framework. They were convinced that the performance benefits would give them a competitive advantage. They were wrong. They spent the next year fighting with the framework. They had to write their own libraries for everything, from authentication to payment processing. They spent more time debugging the framework than they did building their product. By the time they finally launched, they had burned through most of their funding and had a product that was buggy and unstable. They eventually had to pivot and rebuild their entire platform on a more mature and stable framework. It was a painful and expensive lesson.
Don’t be that company. Don’t let the siren song of the new and shiny lure you onto the rocks. Stick with what’s tried and true. Stick with what has a large and active community. Stick with what will help you ship your product faster. Your startup depends on it.
Conclusion: It's About the People, Not the Code
If there’s one thing I want you to take away from this article, it’s this: startups are about people, not code. They’re about understanding your customers and building something that they love. They’re about building a team that can execute and iterate quickly. The framework you choose is a tool to help you do that, but it’s not the most important tool in your toolbox. Not by a long shot.
So the next time you’re starting a new project, I want you to do something different. Instead of spending weeks agonizing over which framework to use, I want you to spend that time talking to your customers. I want you to build a prototype, get it in front of users, and get their feedback. I want you to focus on what really matters. Because that’s how you build a successful company. And that’s the counterintuitive truth about choosing a Ruby on Rails framework.
Frequently Asked Questions
Which option is best for startups?
It depends on your stage, budget, and specific needs. Early-stage startups should prioritize flexibility and low cost. Growth-stage companies can afford to optimize for performance and scalability. There's no universal answer.
Can I switch later if I make the wrong choice?
In most cases, yes. The switching cost is usually lower than people fear. The bigger risk is analysis paralysis, spending months evaluating options instead of picking one and learning from real usage.
What factors matter most in this comparison?
For most founders, the three factors that matter most are: total cost of ownership, ease of implementation, and how well it integrates with your existing workflow. Features are important but often overweighted in decision-making.
How often should I re-evaluate this decision?
I recommend revisiting major tool and strategy decisions every 6-12 months. The landscape changes fast, and what was the best choice a year ago might not be today. But don't switch for the sake of switching.