Why Rails is a Great Choice for Startups in 2023
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
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
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.
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:
administrateto build an admin panel in no time.
devisehelps 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
- 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.