Why Rails is a Great Choice for Startups in 2023

JavaScript is in the vogue now, but Ruby on Rails can easily become your startup’s secret competitive advantage.

The tech industry is a fashion contest in disguise, and it must be admitted that Ruby on Rails used to be the industry’s sweetheart. Things have changed with JavaScript and React in the spotlight now, but Ruby is still in the game, more stable and mature than ever.

In this article we’ll look at several reasons that make Ruby on Rails a great choice for early-stage start ups. Let’s have a look at the talent pool, and then focus on the framework’s technical merits.

Senior Talent Pool

Most Rails engineers on the market are senior compared to popular technologies like Python or JavaScript. In other words, there’s less fresh blood flowing into the Rails ecosystem. This is concerning ecosystem-wise, but paradoxically can be a great advantage for an early-stage startup that knows how to capitalize on it.

The biggest risk for a startup is failure due to lack of a feasible product, business model, distribution channels, and so on. Over-reliance on juniors can become another existential threat in an already risky endeavor, so startups should naturally prefer seniors as their first hires. That makes the Rails talent pool more suitable for startups, as less filtering is needed. Additionally, many present contrarian attitudes, which may be helpful if you’re aiming to disrupt an industry or just build something much better than competition.

Attracting, retaining, and growing Rails developers is a topic for another article, so let’s have a look at technical merits behind the framework.

Focus on the Product, not Technical Minutia

Software development is a constant stream of micro-decisions like naming, splitting and grouping things together, TODO and torturing HTML and CSS to achieve the desired effect. These are important from delete word

They are important from the engineering perspective, as consistency improves code understandability, but have little direct customer impact. Some engineers may find it hard to believe, but customers really don’t care whether configuration is put in cfg, config or configuration.

One of the conceptual pillars of Ruby on Rails is Convention over Configuration.

Regrettably, engineers can spend unreasonable amount of time debating technical minutia. This is where Rails enters the scene – by making hundreds of such small decisions for you, it enables your engineers to focus on core product features. From my experience, one of these choices turns out to be much more important than others and deserves a section of its own.

Architecture Appropriate for Startups

The single-page app architecture, almost always used with React, Angular, and Vue, kills productivity big way. What’s worse, it’s often paired with replacing one full-stack developer with two part-stack developers (i.e. backend and frontend), which further decreases productivity by introducing a communication and coordination barriers.

The Rails way is much simpler in comparison: server-side rendering and Hotwire allow engineers to focus on HTML and CSS (strictly required to make things appear in the browser), while minimizing the amount of explicitly-managed client side-state and JavaScript code.

Extensive Ecosystem Centered on Rails

Rails is a dominant force in the Ruby ecosystem with almost half billion downloads. This fact drives other projects to support Rails out-of-the-box, which means it’s easier to integrate multiple tools, allowing your engineers to focus on the product, instead of stitching libraries together.

There are thousands of tools out there, but let me mention a few of my personal favorites:

  • Use administrate to build an admin panel in no time.
  • devise helps to add all sorts of authentication features like password resets, account locks, OAuth (for “Sign in with Google” and the like).
  • ViewComponents, a framework for component-based UI development.
  • Alternatives to HTML/ERB like Phlex, Haml, or Slim.
  • A great UI development environment called Lookbook.
  • Security tooling like rack-attack or bundler-audit.
  • Backend niceties in the form of Pagy, AASM or sidekiq.

Rails is great, but it’s not everything! The app needs to be hosted somewhere. I do have some recommendations that should result in productivity bliss.

Rails Rhymes with PaaS

Infrastructure can become another engineering time sink that contributes very little to startup success. Rails is less prescriptive here, but my recommendation is to delegate as much infrastructure choices to a PaaS as possible. There are many options out there, including Heroku, Fly, Render, and North Flank.

No Silver Bullet

I intend to write an honest assessment, so cases where Rails is a bad fit must be discussed, too. Naturally, we’re talking about building web and mobile products. You obviously won’t deploy Rails to a toaster (that’s what NetBSD is for).

First, Ruby (and thus Rails) may be a bad choice if you need access to specialized libraries. For example, it’s difficult to match Python’s offering of maths and statistics libraries: NumPy, SymPy, Jax, and others. In those cases, Python may be a better option (but keep reading!).

Second, some applications have unusual usage patterns. A group chat is a perfect example: many-to-many communication system sending relatively little data in a single interaction. Something like Erlang or Elixir may be a better choice here.

Lastly, Rails can drive a mobile app built with Turbo Native, but not all apps fit within the constraints established by that architecture. In those cases, you may need to use React, React Native, revert to native development and rely less on the Rails way in general.

Things are even more complicated than that, as you may be able to circumvent some of the limitations above with appropriate architectural choices (e.g. using service-oriented architecture), but that’s a topic for another article.

End Result: Insane Productivity

The technical points above share a clear pattern: delegating ancillary choices to Rails (paired with a PaaS) enables your engineering team to focus on driving the product forward. In other words, you focus on essential complexity and delegate incidental complexity to the framework.

The end result is that a single engineer, or a small team of engineers is capable of achieving insane levels of productivity. You’re likely end up hiring less engineers (albeit for higher rates), come ahead financially and build a better product.

If you liked the article and would like to get early-access to other deep-dive articles covering Ruby, Rails, and PostgreSQL then leave your email below.

Leave your email to receive updates about articles.