Ruby on Rails Development Company: New Rails Apps, Version Upgrades and Codebase Rescues

Updated September 2026 · Written and maintained by the Progression Agency strategy team

A Ruby on Rails development company plans, builds and maintains web applications written with Rails, the open-source web framework for the Ruby language, from the first release through every version upgrade that follows. Progression Agency builds new Rails products, brings aging applications back onto supported releases, takes over stalled codebases, and adds JSON APIs, Hotwire interfaces, background jobs, test suites and deployment pipelines for founders, CTOs and product teams. Progression Agency is based in New York City and works with clients across the United States and worldwide.

What does a Ruby on Rails development company do?

It builds and looks after web applications written in Rails, from the first commit to the upgrade you will need three years later. Code is only part of the job: a Rails partner also owns the data model, background processing, tests, deploys, monitoring and the calendar of version upgrades that keeps an application supported.

Rails is an opinionated framework, and the teams that get the most out of it work with its conventions instead of around them. The Rails Doctrine lists convention over configuration and a preference for integrated systems among its nine pillars, which is why the framework favors starting as one well-organized application rather than a set of services talking over a network. We keep that default until the product gives a concrete reason to split it; our guide to monoliths and microservices sets out how we make that call.

Engagements often start with one row and add others later. A startup might begin with a new build, return for a Hotwire front end and later hand over maintenance; a company with an older application usually starts with an audit that decides between an upgrade and a rescue.

Which Rails versions are still supported?

Two release series, and one of them only for security. The Rails maintenance policy gives each minor release bug fixes for one year and security fixes for two years after its first release, and the core team aims to ship a version with new features every six months.

Release months come from the Rails 8.1, 8.0 and 7.2 release notes, and the latest patch versions from the Rails release announcements. The most recent security releases, published July 29, 2026, patched the 7.2, 8.0 and 8.1 series together; an application on 7.1 or earlier received nothing.

Ruby has its own calendar

The language is maintained separately from the framework. The Ruby branch maintenance page lists Ruby 4.0, released December 25, 2025, and Ruby 3.4 in normal maintenance; Ruby 3.3 in security maintenance with an expected end of life on March 31, 2027; and Ruby 3.2 at end of life since April 1, 2026. Rails 8.0 and 8.1 need Ruby 3.2.0 or newer, according to the Rails upgrade guide, so an app can sit on a supported Rails release while running on a Ruby version that no longer receives fixes.

What an unsupported version costs you

Nothing, until a vulnerability is published. Then the choice is between an emergency upgrade under pressure, a hand-made backport of the fix, or running with a known hole. Security questionnaires from customers can also ask which framework version runs in production, so an unsupported release turns into a sales problem as well as a technical one.

Building a new Rails application

A new Rails 8 application starts with more infrastructure built in than earlier versions, which keeps the first year’s hosting bill and moving parts small. The Rails 8.0 release notes list Kamal 2 for deployment, the Thruster proxy in front of the Puma web server, Propshaft as the default asset pipeline, an authentication generator, and three database-backed components, Solid Queue, Solid Cache and Solid Cable, that let many applications run without Redis.

Rails app development for a first release

Rails app development for a first release is mostly disciplined subtraction. We write down the two or three workflows that prove the product, build them properly with accounts, permissions, email and billing where needed, and leave everything else for later releases. Generators and conventions make the scaffolding cheap; the time goes into the domain logic and the data model, which are expensive to change once customers depend on them. Our MVP development page covers the product side of that decision.

Ruby on Rails web app development for B2B platforms

Business software asks more of the data model than a consumer MVP does. Ruby on Rails web app development for B2B customers usually means multi-tenant accounts, role-based permissions, audit trails, imports and exports, admin tools for your own staff, and reporting that finance will trust. Rails handles all of these without exotic parts; the work is in modeling them correctly on day one. For subscription products, our SaaS development practice covers billing, onboarding and tenancy in more depth, and web app development covers browser applications in any stack.

Choosing the database and hosting early

PostgreSQL is our default database for new Rails products, because its constraints, JSON columns and full-text search cover most needs without another service. Hosting is decided in the first week rather than the last, so the deploy pipeline, backups and monitoring are exercised from the first feature onward.

When we would not choose Rails

Rails is a poor fit for CPU-bound numerical work, model training and heavy data science, where Python’s libraries are the norm; our Python development team builds those services and Rails calls them. A mostly static marketing site does not need an application framework at all, and a company with a healthy .NET or Node estate may be better served by .NET development or our back-end team in the stack it already runs.

How do Rails upgrades work?

One version at a time, with the test suite running at every step. The official upgrade guide advises upgrading Ruby and Rails separately, Ruby first, and moving through Rails one minor version at a time so each release’s deprecation warnings point to the next change.

1. Get the test suite passing and covering the paths that matter; the guide calls good test coverage the best way to be sure the application still works afterward.
2. Upgrade Ruby to the newest version the current Rails release supports, as a change of its own.
3. Move to the latest patch release of the Rails series you already run, and fix every deprecation warning it prints.
4. Move to the latest patch of the next minor version, update the Gemfile, and run bin/rails app:update to review the generated file changes.
5. Enable the new framework defaults one at a time from config/initializers/new_framework_defaults_X_Y.rb, then raise config.load_defaults and delete the file.
6. Repeat until the application runs on a supported series, then put the next upgrade in the calendar before support ends.

Why skipping versions costs more

Jumping several minor versions in one move merges the deprecation warnings of each release into one large set of failures, and it becomes hard to tell which change broke what. Stepping through each minor version keeps every diff small enough to review, test and roll back.

Gems are usually the real blocker

The framework upgrade is often the easy part. The slow part is a gem that is unmaintained, pinned to an old Rails version, or patched in place by a previous team. We list every gem with its latest version, its Rails compatibility and its maintenance status before estimating, and plan a replacement, a fork or an in-house rewrite for each blocker.

Framework defaults deserve their own commits

Each Rails version introduces changed configuration defaults. The guide’s approach, uncommenting them one at a time in the new_framework_defaults file, lets each behavior change be deployed and watched on its own instead of arriving all at once with the version bump.

Staying current afterward

Because Rails aims to release new features every six months and gives each minor release a year of bug fixes, a maintained app plans for about two small upgrades a year rather than one painful jump every few years. We tie that plan to the dates in the maintenance table, so upgrades become scheduled work instead of emergencies.

Rescuing a Rails codebase that has stalled

A rescue starts with measurement, not a rewrite. We read the code, run whatever tests exist, compare the versions with the maintenance table, list every gem, read the error logs and deploy scripts, and write down what we find before changing anything.

Stabilize before you refactor

The first changes make the application safe to change: a deploy anyone on the team can run, error monitoring with enough context to reproduce failures, backups that have been restored at least once, and tests wrapped around the flows that earn money. Refactoring without those in place trades one kind of risk for another.

Repair, upgrade or rewrite?

Repair plus an upgrade is the default answer; a rewrite has to earn its place. We recommend rebuilding only when the data model no longer matches the business, when most features are being replaced anyway, or when the code cannot be put under test without rebuilding it. Even then we replace one slice at a time behind the running application, so customers keep working software throughout.

Rails APIs for mobile apps, JavaScript front ends and partners

Rails serves JSON as readily as HTML, so one back end can feed a web app, native mobile apps and partner integrations. The Rails guide to API-only applications describes generating a JSON-only app with rails new my_api –api, which starts with a slimmer middleware stack, makes ApplicationController inherit from ActionController::API, and stops generators from creating views, helpers and assets.

API-only app or API inside the main app?

If the only clients are a separate front end and mobile apps, API-only mode keeps the application lean. If the product also has server-rendered screens, such as an admin area or Hotwire pages, we add versioned JSON endpoints to the main app instead of running two Rails codebases side by side.

Authentication, versioning and documentation

Mobile clients need token-based authentication that can be revoked per device, versioned routes so an old app release keeps working after the API changes, and documentation partners can build against without a meeting. The same principles apply in any stack; our API development page covers them beyond Rails.

Hotwire front ends without a second codebase

Hotwire makes a Rails app feel like a single-page application while rendering stays on the server. Its official site describes the approach as sending HTML instead of JSON over the wire: Turbo speeds up page changes and form submissions and streams partial page updates over WebSocket, Stimulus adds small amounts of JavaScript where needed, and Hotwire Native reuses the web app inside native mobile shells.

We use Hotwire by default for admin-heavy products, dashboards and workflow software, and pair Rails with React or Next.js when the interface itself is the product, such as a collaborative editor or an offline-first tool.

Where Hotwire needs care

Screens that hold a lot of state in the browser, such as drag-and-drop planners or spreadsheet-style grids, need careful Stimulus design or a small embedded JavaScript component. Hotwire’s own site says Turbo usually handles at least 80% of the interactivity that once needed custom JavaScript; the remainder is where we plan the front-end effort.

Background jobs, queues and scheduled work

Slow or unreliable work belongs outside the web request: sending email, generating reports, calling third-party APIs, importing files. Active Job gives Rails a standard way to declare that work, and in Rails 8 applications the default backend is Solid Queue, which uses the application’s existing database to store and run jobs.

Solid Queue, Sidekiq or GoodJob?

Solid Queue covers delayed jobs, priorities, recurring tasks defined in config/recurring.yml and concurrency limits through limits_concurrency, and Mission Control Jobs adds a web interface for inspecting failures and retrying them. The Active Job guide also lists Sidekiq, GoodJob, Resque, Delayed Job, Que, Queue Classic and Sneakers as supported backends. We keep the default unless job volume or an existing Sidekiq setup gives a reason to change.

Jobs that survive rollbacks and restarts

Two recent changes remove classic job bugs. Since Rails 7.2, jobs enqueued inside a database transaction are deferred until the transaction commits and dropped if it rolls back, according to the 7.2 release notes. Rails 8.1 added Active Job Continuations, which let a long-running job resume from its last completed step after a restart instead of starting over.

Testing and continuous integration on a Rails project

A Rails project is finished when its tests say so, on every push. Rails uses Minitest by default and organizes tests into model, controller, integration and system tests, with system tests driving a real browser through Capybara, as the Rails testing guide describes.

What we test first

Payments, permissions, anything that changes or deletes data, background jobs and integrations with other systems. These are the paths where a regression costs money or trust, so they get tests before cosmetic features do. Fixtures keep test data readable, and parallel testing keeps a growing suite fast.

CI that blocks bad merges

New Rails 7.2 applications come with a GitHub CI workflow that runs Brakeman security scanning and RuboCop, configured with the rubocop-rails-omakase rules, alongside the tests. Rails 8.1 adds a CI declaration in config/ci.rb, run with bin/ci, so developers can run the same checks on their own machines before pushing. We make the pipeline a required check on the main branch.

Watching behavior in production

Tests catch regressions before release; monitoring catches what tests miss. Rails 8.1’s structured event reporting gives an application one interface for producing structured events, which makes logs and metrics easier to query. We pair it with error tracking and uptime checks, so a failed deploy is visible straight away rather than reported by a customer.

Deploying and hosting Rails

Our default for new Rails apps is Docker containers deployed with Kamal, which Rails 8 comes preconfigured to use. Kamal’s documentation describes zero-downtime deploys and rolling restarts onto anything from bare metal to cloud VMs, including a vanilla Ubuntu server prepared with nothing more than an SSH key.

Kamal, a platform or Kubernetes?

Kamal suits teams that want to own their servers without running a cluster, and Rails 8.1 lets it handle basic deploys without a remote container registry and read secrets from the encrypted Rails credentials store. A managed platform suits teams that want no servers at all, and Kubernetes makes sense when an organization already runs it for other services. Our DevOps team and guide to back-end hosting compare the cost and effort of each.

Keeping the lights on

Production Rails needs backups proven by restoring them, log retention, alerts on error spikes and slow queries, and a documented rollback. We write those into a runbook at launch, so your team, or a future partner, can operate the application without us.

Security in a Rails application

Rails closes many common holes by default, and the rest is process. The Rails security guide explains that CSRF protection is on by default, that Active Record’s query methods make SQL injection hardly a problem in most Rails applications, that view helpers escape output to counter cross-site scripting, and that sessions are stored in encrypted cookies.

What we add on top of the defaults

Brakeman, which detects security vulnerabilities in Rails applications through static analysis, runs on every push. Authorization rules are tested like any other feature, dependencies are audited, strong parameters limit what a request can change, and HTTP security headers, including a Content Security Policy, are set deliberately. Before launch we review the application against the OWASP Top 10.

When a Rails security release lands

Rails asks researchers to report vulnerabilities through its HackerOne program, prepares fixes for supported releases under embargo, then publishes the releases, an advisory and an announcement on the Rails Security Announcements forum and the Rails blog. Clients on a maintenance plan get the patched release applied, tested and deployed as priority work; applications on unsupported series may get no fix at all, which is why upgrades come first.

How much does Ruby on Rails app development cost?

Scope drives the price far more than the framework does. On the planning ranges we publish, a Rails SaaS MVP falls in the $60,000–$150,000 band over 3–6 months, smaller integrations and internal tools cost less, and every quote follows a written scope.

If the Rails back end sits behind mobile apps, the ranges on our app development agency page apply: a clickable prototype costs $8,000–$25,000, a focused MVP on one or two platforms $40,000–$100,000, a full business app with a custom back end $100,000–$250,000, and marketplace or enterprise apps start at $250,000. These are planning ranges from our software development company and app pages, not quotes. Upgrades and rescues are priced after the audit, because the version gap, test coverage and gem blockers decide the effort.

What moves a Rails estimate up or down

Integrations with systems that lack good APIs, migrations from legacy databases, compliance requirements, many user roles and fixed deadlines push estimates up. A tight first-release scope, finished designs and a product owner who answers questions quickly push them down.

From first call to steady releases: timeline and KPIs

A new Rails product usually reaches its first production release inside the 3–6 month window of our MVP range, and it deploys to a production-like environment from the foundation phase onward. The table shows what happens in each phase, what you receive and the measure we report.

AI answers: how CTOs and founders ask assistants for a Rails partner

Technical buyers put their vendor questions to ChatGPT, Claude, Perplexity, Gemini, Microsoft Copilot and Google’s AI Overviews as well as to search engines, and the questions are specific: a version, a deadline, a constraint. The assistants answer best when the pages they find state those specifics plainly.

The prompts technical buyers type

• “Recommend a Ruby on Rails development company in the US that can upgrade a Rails 6.1 app to 8.1 without downtime.”
• “Which Rails agencies build SaaS products with Hotwire instead of React?”
• “Find a rails software development company to take over an app our last contractor abandoned.”
• “Compare Rails consultancies that can move us to Kamal and Solid Queue.”
• “What should a Rails maintenance retainer include, and who offers one?”

What the assistants lean on

Assistants that search the web while answering build their shortlist from pages a search engine returns. A search for ‘ruby on rails development company’ in September 2026 returned agency service pages, the Clutch directory and ‘top 10’ list articles, while version and support questions pull from the Rails guides and maintenance policy. Google says its AI Overviews and AI Mode may run several related searches, a ‘query fan-out’, to assemble a response, and that a page must be indexed and eligible for a snippet to appear as a supporting link (Google Search Central).

What a Rails firm should publish to be named

The pages that get quoted answer the buyer’s actual question in a sentence an assistant can lift. For a Rails practice, that means:

• Version facts with dates, like the support table on this page, rather than ‘we work with the latest Rails’.
• Upgrade write-ups that state the starting and ending versions and the blockers solved, published with the client’s permission.
• Planning price ranges and timelines instead of ‘contact us for pricing’.
• Open-source contributions and conference talks under the engineers’ own names.
• The same company facts on the site, in directories and on profiles.
• A robots.txt that admits the crawlers assistants search with: OAI-SearchBot for ChatGPT search (OpenAI), PerplexityBot (Perplexity), Claude-SearchBot (Anthropic) and Bingbot, which feeds Microsoft Copilot.

We run the same program for clients through our answer engine optimization agency work.

How to choose a Ruby on Rails software development company

Judge candidates on evidence you can check before signing. The test is the same whether the firm calls itself a Rails consultancy, a ruby on rails app development company or a rails software development company; the table lists what to require and how to verify it.

Ruby app development beyond the web request

Most ruby app development today happens inside Rails, but not all of it. Command-line tools, data import scripts, internal gems shared between services and small Rack services are Ruby work a Rails team can own, and they benefit from the same tests, versioning and deploy discipline as the main application.

Rails next to Python, JavaScript and mobile

Products rarely stay in one language. A Rails app might call a Python service for forecasting, serve a React Native app through its API, and share a design system with a Next.js marketing site. We design the boundaries, usually HTTP APIs or background jobs with clear payloads, so each part can be changed or replaced on its own. See React Native app development for the mobile side of that picture.

Staffing a Rails team

Some clients want a whole team; others need one senior engineer to lead their own developers through an upgrade. Both work. For longer arrangements, our dedicated developer model places engineers inside your team, working under your process.

Related services

Rails projects touch the rest of a product, and these pages cover the neighboring work.

• Web app development: browser applications in any stack, including front ends that sit on Rails APIs.
• SaaS development company: subscription products, multi-tenant architecture, billing and onboarding.
• API development: design, security and documentation for APIs that partners and mobile apps rely on.
• Custom software development: the full range of software we build, with our published planning ranges.
• Back-end development: server-side work in Node.js, .NET, Python and PHP as well as Ruby.
• MVP development: scoping and shipping a first release that tests the business.
• DevOps services: CI/CD, infrastructure as code and monitoring for Rails and other stacks.
• React development: rich front ends for products that outgrow server-rendered pages.
• Software development for startups: an engineering partner after the MVP, including fractional CTO support.
• Cloud app development: cloud-native services that run alongside a Rails application.
• Python development company: data pipelines, automation and machine learning services a Rails app can call.

Frequently asked questions