We've been on both sides of this — as the agency being evaluated and as a fractional CTO helping founders pick someone else. The pattern is consistent: founders make this decision based on the sales conversation, then live with the engineering for years. The signals during a sales call tell you almost nothing about what the engineering will actually look like.
Here's the framework we wish founders used. Same checklist, same exercise, every time.
How do you pick a good Rails development company?
Evaluate Rails development companies on three axes: Rails-specific depth (years on the framework, named gems they maintain or contribute to), production engineering practice (visible test coverage, deploy frequency, named clients running their code at scale), and team transparency (you talk to engineers, not account managers). The interview itself should include a small paid trial — actual code, not a sales demo.
Watch first: a 100-second refresher on what Rails actually is in 2026
Before evaluating Rails companies, make sure you and they agree on what Rails actually is in 2026. The 100-second Fireship overview is the fastest baseline — Hotwire, Solid Queue, Solid Cache, Propshaft, the modern Rails 8 stack. If an agency pitches Rails like it's 2018, that's your first signal.
The 7 questions that separate Rails shops from generic agencies
Run through these in your first call. The answers tell you whether you're talking to Rails engineers or salespeople with a Rails landing page.
1. "Which Rails gems do you maintain or contribute to?"
Real Rails shops have public open-source presence. Maybe they maintain a niche gem; maybe they contribute pull requests to Devise, Sidekiq, Rails itself. If the answer is "we use lots of gems," that's a generic-agency answer — they consume open source but don't participate in it. The good agencies will have GitHub orgs you can browse.
2. "Walk me through how you handle background jobs in Rails 8"
A real Rails engineer can explain Solid Queue vs Sidekiq, when to pick each, and what they default to in 2026. They'll mention specific gotchas — Sidekiq's idempotency requirements, Solid Queue's database backpressure, how they monitor job failures. A generic agency will say "we use Sidekiq" and not be able to go deeper.
3. "What's your testing approach for Rails?"
Specific answers: RSpec vs Minitest preference and why, system-test approach (Capybara, Cuprite), CI runtime per build, how they handle factory bloat, fixture vs FactoryBot choice. If they answer "we write tests" without specifics, they don't write tests rigorously.
4. "Can I see a Rails app you shipped, deployed and live?"
Not screenshots — actual URLs. The good agencies have multiple production references; the bad ones have NDAs covering everything. Some NDAs are real, some are convenient excuses. Ask for at least two live URLs and one anonymized GitHub repo.
5. "How do you handle Rails version upgrades?"
Real Rails work involves continuous version management. A real Rails shop has done Rails 5→6→7→8 upgrades and can describe their process — strong_migrations gem, dual-booting, the deprecation-warning sprint, the gotchas of each version transition. A generic agency stays on whatever version the project started with and gets stuck.
6. "What's your deployment stack?"
Modern Rails answer: Kamal or Heroku or Render. Maybe Docker + ECS for scale. Specific opinions about CI/CD (GitHub Actions usually), database hosting (RDS, Neon, or self-managed), monitoring (Sentry + Skylight or AppSignal). A generic agency says "AWS" and stops there.
7. "Will the engineers writing my code be on these calls?"
The biggest divide between good Rails shops and salesy agencies. Good shops have engineers join discovery calls — they want to understand the technical problem. Salesy agencies hide engineers behind account managers and pass requirements through a game of telephone.
The paid trial sprint test
The most reliable signal: run a paid trial. Hire the agency for one specific feature — 2-3 weeks of work, $5-15k. Look at what they deliver.
Things to evaluate after the trial:
- Code quality. Does it follow Rails conventions? Tests pass? Code reviews show real architectural discussion?
- Communication style. Did they ask clarifying questions early, or build the wrong thing then bill for rework?
- Documentation. Did the PRs have meaningful descriptions? Is the architecture documented anywhere?
- Speed. Did they deliver in the estimated time, or did 2 weeks become 4?
- Pushback. Did they push back on bad ideas (yours included), or just execute whatever was asked?
The trial costs more than picking based on a sales call, but it saves orders of magnitude more by avoiding a bad multi-month engagement. We've seen founders skip this and lose 6 months rebuilding from scratch with a different team.
Pricing benchmarks (2026)
What real Rails work actually costs, by tier:
| Tier | Hourly | Typical engagement |
|---|---|---|
| Cheap offshore (mostly junior) | $20-35/hr | High oversight needed; you pay in rework cycles |
| Mid-tier offshore (mixed senior) | $40-70/hr | Decent for capacity work, weak on architecture decisions |
| Senior-only specialty shop (India, EE) | $60-120/hr | Where we operate; best value-per-dollar for complex Rails work |
| US/UK senior Rails shop | $150-300/hr | Same quality as senior-only specialty shops, 2-3x cost |
| Boutique founder-led (Thoughtbot, etc.) | $250-400/hr | Premium positioning; useful for high-stakes architecture decisions |
For more on hiring economics, see our cost to hire a Rails developer in 2026 writeup which covers both contracting and FTE math.
Red flags that should kill a deal
- "We do Rails, Node, Python, PHP, and mobile." Specialists ship better Rails than generalists. If Rails is one of 10 bullets on their landing page, it's not their depth.
- No GitHub presence. Real Rails engineers have public code. If you can't find any, the engineers either don't have it or the agency hides them.
- Pushback when you ask to talk to engineers. "Our project managers handle communication" = your requirements will be filtered through people who don't write code.
- "We'll figure out the architecture after we start." Real Rails shops have opinions about architecture up front. They might revise them, but they won't show up empty.
- No testing in their portfolio repos. Look at any public code they have. Zero tests = they don't write tests on private code either.
- Promises of "10x faster" or "we use AI to ship in days." Real Rails work has predictable cadence. AI can accelerate parts, not architecture decisions. Promises of magic = sales theater.
- Refusal to do paid trial. The trial is small enough that no real agency should refuse. Refusal means they know their delivery doesn't match their pitch.
Why Rails specifically (and is it still worth it?)
The reason to specifically want a Rails shop in 2026 is because Rails is genuinely productive for the apps you'd typically build on it — SaaS, marketplaces, B2B portals — and the talent gap between a real Rails engineer and a generic full-stack developer is significant. Rails has conventions. People who know them ship faster.
If you're still deciding whether Rails is the right stack at all, our Is Rails still relevant in 2026 writeup covers the framework's current state. Our Rails SaaS development guide is the deepest case for choosing it for SaaS specifically.
What working with us looks like
For full disclosure on what a real engagement looks like, our RankLoop case study shows a Rails SaaS we built end-to-end and continue to operate. It covers the actual decisions made — Rails 7 then 8, multi-tenant architecture, Stripe integration — at the level of detail that lets you evaluate whether the engineering reasoning is sound.
External references
- Ruby on Rails official site and guides — the canonical resource. Any Rails shop you're evaluating should be able to point to specific guides they treat as authoritative.
- Rails 8 — "no PaaS required" announcement — DHH's framing of where Rails went in 2024-25 and why deployment got simpler.
- Shopify Engineering Blog — the largest Rails app in the world publishes their engineering decisions openly. Required reading for serious Rails work.
FAQ: Choosing a Rails development company
How much does it cost to hire a Ruby on Rails development company?
$60-120/hr at the senior-only specialty tier where the best value sits; $150-300/hr at US/UK shops; $250-400/hr at boutique founder-led firms. Cheap offshore at $20-50/hr appears cheaper but typically costs 2-3x more end-to-end after rework cycles. Total MVP cost typically falls in the $30-80k range for a senior-only engagement.
What should I look for when hiring a Rails developer or agency?
Real Rails depth (open-source contributions, gems they maintain), public GitHub presence, engineers who join discovery calls rather than account managers, opinions about testing and deployment, and willingness to do a small paid trial. Avoid agencies that list Rails as one of 10 stacks — depth beats breadth for Rails specifically.
Is Ruby on Rails still relevant in 2026?
Yes. Shopify, GitHub, Basecamp, Cookpad, Coinbase, and Zendesk all run Rails in production at scale. Rails 8 added Solid Queue, Solid Cache, Solid Cable, and an authentication generator. The framework is more capable in 2026 than it was at peak hype in 2014.
Should I hire a US-based or offshore Rails team?
For most pre-PMF SaaS, senior-only offshore (India, Eastern Europe, LatAm) at $60-120/hr offers the best value — same quality, 2-3x cheaper than US-based seniors. For real-time-collaboration-critical work or in-person team integration, nearshore beats far-shore on timezone overlap. Cost alone shouldn't drive the decision; communication style does.
What questions should I ask a Rails development company in a first call?
Which Rails gems do they maintain or contribute to; how they handle background jobs in Rails 8; their testing approach (RSpec vs Minitest, system tests); links to two production Rails apps they shipped; how they handle Rails version upgrades; their deployment stack; and whether the engineers writing the code will be on calls. Specific answers separate Rails specialists from generic agencies.
How we can help
At TechVinta, Rails is our core specialization, not a bullet on a landing page. We maintain public Rails gems, contribute to the framework, and our engineers have shipped Rails apps from MVPs to multi-region SaaS at production scale. Most engagements start with a 1-week paid discovery so you can evaluate the engineering quality before committing.
Evaluating Rails development companies or considering a build? Talk to our Rails team or get a free estimate — we'll review your requirements and propose a plan within 48 hours.