From Quay to Authzed: How Three Acquisitions Taught Jacob Moshenko What Infrastructure Companies Actually Need

From Quay to Authzed: How Three Acquisitions Taught Jacob Moshenko What Infrastructure Companies Actually Need

The best startup ideas don’t come from market research. They come from watching the same expensive mistake happen over and over again until you can’t ignore it anymore.

In a recent episode of Category Visionaries, Jacob Moshenko, CEO and Co-founder of Authzed, shared how his path through multiple acquisitions—Quay to CoreOS to Red Hat—gave him a unique vantage point to observe a pattern that most founders never see. Engineering teams across dozens of companies were wasting months rebuilding the same infrastructure component, making the same architectural mistakes, and facing the same painful rework cycles.

That pattern became Authzed. But the insight didn’t come quickly, and it didn’t come easy.

The Quay Foundation: Learning Infrastructure Economics

Jake’s infrastructure education began at Quay, the container registry company he co-founded. Container registries solved a fundamental problem in the emerging Docker ecosystem: developers needed a secure, reliable place to store and distribute container images. Quay built that solution and found product-market fit in the early wave of containerization.

The Quay experience taught Jake his first critical lessons about infrastructure businesses. Unlike SaaS applications where users tolerate feature limitations or occasional downtime, infrastructure software operates under different rules. When a container registry goes down, entire deployment pipelines stop. When authorization systems fail, applications break. Infrastructure products require a level of reliability and depth that consumer-facing software doesn’t.

Quay was eventually acquired by CoreOS, which was itself acquired by Red Hat. For most founders, this double acquisition would mark the end of a chapter. For Jake, it marked the beginning of a pattern recognition exercise that would define his next company.

Inside Red Hat: The Observatory View

Working inside Red Hat’s OpenShift organization gave Jake something rare: visibility into how dozens of sophisticated engineering teams approached infrastructure problems. OpenShift, Red Hat’s Kubernetes platform, served enterprise customers across industries. Each customer had unique requirements, but Jake started noticing a troubling pattern.

“I started to realize that there was this massive opportunity to build the authorization system that was always the second or third thing that every engineering organization I was working with would build,” Jake explained. This wasn’t just one company or one industry. It was systematic.

Every engineering organization followed roughly the same path. They’d launch their product with basic authorization—often just role-based access control hardcoded into the application. As the product grew, requirements evolved. Users needed more granular permissions. Teams needed delegation capabilities. Compliance demanded audit trails. The initial authorization system, built for simpler times, couldn’t accommodate these demands.

So they rebuilt it. And that’s when Jake noticed the real pattern.

The 3-4 Year Rebuild Cycle

The tragedy wasn’t that companies built authorization systems from scratch. The tragedy was what happened next. “They would build the thing, and then about three or four years later, they would realize they needed to rebuild it again because they made some assumptions that weren’t true,” Jake noted.

This cycle repeated with shocking consistency. A company would invest three to six months of engineering time building a new authorization system. It would work well initially. Then business requirements would shift. Maybe they moved from B2C to B2B and needed organizational hierarchies. Maybe they expanded internationally and needed regional data isolation. Maybe they added new products and needed cross-product permissions.

The assumptions baked into their second authorization system would prove just as limiting as the first. Three or four years later, they’d be planning rebuild number three. And the engineers who built version two had often left for other companies, taking institutional knowledge with them.

Jake watched this pattern destroy value in sophisticated ways. The obvious cost was engineering time—talented developers spending months rebuilding infrastructure instead of building features. But the hidden costs were worse. During the rebuild, the existing system calcified. Teams hesitated to add new features or change behaviors because they knew a rewrite was coming. Product development slowed exactly when companies needed to move fast.

The False Solutions

Jake also observed various failed attempts to break this cycle. Some companies tried buying authorization as a module within larger identity management platforms. These solutions worked for simple use cases but broke down when companies needed custom logic or tight integration with application code.

Others tried abstracting their authorization logic into internal services, hoping that centralization would solve the rebuild problem. But without proper modeling of resources and permissions, these internal services just became more complex versions of the original hardcoded logic. The abstraction added operational overhead without solving the fundamental architectural problems.

The pattern clarified what was missing: a proper authorization system needed to model relationships between resources, users, and permissions in a way that could evolve as business requirements changed. It needed to handle the complexity that killed previous iterations while remaining performant enough for production use.

The Zanzibar Moment

The final piece of Jake’s insight came from Google’s Zanzibar paper. Google had faced these same authorization challenges at massive scale and built a system that could handle billions of permission checks per second while maintaining flexibility for evolving requirements. The paper outlined an elegant solution: model authorization as a graph of relationships, use a specialized language for defining permissions, and separate the authorization logic from application code.

Jake recognized that what Google had built for their internal use case could solve the problem he’d watched plague dozens of companies. But Google wasn’t going to open-source Zanzibar or offer it as a service. The opportunity was clear: build a Zanzibar-inspired system that any company could adopt.

This wasn’t about copying Google. It was about taking the principles that solved authorization at massive scale and making them accessible to companies that couldn’t invest years building their own systems. Jake understood from his OpenShift experience that engineering teams would embrace this approach—if it was truly production-ready and didn’t require them to trust a black box.

From Observation to Authzed

The insight that became Authzed synthesized everything Jake had learned. The rebuild cycle revealed the market need. The failed solutions showed what didn’t work. The Zanzibar paper provided the architectural approach. And his experience with infrastructure economics at Quay taught him how to build a business model around it.

But knowing what to build is different from knowing how to bring it to market. Jake’s Red Hat experience informed this too. He’d watched how enterprises evaluated and adopted infrastructure. They needed to trust it deeply, test it thoroughly, and validate it in their own environments before committing. Traditional sales approaches—demos, trials, aggressive follow-up—didn’t match how infrastructure buyers actually made decisions.

This insight led to Authzed’s open-source strategy. SpiceDB, their Zanzibar-inspired authorization system, would be fully open source and production-ready. Companies could download it, test it against their use cases, and even run it in production without ever talking to Authzed. The commercial offering would provide managed hosting and enterprise support—valuable for companies that didn’t want operational overhead, but not required for companies that did.

The Pattern Recognition Advantage

What made Authzed possible wasn’t just technical skill or market timing. It was pattern recognition across multiple contexts that most founders never experience. Jake didn’t just work at one infrastructure company—he worked through three acquisitions, observing engineering practices across dozens of enterprises.

This macro view revealed the authorization rebuild cycle not as isolated incidents but as a systematic problem. Individual engineering teams thought they were facing unique challenges. Jake saw they were all facing the same challenge with slight variations. That insight made it possible to build a general solution rather than a point solution.

“The people who really benefit most from our product are people who have already been burned once or twice trying to build something in house,” Jake noted. His pattern recognition let him identify these burned teams immediately and speak their language. He’d watched them go through the pain. He understood exactly what they needed because he’d seen it fail repeatedly.

Building Once for Everyone

The journey from Quay through acquisitions to Authzed spans nearly a decade of infrastructure experience. Jake’s insight wasn’t instant—it accumulated through years of observation, conversation, and pattern matching. But once the pattern became clear, the opportunity was obvious.

Every company was rebuilding authorization systems every three to four years, wasting engineering resources and slowing product development. Jake built it once, properly, and made it available to everyone. That’s Authzed. The companies that recognize the pattern—usually because they’ve lived through it—become customers. The ones that haven’t been burned yet will discover the pattern eventually.

Jake’s just hoping they find Authzed before they start rebuild number three.