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.

Ruby on Rails has been in continuous development since 2004. The early days of looking for its identity, structure, and mission are long gone. The framework has become a mature and stable foundation for building businesses upon. This has tremendous implications for the available talent pool and the ecosystem of additional tools. Let’s start by looking at the talent pool.

Senior Talent Pool

Rails’ long history results in a large number of senior engineers available on the market. I’d say that the average Rails engineer is more experienced than the average Python or JavaScript engineer. Paradoxically, this means there’s less fresh blood flowing into the Rails ecosystem. This is concerning ecosystem-wise, but 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, or distribution channels. Over-reliance on juniors can become another existential threat in that risky endeavor, so startups should naturally prefer seniors as 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 build something much better than competition.

Attracting, retaining, and growing Rails developers is a topic for another article. Let’s turn our attention to technical matters.

Extensive Ecosystem of Tools

With almost half a billion downloads, Rails has become a dominant force in the Ruby world. That dominance incentivizes Ruby developers to integrate their tools with Rails out of the box, or at least to make it simple. The result is a rich ecosystem of Rails add-ons for handling a wide array of concerns, from building admin panels to ensuring database performance.

There are thousands of tools out there, but let me mention a few I like:

• Use administrate for building admin panels 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).
• A great UI development environment called Lookbook.
• ViewComponents, a framework for component-based UI development.
• Alternatives to HTML/ERB like Phlex, Haml, or Slim.
• Security tooling like rack-attack or bundler-audit.
• Backend niceties in the form of Pagy, AASM or sidekiq.

Long history is not all, though. There are other reasons for the framework’s success that are relevant for startup work.

Focus on the Product, not Technical Minutia

Software development is a constant stream of decisions: decomposing problems into subproblems; naming variables, functions, and classes; deciding on API inputs and outputs; picking libraries to use. These decisions are critical to product quality, but have little direct impact on customers. Sadly, engineers could spend countless hours debating whether configuration should be put under cfg or config, which distracts them from making actual product progress. The Rails Doctrine addresses that problem at a high- and low-level.

At a high level, all Rails apps are assembled from a well-defined choice of components for tackling common web development problems: accessing the database, processing background tasks, handling email, file uploads, and others. This is one of the Rails Doctrine principles in action: the menu is omakase.

Assembling large building blocks is not enough, though. You also need to structure the code within them. This is where another principle from the Rails Doctrine enters the scene: Convention over Configuration. It’s a low-level counterpart of the previous principle, and it means offering sensible default across the entire code base.

Taken together, these principles mean that engineers are freed from making those decisions themselves, and can almost immediately start building customer facing features. Additionally, hte resulting consistency across apps makes it easier to onboard new Rails engineers, as they can skip learning how various pieces fit together and go straight to learning the product itself.

Architecture Appropriate for Startups

Among the choices made by Rails one is the most contrarian, and thus can become your startup’s secret weapon: Hotwire. React, Vue, and Angular are almost always used within the single-page app architecture, which kills productivity big way. What’s worse, it’s often paired with replacing one full-stack developer with a frontend and a backend developer, which introduces communication and coordination barriers that further slow things down.

The Rails way is much simpler in comparison: server-side rendering paired with Hotwire allows engineers to focus on HTML and CSS with a minimal amount of JavaScript. Turbo 8 offers an amazingly simple solution for interactivity, and more sophisticated real-time and interactive parts can be built using Stimulus, Turbo Streams, and Action Cable.

If you really need to use React or Vue then it can be limited to a few specific pages. Reasoning along the lines of “The map component would the benefit from React, so let’s use it for everything, including Sign Up, Sign In, About, etc.” is something best left for your competitors.

Rails Rhymes with PaaS

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

No Silver Bullet

I’m writing an honest assessment, so must mention when Rails is a bad fit. 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 may lack specialized libraries required by your product. For example, it’s difficult to beat Python in number crunching, as there’s no Ruby counterpart for NumPy, SymPy or Jax. In those cases, Python may be a better option.

Second, certain usage patterns may be handled better by other technologies. A group chat is a perfect example: many-to-many communication sending little data in a single interaction. 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, or revert to native development, and rely less on the Rails way in general.

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 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.