Backend
Ruby on Rails
The original convention-over-configuration framework, in the hands of engineers who ship MVPs fast and then run them for years.
Overview
Ruby on Rails is the full-stack web framework that made convention over configuration a mainstream idea. Instead of asking you to wire together a router, an ORM, a template engine, a background-job system and a test harness by hand, Rails ships all of them, already agreeing with each other, behind a set of sensible defaults. Follow the conventions — name a class Order and its table orders, put controllers where controllers go — and an enormous amount of code you would otherwise write simply disappears. That is the whole bargain: you give up some freedom to arrange things your own way, and in return you move faster than almost any other stack from empty repository to working product.
At the centre sits ActiveRecord, the ORM that maps your database tables to Ruby objects and gives you migrations to evolve the schema in version-controlled steps. Around it are the pieces that make Rails a complete toolkit rather than a library: ActionCable for WebSockets, ActiveJob for background work, ActionMailer for email, and scaffolding and generators that stamp out the repetitive boilerplate of a new resource in one command. The framework’s guiding philosophy — the "majestic monolith" — is that for most products a single, well-organised codebase beats a constellation of microservices, and that a small senior team is more productive keeping one thing coherent than maintaining ten things that must agree over the network.
We reach for Rails when time-to-first-real-feature matters and the domain is a fairly ordinary web application: users, records, forms, workflows, money, email. That covers most software a business actually needs. We use Hotwire and Turbo to add real interactivity — live updates, partial page changes, modal flows — without dragging in a heavy single-page-app front end, so the server stays the source of truth and the JavaScript stays thin. This page is about the framework; if you want the language underneath it, see our Ruby page. What follows is where Rails is the right call, where it is not, and how we build with it so it lasts.
Best for — Database-backed web products — startups, MVPs and SaaS — where getting a real, maintainable application in front of users quickly matters more than squeezing out the last microsecond per request.
Why teams choose Ruby on Rails
Unmatched time to market
Convention over configuration, generators and ActiveRecord mean a working, deployable feature exists in days, not weeks. For an MVP that is the whole point: you spend your money proving the product, not building the plumbing every web app needs.
One codebase, one mental model
The majestic monolith keeps routing, data, jobs and views in a single, consistent project. New engineers find their way around fast because Rails apps are laid out the same way, and there is no network boundary between parts of your own system to debug.
Interactivity without an SPA
Hotwire and Turbo deliver live updates and dynamic pages from server-rendered HTML, so you get an app that feels modern without the cost of building and maintaining a separate React or Vue front end and the API tier it demands.
Why businesses choose Ruby on Rails
- You need to be in front of users fast, and you would rather spend your budget on product than on assembling infrastructure that Rails already provides.
- Your product is a database-backed application — the kind of software Rails’ conventions were built for — rather than a real-time or compute-heavy edge case.
- You want a single coherent system a small senior team can own, not a microservice estate that adds operational cost before you have the scale to justify it.
- You value a framework with fifteen years of hard-won conventions and a deep body of proven patterns over the churn of assembling this year’s favoured libraries.
What we build with Ruby on Rails
The capabilities this technology is genuinely strong at — and what we most often build with it.
ActiveRecord & migrations
The ORM maps tables to Ruby objects with readable associations and queries, and migrations evolve the schema in version-controlled, reversible steps. We keep migrations safe on live data and resist the temptation to hide business logic inside model callbacks where it becomes impossible to test in isolation.
Generators & scaffolding
Rails generators stamp out models, controllers, migrations and tests from one command, so a new resource is wired up in seconds. We use them to start fast, then prune the scaffold down to what the feature actually needs rather than leaving generated cruft behind.
Hotwire, Turbo & Stimulus
Turbo swaps page fragments and streams live updates over the wire from server-rendered HTML; Stimulus adds small, targeted sprinkles of JavaScript. Together they deliver an interactive product without a separate SPA front end — the server stays the single source of truth.
ActiveJob & background processing
Slow work — email, exports, third-party calls, scheduled tasks — moves off the request into background jobs, backed by Sidekiq on Redis or Rails’ own Solid Queue. We keep jobs idempotent and observable so a retry never corrupts data or silently drops work.
ActionCable & real-time
ActionCable provides WebSockets integrated with the rest of the framework, so notifications, live dashboards and presence work without a bolt-on service. We are honest about its limits and reach for a dedicated tool when the concurrency genuinely outgrows what a Rails process should carry.
The full toolkit
ActionMailer for email, ActionText for rich content, ActiveStorage for file uploads, fragment and Russian-doll caching, and a first-class testing stack — Minitest or RSpec — all ship together and are designed to work as one. Less glue to write, less to keep in sync.
Use cases
Startup MVPs
Getting a real, credible product in front of users and investors quickly, on a codebase that will not have to be thrown away when the idea proves out — Rails’ core strength since its inception.
SaaS applications
Multi-tenant subscription products with accounts, billing, roles and dashboards. Rails handles the recurring shape of SaaS — users, records, workflows, money — with conventions rather than bespoke architecture.
Marketplaces & platforms
Two-sided marketplaces and internal platforms where listings, transactions, messaging and admin all live in one domain model that ActiveRecord expresses cleanly.
Internal tools & admin systems
Operational back-office software — inventory, CRM, reporting, approval workflows — where development speed and maintainability matter far more than raw throughput.
When Ruby on Rails is the right choice
- Right for a startup or MVP that needs to reach the market quickly. Rails’ golden path — generators, ActiveRecord, batteries-included defaults — gives you a working, deployable product in a fraction of the time a hand-assembled stack takes, and that head start is often the difference between validating an idea and running out of runway.
- Right for a database-backed business application: CRM, marketplace, booking system, internal admin, SaaS product. When the work is modelling a domain and putting forms, workflows and reports over it, Rails’ conventions were designed for exactly this shape of problem.
- Right when you want one coherent codebase a small senior team can own end to end. The majestic monolith keeps the whole system in one place, one deployment, one mental model — far cheaper to reason about than premature microservices.
- Wrong for hard real-time or CPU-bound work — high-frequency trading, video transcoding, physics simulation, low-latency game servers. Ruby is interpreted and per-request throughput trails compiled languages; for those workloads a compiled stack or a purpose-built service is the honest answer.
- Wrong when your team is already standardised on another ecosystem and has no Ruby experience. Rails’ productivity comes from fluency in its conventions; dropping it into a .NET or Go shop with nobody who knows it trades a real learning cost for a benefit that team may never fully realise.
Ruby on Rails: pros and cons
Strengths
- Fastest mainstream path from idea to working product — the golden path removes most of the boilerplate every web application otherwise needs.
- ActiveRecord and migrations make data modelling and schema change genuinely pleasant, with version-controlled, reversible steps and readable queries.
- A mature, complete toolkit: background jobs, WebSockets, mailers, caching, testing and Hotwire all ship together and are designed to cooperate.
- The monolith is cheap to reason about — one deployment, one codebase, no distributed-systems tax until you have actually earned the need for it.
Trade-offs
- Per-request performance trails compiled stacks. Ruby is interpreted, and while this rarely matters for typical web workloads, it is a real ceiling for CPU-bound or latency-critical paths.
- The "magic" cuts both ways: conventions and metaprogramming that make experts fast can obscure what is actually happening from newcomers, who must learn the framework before the code reads as obvious.
- The monolith needs discipline. Without deliberate boundaries — service objects, well-drawn models, restraint on callbacks — a large Rails app can grow fat controllers and tangled models that slow every future change.
- A smaller talent pool than the JavaScript world. Good Rails engineers exist and are productive, but there are fewer of them than React developers, which is a real hiring consideration.
The majestic monolith
A Rails application is a single, conventionally structured codebase: models that own the domain and the database, controllers that handle requests, views that render HTML, jobs that do slow work in the background, and mailers that send email — all in one deployable unit. This is the majestic monolith, and for most products it is the right architecture, not a compromise. One codebase means one mental model, one deployment pipeline and no network boundaries inside your own system to trace when something breaks. The distributed-systems tax — service discovery, eventual consistency, cross-service debugging — is real, and a monolith lets you defer it until you have actually earned the need.
Keeping a monolith healthy at size is a matter of discipline, not luck. We draw clear boundaries with service objects and query objects, keep controllers thin and models focused, and use callbacks sparingly because they are the usual route to a model nobody can reason about. Where a genuinely separable concern emerges — a heavy reporting pipeline, an isolated integration — we extract it deliberately rather than by reflex. The goal is a codebase where a new senior engineer is productive in days because it looks like every other well-kept Rails app, not one that has drifted into a private dialect only its authors understand.
Performance
Let us be blunt about the ceiling and then about the reality. Per request, Ruby is slower than a compiled language — that is a fact, and for CPU-bound work it matters. But for the overwhelming majority of web applications, the request time is dominated not by Ruby but by the database. A page that feels slow is almost always waiting on an N+1 query, a missing index or an unbounded result set, not on the interpreter. We profile with tools like rack-mini-profiler and Bullet, fix the query layer first with eager loading and proper indexes, and only then look at the Ruby.
From there the standard levers apply and they work well: fragment and Russian-doll caching so expensive views are computed once, a Redis cache for hot data, background jobs so nothing slow blocks a response, and HTTP caching at the edge. Modern Ruby has also closed part of the gap — YJIT gives a real throughput improvement for free on recent versions. The honest summary is that Rails is fast enough for nearly everything a business builds, and where it is not, the fix is usually architectural rather than a change of framework.
Security
Rails has one of the better security defaults of any web framework, precisely because it makes the safe path the conventional one. ActiveRecord parameterises queries, so SQL injection is avoided unless you deliberately drop to raw SQL. The view layer escapes output by default, blunting cross-site scripting. CSRF protection is on out of the box, and strong parameters force you to whitelist which attributes a request may set, closing the mass-assignment hole that once bit the framework publicly. Encrypted credentials keep secrets out of the codebase. These are defaults, not features you have to remember to switch on.
Defaults are a floor, not a ceiling, and we treat them as such. We enforce authorisation on the server for every action rather than trusting a hidden button, keep the dependency tree current and audited with bundler-audit and Brakeman on every build, and are careful with the escape hatches — raw SQL, html_safe, and skip_before_action — that quietly bypass the framework’s protections. Authentication, session handling and secure cookies are deliberate decisions, and we review them as such rather than inheriting whatever a starter template happened to set.
Scalability
The claim that "Rails doesn’t scale" is folklore, and the counter-examples are enormous. GitHub, Shopify, Basecamp and countless others run Rails at a scale most products will never approach; Shopify in particular serves some of the largest traffic spikes on the internet on a Rails monolith. What is true is more precise: Rails scales with engineering effort, and the constraint you hit first is almost always the database, not the framework. A stateless Rails app scales horizontally by adding processes behind a load balancer without drama — the hard part is the data layer underneath it.
So we plan for scale where it actually lives. Read replicas and connection pooling for read-heavy load, careful indexing and query design, caching layers in Redis to keep the database off the critical path, and background jobs to absorb spikes rather than blocking requests. When a single database genuinely becomes the limit, sharding and partitioning are proven paths — Shopify’s pod architecture is the well-documented case study. The framework will carry you a very long way; the engineering discipline you apply to the data tier is what determines how far.
Ruby on Rails integrations & ecosystem
The technologies we most often pair with it — each links to how we work with it.
How we build with Rails
We start on the golden path and stay there as long as it serves us. That means leaning on generators, ActiveRecord and Rails’ conventions to get a real, deployable slice of the product working within the first week, then iterating in thin vertical features that each ship to production. The framework’s speed is only worth having if you actually spend it on the product; we do not gold-plate architecture an MVP has not earned, and we do not reach for microservices, GraphQL or a separate front end unless the product has a concrete reason for them.
The engineers who design the app are the ones who write it and keep it running — that is what "we operate what we build" means in practice. It shows up as tested code on the paths that matter, migrations that are safe against live data, background jobs that are idempotent, and a monolith kept deliberately tidy with service objects and thin controllers so it stays cheap to change. You get honest trade-offs about where Rails’ speed helps and where its per-request cost bites, and a codebase your own team can pick up because it looks like every other well-kept Rails app.
The service behind it
Delivered throughCustom Software DevelopmentWhat we build with Ruby on Rails
The disciplines this technology most often shows up in — from a first build to taking over and stabilising an existing one.
How we deliver
- 01
Discover
We map the system, the constraints and the business it serves — including the parts nobody documented.
Architecture brief
- 02
Architect
Decisions get made, written down and defended before a line of production code exists.
Decision records
- 03
Build
Short cycles against working software. You see progress in the product, not in a status deck.
Shipping increments
- 04
Operate
Monitoring, incident response and iteration. The system is alive, so the engagement is too.
Runbooks & SLOs
Industries we use Ruby on Rails in
Domain knowledge changes what gets built. A few of the sectors we know before the first meeting.
Also in Backend
Why teams choose us for Ruby on Rails
Senior engineers only
Rails rewards fluency in its conventions and punishes cargo-culting. The people modelling your domain and drawing your monolith’s boundaries have done it before and have seen how those decisions age — there are no juniors learning the framework on your project.
We operate what we build
We run the Rails apps we ship, so we optimise for the maintenance reality, not the demo. That means disciplined monoliths, safe migrations and idempotent jobs — the things that matter at 3am, not the things that look good in a pitch.
Honest about the ceiling
If your problem is CPU-bound, hard real-time, or your team is standardised on another stack with no Ruby, we will tell you Rails is the wrong tool before you spend money on it. We would rather lose the work than build you the wrong thing.
Typical timeline
- 01
Discovery & domain modelling
Around a week agreeing the domain — the core models, their relationships and the key workflows — because in a Rails app the data model is the foundation everything else rests on.
- 02
First working slice
One to two weeks delivering a real, deployable feature end to end on the golden path, proving the shape of the application against reality rather than a diagram.
- 03
Iterative build
Feature-by-feature delivery in short cycles, each shippable, adding Hotwire interactivity, background jobs and integrations as the product needs them rather than up front.
- 04
Hardening & handover
Query profiling and caching where load demands it, security review with Brakeman, test coverage on the load-bearing paths, and documentation so your team can own and extend the codebase.
How pricing works
- Fixed-scope MVP builds for a well-defined product — a marketplace, a SaaS core, an internal system — quoted once we understand the domain and the workflows, playing directly to Rails’ time-to-market strength.
- Monthly senior engagement for ongoing product work, where scope evolves feature by feature and you want continuity rather than a one-off deliverable.
- Rescue and audit work on existing Rails codebases — a fat-model monolith that has grown hard to change, a performance problem, an upgrade off an old Rails version — priced by the assessment.
Hire Ruby on Rails engineers
Need Ruby on Rails capacity on your own team? We embed named senior engineers into your existing team — reporting to your leads, working in your rituals — so you add capacity without a hiring cycle.
Hire Ruby on Rails engineersCommon questions
Does Rails actually scale?
Yes, and the folklore that it doesn’t is contradicted by the biggest examples in the industry — GitHub, Shopify and Basecamp all run large Rails systems, with Shopify absorbing some of the internet’s heaviest traffic spikes on a monolith. The honest version is that Rails scales with engineering effort, and the limit you hit first is almost always the database, not the framework. A stateless Rails app scales horizontally by adding processes; the real work is in the data tier — indexing, replicas, caching and, eventually, sharding.
Is Rails too slow for production?
For the vast majority of web applications, no. Ruby is slower per request than a compiled language, but request time is dominated by the database, not the interpreter — a slow page is nearly always an N+1 query or a missing index. With sensible query design, caching and background jobs, Rails is comfortably fast enough for most products, and YJIT has improved raw throughput on recent versions. Where you genuinely have CPU-bound or latency-critical work, we would steer that specific path to a different tool rather than force it through Rails.
Do we need React or Vue with Rails, or can Hotwire handle it?
For most products, Hotwire and Turbo handle it — you get live updates and dynamic pages from server-rendered HTML without building and maintaining a separate front end and the API tier it needs. That is cheaper to build and to run. We reach for React or Vue only when the interface is genuinely SPA-shaped: a rich editor, a complex client-heavy dashboard, something with intricate client-side state. We will tell you honestly which side of that line your product falls on rather than defaulting to a heavy front end.
What is the "majestic monolith" and is it outdated?
It is the idea that for most products a single, well-organised Rails codebase beats a set of microservices. It is not outdated — for most teams it is the correct default, because microservices add real operational cost (service boundaries, network calls, distributed debugging) that you should only pay once you have concrete scale or organisational reasons. A disciplined monolith with clear internal boundaries is faster to build and cheaper to run. We extract services deliberately when a concern genuinely warrants it, not by reflex.
How is Ruby on Rails different from the Ruby language?
Ruby is the programming language — the syntax, objects and standard library. Rails is a web framework written in Ruby that adds the conventions, ActiveRecord, routing, generators and everything else that makes it a complete toolkit for building web applications. You can write Ruby with no Rails at all (scripts, CLI tools, other frameworks), but Rails always runs on Ruby. This page is about the framework; if you want the language itself and where it fits beyond the web, see our Ruby page.
Building on Ruby on Rails?
A technical conversation with the engineers who would do the work. If we are not the right fit, we will say so on the call.