Somewhere behind this search is a real application: a Rails app that earns money, needs an upgrade it keeps not getting, or has outgrown the person who built it. What the search returns is thinner than that problem deserves. Most of what ranks is either a ranked list written by one of the companies on it, usually with the author in first place, or a service page that calls itself fast, scalable, and secure without saying what any of that would mean inside your codebase. The buying advice, where it exists, stops at checking the portfolio and reading the reviews.

We run a Rails shop ourselves, so we’re not neutral here either. This is our attempt at the page the search should return: what a Rails development company does all day, the three shapes an engagement usually takes, the questions that separate one shop from another, and the situations where you don’t need a company like ours at all.

The label covers more than “development” suggests. A Rails shop spends its weeks on some mix of five kinds of work: building new applications, carrying existing ones across Rails versions, maintaining production apps month over month, rescuing inherited codebases whose original developers have moved on, and standing in as technical leadership for companies that don’t have a CTO. The balance varies a lot from shop to shop: some are project factories that build, launch, and hand off, while others, like us, skew toward long-running work on applications that are already earning revenue.

You can learn a surprising amount about how a shop thinks from what it publishes, because some kinds of work can’t be faked with adjectives. Upgrade work is like that. Our working guides to upgrading Rails 6 to 7 and upgrading Rails 7 to 8 walk through the real mechanics, and reading anything similar from the shops on your list will tell you more than their awards pages will. Since we’re asking you to weigh us the same way: we’re Ecliptic Ideas, a Ruby on Rails consultancy based in Coronado, California, founded in 2015.

Nearly every engagement with a Rails shop takes one of three shapes, and knowing which one you’re shopping for keeps the conversations short and makes the quotes comparable.

A project has a defined scope and an end date: the shop builds the application or delivers the upgrade, hands off, and leaves. It fits when the work is well defined and you have someone on your side who can evaluate what gets delivered.

A maintenance retainer is the ongoing shape: a team that keeps a production application patched, upgraded, and monitored. It fits when the app is live and earning, nobody inside the company is watching the Rails release calendar, and problems tend to be discovered by your customers before your tooling. We’ve written a full piece on what a well-run Rails maintenance retainer contains month to month, so we won’t restate it here; if a monthly relationship is what you’re weighing, start there.

A fractional CTO engagement layers decision-making on top of delivery: someone senior who owns the technical roadmap, vendor choices, and hiring questions while a team handles the building. It fits when nobody at your company really owns technology decisions, so they keep getting made by default. Whether you need that layer at all is a real question, and we’ve written about the signs your company needs a fractional CTO to help you answer it.

Every buying guide tells you to check the portfolio and read the reviews. Do both, but expect them to eliminate almost nobody, because every shop that reaches page one has a polished portfolio and a wall of five-star quotes. The questions below are the ones that separate shops. A team that does careful Rails work will answer them quickly and in specifics; everyone else answers in generalities, and you’ll hear the difference.

1. Which version upgrades have you shipped, and how did you run them? A shop that lives in Rails will name the specific hops it has carried applications across and describe the method: dual-booting the app on two framework versions during the transition, how the deprecation backlog got worked down, and what deploy day looked like. Push on that last part, because careful and careless upgrades differ most at deploy time. Our own standard on client work is that major Rails and Ruby upgrades ship with zero downtime.

2. What is your policy on end-of-life versions? Rails publishes its maintenance windows, and a shop that manages production applications should be able to tell you exactly how it keeps clients inside them. If the person across the table isn’t fluent in the Rails end-of-life schedule, they aren’t watching the deadlines that decide when your app stops getting security fixes.

3. What test coverage do you hold client work to? Any concrete number beats a paragraph about craftsmanship, because a number means coverage gets measured and slippage gets noticed. We keep client projects at 80 to 90 percent, and whatever figure a shop gives you, the useful part is hearing them commit to one.

4. Who writes the code, and who reviews it? Ask this plainly, because shops differ widely in how they work today and in how openly they’ll tell you. Here’s our answer: AI writes the code at our shop today, and senior engineers direct and review every change. Whatever answer you get, what matters is that a policy exists, that review belongs to a named senior person, and that nobody gets cagey when you ask.

5. Who owns deploys and production access? The deploy pipeline, the hosting account, and the credentials should be yours, with the shop working inside access you grant. If leaving your vendor would mean asking them for your own keys, that’s leverage you handed over for no reason.

6. What does leaving you look like? Ask about the exit while you’re still negotiating the entrance, when the answer costs nothing. A good one covers documentation, repository ownership, credential handover, and how the final month winds down. A shop that expects to keep clients through good work has no trouble describing how you’d go.

Some signals are worth walking away from no matter how good the portfolio looks.

• A rewrite recommendation before anyone has read your code. Rewrites are occasionally the right call, but they’re rare, and a shop whose opening move is its own largest possible project is telling you how it bills.
• A first conversation with no questions about your test suite, your deploy process, or your dependency situation. A team planning to work inside your codebase should be curious about its condition before promising anything.
• A portfolio that’s all launches, with nothing held and maintained for years. Shipping a new app and keeping one healthy are different skills, and an application that’s earning needs the second one.
• A price before a diagnosis. Whatever that number is, it wasn’t derived from your application.

An honest guide has to include the cases where the right answer is no development company at all, so here they are.

A single senior contractor is the better hire when the work is one well-defined project, someone technical on your side can review what gets delivered, and you don’t need continuity after it ships. One good contractor starts faster and costs less than a firm, and on a short project the things a firm adds, like review layers and redundancy behind any one person, may never come into play.

Your current generalist agency can also be the right choice. If they built your product, know it well, and the Rails work you need is a small slice of a larger relationship, the switching cost of a new vendor may outweigh what a specialist would bring. What a Rails specialist adds is depth over time: version upgrades run on a calendar, production incidents get handled by people who have seen that failure before, and codebase decisions get made by a team that plans to be around to live with them.

If you’ve read this far, you’re past what the ranked lists can do for you, so here’s the concrete next step, whoever you end up talking to: put the questions above in front of your shortlist, in writing or on a call, and weigh how specific the answers are. If you’d like us on that shortlist, our engagements start with a week-one codebase audit, so the first thing you receive from us is a written account of your application’s actual condition. Our Ruby on Rails services page covers how we approach production Rails work, and when you’re ready, you can book an intro call with us directly.