Why Gusto hired Evil Martians for Sidekiq infrastructure

Gusto brought in Evil Martians to work on the infrastructure behind their background jobs: Sidekiq, the Redis-backed background job framework that most large Rails applications run on. At Gusto, it’s also the layer where payroll runs, documents get processed, and money actually moves.

This is the story of our engagement, and of a question: why would a company with this much engineering talent hire consultants at all?

One of the best Rails stories in the industry

Gusto’s business is booming, and so is its engineering. The product runs on one of the largest Rails monoliths anywhere. This team has shaped how the whole industry runs big Rails codebases. Gusto pioneered packs, the gradual modularization approach that splits a monolith into team-owned packages, and open-sourced the rubyatscale tooling around it, from Packwerk-based boundary enforcement to the code_ownership gem that maps every file to a team.

They give back at the ecosystem level, too. Gusto is a Rails Foundation contributing member and became the inaugural member of Ruby Central’s Ruby Alliance in May 2026, committing significant investments into the long-term health of the Ruby ecosystem.

Membership money like that funds work the whole ecosystem gets to use. The Rails Foundation commissioned Evil Martians to build Agents on Rails, the benchmark that measures how coding agents actually perform on Rails codebases: accuracy, speed, token spend, and cost.

And they ship fast. In April 2026, Gusto acquired the compliance platform Mosey and launched payroll access inside Claude and Slack within 48 hours. By May, business owners could run payroll and ask wage and overtime questions in natural language inside Claude, ChatGPT, and Slack.

Their best velocity story comes from the top. When cofounder and head of technology Eddie Kim missed a connecting flight at Heathrow, he opened Claude Code in the airport lounge and prototyped what became Gusto Cofounder, an AI teammate for small businesses.

A team of four engineers and one designer took that prototype to a tier-one launch in ten weeks, with no Figma, Jira, or specs, with progress measured entirely in pull requests.

We’re customers, too. Evil Martians Inc. runs payroll for our US employees through Gusto, myself included. Every Friday a text message arrives to say we’ve been paid, and it still makes me smile.

So this is one of the elite Rails teams: vast codebase, strong conventions, real momentum. This makes the next part really interesting.

Why would this team hire consultants?

Gusto didn’t need us because they were short on brilliant engineers. They have plenty.

There’s one reason a team like this brings in outside help: a specific, hard, high-stakes piece of infrastructure. They wanted people who had already spent years on that exact problem. For Sidekiq at this scale, that list is short, and Evil Martians employ several of the people on it.

That’s also the boundary. We’re not the answer to general feature velocity, and Gusto has that covered better than most companies ever will. We’re the answer when one layer is hard enough, and consequential enough, that you want people who have already broken it and fixed it somewhere else.

The proof is on the shelf. If you run Sidekiq in production, chances are you’re already running code our team wrote and maintains:

The thinking behind that shelf is public, too. Alexander has spent years on fairness and prioritization in background job systems, and took prioritization justice to EuRuKo 2025 and the updated “Fair by design: orchestrating background jobs in Ruby” to RubyConf 2026. Andrey wrote up the fair multi-tenant prioritization work that produced the gem. Their shared question is the one every multi-tenant platform eventually faces: what happens when one greedy tenant monopolizes your queues while everyone else silently waits?

Gusto knows that question well. In his Rocky Mountain Ruby talk, Phillip Campbell walks through SLA breach after SLA breach traced back to a noisy neighbor, and through the auto-rerouter they built to move a job that’s eating too much of a queue. It works. It’s also, in his telling, unfriendly: nobody likes waking up to find their job has been moved, and they’re thinking about reworking the whole mechanism.

None of this is theory. Artur Petrov works inside Factorial, the AI-first workforce operations platform valued at $2.5B, optimizing a large Ruby monolith and preparing its database for global scale. HR-tech monoliths with heavy background processing are his day job.

Background jobs are the heart of the business

Background jobs get none of the visibility and all of the responsibility. The UI is the face of the product; the job queue is where the product actually happens. Payroll runs, money is paid out, documents are analyzed, compliance checks fire.

And this only grows with AI. Every new agent integration, automated workflow, and LLM-powered feature means more work in the queue. When Gusto lets a business owner run payroll from Claude or Slack, that natural-language request still ends up as jobs in the background infrastructure. Gusto Cofounder is that future already shipping: an always-on agent that flags payroll deviations, schedules reminders, and generates reports over SMS and Slack, with no login required. Eddie Kim wants to “automate most of the business processes that small businesses have”, which is a statement about how much work is heading for the queue.

Phillip named the same pattern from that stage. The combination that bends a latency queue is sudden high volume, high compute time, and a job that’s sensitive to latency, all at once. “That trifecta,” he said, “is happening a lot in the AI era.”

This is true well below Gusto’s scale. For an AI startup on Rails, the background job pipeline is often the product: documents get parsed, agents run, results arrive, all asynchronously, all in the queue.

The trouble is that a queue under strain doesn’t announce itself. One customer uploads a 10,000-page batch and every other tenant sits behind it. A flaky model provider turns retries into a storm that fills the queue with work you already did. An agent loop that used to fire once per request starts firing eight times, and nobody notices until the depth chart is a wall. Nothing is down. Everything is late, and when the job was someone’s payroll, late is broken.

Should you lower your hiring bar or stay unstaffed?

Whether you run Sidekiq for five hundred thousand customers or five hundred, the problem is the same: queue latency is invisible until it isn’t, and by then the backlog is measured in money.

And that puts every engineering leader in the same spot. You have a role open and work stacking up behind it. Lower the bar to fill the seat now, and you carry that hire, and the risk that comes with them, for years. Hold out for the great one, and the work waits while you stay unstaffed.

Do the math on the second option before you pick it. A senior Rails infrastructure hire takes four to six months to find and another three to ramp into a codebase of any size. That’s most of a year before anyone touches your queues. A bad hire costs you the same year, plus the cleanup.

Hiring a team that’s already among the best in the world at the thing you need takes the trade off the table. The rate is higher than a headcount line for a while. In exchange, the work moves at the standard you were holding out for, done by people who have already spent years on exactly that problem, and your bar stays where it belongs for the permanent hire.

Inside Gusto’s Sidekiq infrastructure

From February to July 2026, Andrey Novikov (known in the Ruby world as Envek) embedded directly in Gusto’s platform team.

Andrey worked inside Gusto’s own workflow, sometimes putting out fires, taking on some gnarly problems, and clearing the path for the team to hit their goals.

Early on, that also meant fixing bugs upstream, in the open source libraries Gusto depends on, rather than working around them. That’s the default mode for Evil Martians. When the fix belongs in the ecosystem, it goes to the ecosystem.

The whole engagement ran fully async across time zones. Work was picked up, shipped, and handed back without anyone needing to coordinate around a shared clock.

What Gusto’s Sidekiq setup actually looks like

Phillip has put the shape of it on a conference stage. At Rocky Mountain Ruby 2025 he gave the numbers: around 170 million Sidekiq jobs a day, peaking near 270 million, running across about a thousand workers on a single Redis. A dedicated background jobs team carries the pager 24/7, because of the industry they’re in. A slight blip can mean a missed banking deadline.

Two things from that talk stay with me. The first is what actually limits the system. It’s not Redis memory or worker CPU, it’s the primary database, with Redis CPU waiting behind it: single-threaded, already at the fastest clock AWS rents, so the whole company runs on one thread. The second is arithmetic. At that volume, something that goes wrong for 0.01% of jobs goes wrong thousands of times a day.

Gusto has a ton of tooling set on top of Sidekiq Enterprise: a whole bunch of new pages in the Sidekiq UI to run manual tasks, manage the dead set, re-run whole job classes after fixes. In the application code there are dozens of custom RuboCop rules, extensive Sorbet type coverage, background jobs grouped by team for both monitoring and error tracking, and many more.

---

Upgrading Sidekiq and turning on strict arguments

I’ve done several code migrations inside Gusto: upgrading Sidekiq versions, enabling strict arguments, fixing bugs and ensuring compatibility in custom tooling, hardening RuboCop rules and agent skills along the way. This work has revealed a couple of subtle bugs long hidden in the codebase, and a couple of new insights into JSON handling in Ruby and Rails. I’m glad that some of the work was open sourced, like Sidekiq/PerformAsyncStub RuboCop rule.

---

What a Rails monolith this size feels like from the inside

Working inside Gusto changed how we think about big Rails, too. The magnitude is something else: the speed, the organization, the way packs and code owners let 600+ engineers move in one codebase without stepping on each other.

Packs in practice

Rails packs pay off in an organization this size: I always knew what team to mention or ask for review for every change I made. Given the size of the company and the complexity of the codebase, this is a huge win.

---

Gusto’s own engineering blog shows what that structure buys in the agent era. A recent large-scale OpenStruct refactor was decomposed along team ownership boundaries and executed by Claude Code agents in parallel, compressing months of work into weeks. Clean ownership boundaries keep a monolith this size navigable, for humans and agents alike.

AI-assisted onboarding, review, and monitoring

I was really impressed by the scale and the sanity of AI usage at Gusto: everything from onboarding new engineers to reviewing code to monitoring production is assisted by AI. Getting set up took very little human intervention, and once I was in, a change of mine could go from pull request to production the same day.

---

Instead of a conclusion

Phillip Campbell leads two developer productivity teams at Gusto, one on Ruby, Rails, and tooling, the other on background job processing, and he is the one who hired Evil Martians:

In a time of rapid change and acceleration, it was amazing to see Andrey able to step in and create value so quickly.

---

Running Sidekiq at scale, or watching your background jobs become the busiest part of your product? Evil Martians built sidekiq-fairplay and sidekiq-fair_tenant. We work inside some of the largest Rails monoliths in the industry, from Gusto’s payroll infrastructure to Whop’s zero-downtime PostgreSQL-to-PlanetScale migration. Talk to us.