DEV Community

Cover image for Ruby on Rails is the world’s fastest web framework for startups
Kevin Gilpin
Kevin Gilpin

Posted on • Updated on

Ruby on Rails is the world’s fastest web framework for startups

I’m a 48 year old developer and entrepreneur. I’ve developed professionally in C++, Java, Python, C#, Ruby, Go, and JavaScript. My current startup and my previous one were both built on Rails. Here’s why.

As an entrepreneur, my definition of “speed” is “the amount of time and money it takes to reach an objective”. Code execution speed sometimes matters, because I want happy users. But once the app is fast enough, being faster doesn’t help much. Fast means “fast enough to get the job done”.

Built on Rails

Hiring for Rails

Once my company moves beyond the initial prototype, adding more developers is the primary way that we can accelerate the engineering team. Our ability to recruit and hire great developers is driven primarily by the talent pool and by the morale of our team. Talent pool is the first reason why your company can be extremely productive in Rails. The are a lot of developers out there who are skilled in it! And skilled developers who don’t have previous Rails (or Ruby) exposure, can pick it up quickly. The second factor in hiring a great team, morale, is driven in turn by two factors: company values (sometimes misnamed “culture”) and success. It’s often been noted that the company values are a reflection of values of the founding team. In my experience, this is true. “Success” is driven by the aforementioned “speed”. Success comes from quickly acquiring new users, making them happy with new features and bug fixes, supporting and them through problems. The more the team succeeds in doing this, the happier we are. And the happier we are, the easier it is for us to grow.

Coding for Rails

That covers the team aspect. Let’s switch gears and talk about the code base itself. I’m the CTO, so my world revolves primarily around the product code. I think it’s fair to say that successful startup code bases go through three phases:

  • Prototype (5,000 lines)
  • MVP (50,000 lines)
  • Maturity (500,000 lines)

Note that in each phase, 90% of the code is new. That means you can rewrite the entirety of what you already have (in a new language if need be) and only take 10% longer. Less, actually, because you’ve already done it once before. Rewrites are fun and easy! Too bad it doesn’t often make more business sense to do them…

When we start a company, our goal is to get to that 50,000 line MVP. To get there, we need to meet business objectives like acquiring and satisfying users, and growing the engineering team.

The job of the code base is primarily to glue other frameworks, libraries and services together. We don’t have time to do anything else! Rails (and some non-Rails Ruby) is a great platform for building that glue. It doesn’t really have to do very much work. The work should be happening elsewhere; in the database, on the frontend (where compute power is free!), in native code like JSON libraries and database drivers.

So, back to speed. The job of the programming language and framework is to turn your team’s ideas into an MVP as fast as possible. Ben Halpern, founder of, puts it perfectly in his blog post “I’m Ben and I am a Rails developer”:

I recall a blog post about a new company that had some 
non-technical momentum which was completely derailed by 
taking a simple idea and writing it in Go microservices.
I cannot remember where I found the post, but the story
was telling. They scratched their work and took a week
or two with Rails to make up for months of lost 
productivity overthinking the problem.
Enter fullscreen mode Exit fullscreen mode

So keep in mind: to a developer, speed means “performance on benchmarks”. The Ruby 3x3 benchmark and all the debate around it has once again brought out the Ruby critics who are reminding us all again how “slow” Rails is. To me, speed means productivity. Speed means telling my CEO and our investors that we are on track with the product milestones, and on-track with user adoption targets. Sometimes, there is legitimate performance showstopper in the app; a slow query, or a scaling issue with large data files. When that happens, a good engineer digs into the problem for a couple of days, solves it, and we move on. In Rails!

Key takeaways

In summary, as a startup CTO, my job is to coax the most “business speed” out of the dev organization as I can. Rails gives me speed, because:

  • There is a lot of great talent available.
  • Ruby is optimized for developer happiness, and happy teams are better teams.
  • Rails is productive, and the second version of any Rails app is going to be faster and better than the first version of the same app written in any other language.
  • The job of a framework, like Rails, is to glue other tools together. 80% of the program execution time should be spent outside of Rails (say, in the database). So making the web framework 2x faster only makes the app 10% faster. Optimize elsewhere.

That's why I build on Ruby on Rails.

  • kevin

While you're here

We are conducting a survey: State of Software Architecture Quality. We are aiming for 300 responses, and once we meet our goal we will be donating $1,000 to Girls Who Code. Please contribute to our understanding of software architecture quality by filling out the survey! Of course, we will be summarizing and publishing the results once they are available.

If you don't want to fill out the survey, but you want to be notified when the results are available, you can fill out this form:


I suppose I am trolling a bit by calling Rails the “world’s fastest web framework”. This is prompted by two things. (1) The kerfuffle over the Ruby 3x3 objective. (2) The degree to which developers will under-value their own time. As rhymes puts it:

the old saying “premature optimization is the root of all evil”
applies also to technological choices.
Enter fullscreen mode Exit fullscreen mode

Top comments (30)

abhinaykumar profile image
Abhinay Kumar

Do you ever reflect on your negative comments? Someone is taking an effort to make us understand that productivity is the kind of speed that devs should care about period.

andevr profile image

I find it particularly interesting that the critics of rails leave off basecamp, hey, and many other big pieces of software that are powered by ruby and are doing just fine. Granted I don't know how large their user base is, but I do recall seeing DHH tweet about rails being able to at least power a $100m company(basecamp) and now an email service. Im guessing rails is plenty fast enough for those.

Thanks for a great article. I'm new to rails (a couple of months in) and I'm enjoying every minute of it.

brodock profile image
Gabriel Mazetto • Edited

The "machine" cost is no where near the "human cost". Unless you have a very specific case (to which you should optimize), there is no need to rewrite anything in X. Hiring additional people that knows X will eclipse whatever you are going to save by using fewer machines.

At the end of the day, the bigger bottlenecks are Databases and disk I/O.

ronald_arias profile image

Uhmm my understanding of the article is that you use Rails to get you started, but then you optimise.
I've taken that path myself, started with Rails and as demand grew we slowly spread into microservices across different languages. Twitter, Github, etc all did that.

Nobody is saying you stick with Rails forever. Some companies maybe don't even make it that far to reach performance issues that require badass infrastructures.

bizzibody profile image
Ian bradbury

@ron - I think GitHub is ROR.

Thread Thread
ronald_arias profile image

The GitHub site is still RoR but many of the services behind are not anymore. That's the sort of hybrid approach I'm taking about

haruanm profile image
Haruan Justino

Those are almost the same reasons that I use Django with Python, I will save the article to read again in the future, quite nice things to remember.

techbelle profile image
rachelle palmer • Edited

There's also just the bitter reality that most of us will never build a site that has the volume of traffic and users of Github, Airbnb, etc (who, incidentally do use Ruby). So the point about performance is probably not relevant for the majority or even almost all developers who build ruby apps in the first place.
What I see happening typically is that when the Ruby application does hit that magical hypergrowth period, developers/the company has a lot of pain, and then rewrite some of the application in Go. Not all of it, not half of it, not even 10% of it, just the parts that need to be super performant.
That doesn't negate all the benefits that using Ruby provides, imo.

tomavelev profile image
Toma • Edited

The speed of coding/bug fixing depends on the skills, experience with the programming tools - of the coders /and their attachment to technical perfection from machine viewpoint/. Besides that note, I totally agree with you. Speed of development is more valuable than of execution.

kgilpin profile image
Kevin Gilpin

When you achieve MVP you don’t get paid. You get to borrow more money (from VCs usually), which you can use to try and scale up your embryonic company. Meanwhile everyone is trying to kill you.

bizzibody profile image
Ian bradbury

Where did 100 come from?

Thread Thread
peerreynders profile image
peerreynders • Edited

Benefits of Elixir: How Elixir helped Bleacher Report handle 8x more traffic:

"On our monolith we needed roughly 150 [Rails] servers to power the more intensive portions of BR. Following our move to Elixir we're now able to power those same functions on five servers and we're probably overprovisioned. We could probably get away with it on two," Marks says.

Then again Phoenix/Elixir/Erlang are a special kind of beast.

That's 'Billion' with a 'B': Scaling to the Next Level at WhatsApp
Why We Chose Erlang over Java, Scala, Go, C

Which companies are using Erlang, and why?:

Once upon a time, Cisco, Ericsson, Klarna, Goldman Sachs, T-Mobile, WhatsApp, Amazon and many other top companies kept a secret. Erlang was that badly kept secret.

Robert Virding:

Well then, just more cases where it's in wide use but you don't see it or know about it. It's really great it's being used but a bit depressing that no one knows about it as you continually hear "what's Erlang, why should I learn/use it as no one uses it?"

Second-Order Effects: Energy Hogs: Can World’s Huge Data Centers Be Made More Efficient?

chazelton331 profile image
Cliff Hazelton

Curious about this - how often is language the bottleneck (and the cost driver) vs. database and just a poorly optimized codebase (N+1 queries, bad SQL, etc.)? What have you measured?

ecguo profile image

I can programming C# and Ruby, I think I wouldn't consider C# jobs even a little bit higher paid. Using Rails is really peasure.

azuaraj profile image
Antonio Azuara

I think Ruby and Ruby On Rails should be compared against low code or no code solutions (because the amount of abstraction that it's there) not against super scalable functional programming languages like Elixir. And speaking about the resource hungriness of Ruby, when your product reaches market and hopefully financial success the costs of the cloud bill won't be a problem.

defman profile image
Sergey Kislyakov

@ben , could you provide some light on that point? uses Ruby and I think it's a pretty high-loaded website.

kitsunde profile image
Kit Sunde

It's possible to be incompetent in any language. English for instance.

andyobtiva profile image
Andy Maleh

Brilliant article! Thanks!


sujitmohanty profile image
Sujit Mohanty • Edited

Great article! Thank you!