Nate
Berkopec

Right now, Nate Berkopec is the person your Rails team calls when the response times start creeping up and your engineers are out of ideas. He runs Speedshop from Tokyo - a consultancy that does one thing, and does it extremely well: makes Ruby on Rails applications faster. Not marginally faster. Measurably, dramatically, defensibly faster.

He is also a co-maintainer of Puma, the Ruby web server that powers a significant portion of the Rails applications running in production today. He writes the Speedshop Newsletter every Monday - plaintext, no click-tracking, zero analytics surveillance - and has written the book on Rails performance, quite literally.

The world he operates in is a niche within a niche: performance optimization for a specific web framework. But it turns out that niche pays very well when you become the foremost authority in it. His 2016 course generated over $220,000 in its first year. The workshops have trained more than 500 developers. Dozens of companies have run their applications through Speedshop's retainer service.

He has a contrarian instinct that serves him well. When the broader tech community was declaring that Rails couldn't scale - around 2015 - Berkopec's response was not to agree or switch frameworks. He decided to find out. That decision defined the next decade of his career.

His approach to performance work is resolutely practical. "What is measured is managed" - that's the foundation. You cannot optimize what you cannot see. Before any tuning happens, Berkopec's method demands that you understand what you're actually dealing with: profiling, benchmarking, establishing baselines. The rest follows from evidence, not intuition.

He rejects the frame that performance optimization is at odds with good software design. His argument is that well-structured code tends to be faster code - that the apparent tradeoff between clarity and speed is often a symptom of poor measurement rather than an inherent tension. It's a position he argues not just in theory but through the results he delivers for clients.

Here is the version of Nate Berkopec's origin story that he tells with a kind of earned equanimity: at 19 years old, a kid from Eagan, Minnesota, he walked onto the set of ABC's Shark Tank in January 2010 with a clothing company called The Factionist, $3,000 in sales over six months, and an ask of $30,000 for 20% equity.

He didn't close a deal. Millions of people watched. And for nearly a decade, he says, that experience left a mark - the peculiar weight of a public failure broadcast into living rooms across America. Eventually, he found his way to a more useful frame: "I'm glad I failed."

What he got out of it, besides the psychological reps, was a year interning for Barbara Corcoran, who was impressed enough to bring him in. Fashion didn't stick. But the proximity to the startup world gave him a direction. A professor suggested that programming was the fastest path into tech. He completed Michael Hartl's Rails Tutorial - the same free resource that launched hundreds of careers - and became a developer.

From 2011 to 2015, he worked at startups, got good at Rails, and started noticing a pattern: applications slowing down, teams unsure what to do about it, and a lot of cargo-cult optimization happening in the absence of real measurement. The dominant narrative in those years was that Rails couldn't handle real scale. Berkopec found that narrative intellectually unsatisfying.

So he studied. Deeply. The kind of study that turns someone from a practitioner into an authority. By 2016, he had enough to write what would become The Complete Guide to Rails Performance - a 370-page reference manual that is still, in 2026, the standard text on the subject. In its first year, it generated $220,033.50 in revenue. He wrote a public retrospective about every dollar of it.

The transparency was characteristic. Berkopec has consistently chosen openness about his business - his methods, his numbers, his mistakes - over the mystique that consultants sometimes cultivate. It turns out that showing your work is a better marketing strategy than hiding it.

Being a co-maintainer of Puma is not a hobby. Puma is the production Ruby web server for a substantial portion of the Rails ecosystem. When it breaks or behaves unexpectedly, real applications suffer real consequences. The responsibility is not theoretical.

Berkopec took over co-maintenance in 2016 alongside Evan Phoenix (who created Puma) and Richard Schneeman. His approach to this role says something about how he thinks about work more broadly: he spends approximately 15 minutes per day on Puma maintenance. Not because he doesn't care, but because he has thought carefully about what sustainable stewardship actually looks like.

His philosophy toward competing projects - Falcon, Pitchfork, others that operate in Puma's space - is conspicuously non-combative. He views them as exploring different technical priorities rather than threats. In an ecosystem where maintainer burnout is endemic and fork wars are common, this is a considered stance, not a naive one.

He has also been public about recruiting new contributors to Puma - understanding that his own 15-minute model only works if others are available for the problems that exceed that scope. The goal is a healthy project that doesn't depend on any single person's heroic effort. His first open source contribution, years earlier, was a modest Rails fix for email formatting edge cases. The scale of responsibility has grown considerably since then.

Berkopec has built a significant education business alongside his consulting work. The curriculum covers the full stack of Rails performance concerns - from database queries to web server configuration to background job scaling.