Scalability
No shortcuts.

Before starting Superthread, I founded a mobile gaming company. Our biggest hit, Forces of Freedom, was a real-time 5v5 multiplayer game that reached over 50 million downloads. At its peak, it was handling 70,000 new downloads per day and supporting 10,000 concurrent players—without falling apart. To make that possible, we had to build our own networking stack from scratch. Off-the-shelf solutions just couldn’t deliver the performance we needed.
That experience permanently shaped how I think about software: performance and reliability aren’t nice-to-haves—they’re fundamental. But making something that always works—and works well no matter what you throw at it—is brutally hard. It takes deep architectural thinking, relentless trial and error, obsessive monitoring, and an uncompromising level of craftsmanship.
That same mindset is what drives Superthread. From day one, we’ve refused to release anything we wouldn’t personally want to use at scale. We don’t ship fluff, and we don’t believe in papering over technical debt with shiny features. We build for the long term—even when that means it takes longer. We could’ve launched Superthread earlier had we taken shortcuts, but we chose not to. Instead, we built the kind of foundation that can support teams with 10 records or 10 million—without slowing down, breaking down, or degrading over time.
We care—probably too much—about query times, render speeds, latency under load. We track weird edge cases most people wouldn’t even notice. And if something’s not fast enough or solid enough, we tear it down and rebuild it. Because that’s what it takes to make software that feels trustworthy and effortless.
Building something truly robust at scale isn’t fast or easy. But that’s the whole point. We’d rather take the time to do it right than ever ship something we’re not proud of.