Wait… You Chose Ruby?

In early 2020, the company I worked for as lead engineer, Notion (the IoT company, not the project management tool), was acquired by Comcast. At the time, we were a small but cohesive team of eight engineers. During early integration talks with Comcast’s technical leadership, I was repeatedly asked some version of the same question: “Why Ruby?”

The subtext was clear: Ruby didn’t have the best reputation in those circles. It was often written off as “old” or “slow” compared to newer, flashier languages. I didn’t share that hesitation, but the conversations made me more aware of the common criticisms and how valid (or not) they really are.

Since then, I’ve built up a set of experiences that make me confident in this: Ruby can be the perfect language for a startup or small business. And in this post, I’ll share why.

Consistency

How much time can an engineer spend on problems that have already been solved, or debugging issues caused by small inconsistencies in how things are built? The answer: a lot.

Convention over Configuration is a principle popularized by Ruby’s most well-known framework, Rails. It suggests that personal preferences should not outweigh the established norms of proven, working software. When embraced, it removes countless small, low-value decisions during development and promotes consistency across the entire codebase.

That consistency is an underrated superpower of a disciplined Ruby team. When adding a new feature, I can draw from a wealth of existing examples that follow the same patterns. When testing, I do not have to dig through unfamiliar code to understand what is being tested and why. Most importantly, when making changes, you only need to validate and update one familiar pattern. This greatly reduces implementation time and improves the overall quality of the software.

A former colleague and I often debated different technical approaches when facing new challenges. Most of the time, he would end with: “I don’t really care which direction we go, as long as we’re consistent.” Because once everyone is solving problems in an agreed-upon way, progress comes faster and with fewer surprises.

Readability

I firmly believe that the readability and maintainability of code are essential for keeping a project moving forward. Think of it like writing a book. You do not start writing without understanding the surrounding context. You read what came before, follow the flow of the story, and check if the point you want to make has already been made. If you make it harder to understand what is already written, you will inevitably slow down your ability to add new chapters.

Here is a quick example of summing the even numbers in a list:

Here it is in Ruby

def sum_of_evens(numbers)
  numbers.select(&:even?).sum
end

And in JavaScript

function sumOfEvens(numbers) {
  return numbers.filter((n) => n % 2 === 0).reduce((a, b) => a + b, 0);
}

You do not need to be a developer to see the difference in readability. In Ruby, it is often easier to quickly understand what a method is doing compared to many other languages. If you have ever seen an engineering team slow to a crawl over months of development, it is worth taking a hard look at how readable your codebase is.

For the developers in the room, brevity is not always the same as clarity. Shorter code does not automatically improve readability. However, in my experience, there is generally a strong correlation between the two.

Flexibility

One of the things I love most about Ruby is how adaptable it is. While building applications is the most common example, I have used Ruby in a wide variety of other situations.

• The business needs an email sent to a messy list of addresses that may or may not belong to registered users? Write a quick script.
• You want to develop a CLI tool to speed up and standardize how your team handles tasks like deploying to production or logging in to your preferred cloud provider? Simple.
• You want to create a Domain Specific Language that makes integrating with your product easier? Ruby is fantastic at metaprogramming.
• You found a bug deep inside Rails that is specific to your use case? Monkey patching is incredibly powerful (note: monkey patching should be used with extreme caution, please consult your doctor before performing surgery).

The point is this: you do not need multiple tools to tackle the wide variety of challenges a business will inevitably face when you are using Ruby.

But Isn't Ruby Slow?

The most common question about Ruby is usually some version of: “Isn’t Ruby slow?” The short answer is yes, but in a way that is irrelevant to your business. Ruby 3 brought welcome performance improvements over Ruby 2, yet it still lags behind some newer languages in raw speed.

For a startup, that difference rarely matters. Your bottleneck is not language performance, it is developer throughput. Who cares if a login page responds 100 milliseconds slower if your development team can build it in half a day instead of an entire sprint?

It is like comparing a supercar to a Hyundai Elantra for everyday use. The top speed might not be 180 miles per hour, but if it gets you to work reliably and on time, does it really matter?

Conclusion

Several months into our acquisition at Comcast, we held a round of technical deep dives with their engineering leadership. I presented our service-based architecture, how we integrated with our hardware, and how our data pipeline turned raw accelerometer data into an event that notified a user their front door had just opened.

When I finished with an overview of our team, that same technical leader was floored by how much we had built and maintained with only eight engineers. That reaction is exactly why Ruby remains at the top of my list for startups and small companies. The consistency it encourages, the readability that makes it a joy to work with, and the flexibility it is built for allowed our small team to deliver an outsized business impact.