Rails monoliths that are 10 years old and still shipping.
For the teams who built on Rails before it was unfashionable and now need to keep shipping without a rewrite. Rails 7, 8, Hotwire, Solid Queue.
Rails is not dead. Your version of it might be.
Most production Rails apps in 2026 are on Rails 6.1 or 7.0, behind on Ruby version, fighting webpacker, and patched against a half-dozen since-deprecated gems. The team that built it has rotated twice. The CTO is told quarterly that "we should really migrate off Rails." Nine times in ten, the right move is to stay on Rails and modernise the parts that hurt. We have done that migration enough times to know which parts.
What changes when a Metafic pod is in your repo.
Rails 7 / 8 upgrade as a feature branch
Not a months-long initiative. We do these in 6-8 weeks with feature flags on the new code paths, dual-running where critical, and a rollback plan that does not require a database restore.
Hotwire over Vue/React for new internal tooling
When the user is a logged-in admin, Hotwire ships in a fraction of the time. We do not re-platform you to a SPA just to add a settings page.
Solid Queue replaces the Sidekiq + Redis dance for most workloads
Database-backed jobs are mature in Rails 8. We migrate teams off the Redis dependency where it is more cost than value.
Performance work driven by traces, not opinions
Skylight, Scout, or DataDog APM hooked in by week one. We optimise the routes you actually have, not the ones you might.
ActiveRecord audited before any other optimisation
Most "Rails is slow" problems are ActiveRecord N+1 or unbounded includes. We catch them in CI, not in production.
Who is on the pod for this work.
Pods scale up from here for Enterprise engagements.
Has shipped Rails in production since at least Rails 4. Specific opinions on what to leave alone.
5+ years Rails, comfortable reading 200K-line monoliths and modifying without breaking.
RSpec + system tests with Capybara, plus the integration tests that run against a real Postgres in CI.
Tuned to read Ruby idioms (not just Python-style code), suggest concern extractions, and propose model-test scaffolds.
The bugs that bite this stack.
Webpacker still in the build chain
You should be on jsbundling-rails or importmap-rails. Webpacker is unmaintained as of Rails 7. We migrate.
Background jobs without idempotency keys
Sidekiq retries by default. Your "send notification" job sends three. We add the idempotency layer.
Old Rails plugins running monkey-patches
The reason your test suite breaks on Ruby upgrade. We audit and replace.
CounterCache and Touch cascading without bound
A single update saving 40 records because of nested touch chains. We measure and prune.
Honest about scope.
We will not migrate you off Rails to Phoenix, Go, or Next.js unless the actual constraint demands it. Most "we need to move off Rails" conversations are really "we need to upgrade Ruby and clean up our service layer" conversations.
Common questions.
Should we migrate off Rails?
Almost never. The exceptions: you have a real-time-heavy workload that the GIL or Ruby allocation patterns hurt; you have an offer to acquire-hire and the buyer specifically wants a different stack; or you have a hard constraint we cannot solve inside Rails.
Hotwire or React for the admin?
Hotwire for almost all internal tooling. React when you have genuine client-side state machines (drag-drop editors, real-time collaborative UI).
Sidekiq or Solid Queue in 2026?
Solid Queue if you are on Rails 8 and your workload is moderate. Sidekiq if you have high-throughput jobs or already operate Redis at scale.
Can you upgrade us from Rails 5 to 8?
Yes, common engagement shape. We do it in two big jumps with feature flags between them, not as a single big-bang.
Ready to scope it?
A 25-minute call. We will tell you what we would do, what we would not, and whether a pod is the right shape.
Or stay in the loop. One engineering teardown a week.