Your Rails app got slow. Let's find out why — fast.

A Quick Win usually lands in a few days — sometimes the same week. The classic version: you hand over a slow endpoint and a copy of the data, we profile it, find the bottleneck, and come back with a measured fix. One CattleSoft page went from about 5 seconds to about 1.2 seconds on a single large account inside a day of getting set up. That's one page on one dataset, not a blanket promise — but acute, well-scoped Rails performance problems often move that fast.

Both are on the table, and they're deliberately kept separate. Berube Consulting diagnoses and advises — that's this engagement. If the fix is an eager-load, a query rewrite, or a cache, it often gets handled inside the diagnostic. If it turns into real implementation work, that runs through Durable Programming (a separate firm, same David) as its own engagement — or you take the plan to your own team. There's no assumption a diagnosis turns into a build.

Enough to reproduce the problem: the repo (read access is fine), a copy or representative dump of the relevant data, and access to whatever APM you run (New Relic, Scout, Skylight, Datadog) plus production logs. For the deeper work, the slow endpoints, the request volume, and someone on your side who can answer questions about the app. We scope access to the minimum, sign an NDA up front, and work to your security requirements.

That's the Deep Diagnostic, and it's honest about being the hard case. Latency spikes that show up a few times a day — request queuing, a job storm, memory creeping up until the dyno restarts — are genuinely difficult, and sometimes the first job is just instrumenting the app so the event gets captured at all (request-level traces, GC stats, rack-mini-profiler in staging, a memory profiler under real load). We'll tell you what we're finding as we go, and we won't dress up a hard, unfinished hunt as a clean win.

Sometimes the answer really is an `includes` or a missing index, and if that's the whole fix we'll tell you so instead of inflating the engagement. More often it's a mix: an N+1 hidden behind a serializer, a controller loading 40,000 rows to render 40, a view that renders thousands of partials, a Sidekiq job hammering the database, a cache that never hits, or memory bloat forcing restarts. The point is to find the actual bottleneck — with a profiler, not a checklist.

Ruby on Rails across the versions you'll find in production, from older 4.x/5.x apps through current. Postgres or MySQL underneath, Sidekiq / GoodJob / Resque for jobs, Redis, Puma, Hotwire or a JS front end — the performance work applies across them. Tooling is the usual Ruby kit: rack-mini-profiler, the Bullet gem, derailed_benchmarks, stackprof / vernier, memory_profiler, and your APM. The database underneath is often the real bottleneck, and that's squarely in scope.

David Berube, directly — not a junior assigned to your account. He co-founded Casting Frontier and was its technical lead through a 2020 acquisition by Talent Systems, architecting the Rails platform behind a database of 800,000+ actors used across 45+ of the Fortune 100. He wrote *Practical Ruby Gems* (Apress) and several other books on software development, and has 20+ years of production Ruby and Rails behind him. Rails performance is one of the things he is genuinely best at.

The prices above are honest starting points. A tightly-scoped Quick Win on one endpoint is the cheapest door in; a full assessment or an intermittent-slowdown hunt costs more because it's more work. We scope and quote before starting, the common engagements are fixed-fee, and you'll know the number before you commit. If your problem is smaller than the smallest tier, we'll say so.