The Story of Authzed: Building the Authorization Layer Every Company Needs But No One Wants to Build

The Story of Authzed: Building the Authorization Layer Every Company Needs But No One Wants to Build

Some startup ideas come from market research. Others come from watching the same problem destroy engineering teams over and over again.

In a recent episode of Category Visionaries, Jacob Moshenko, CEO and Co-founder of Authzed, shared the origin story of a company born from pattern recognition across multiple acquisitions and engineering organizations. What started as an observation at Red Hat became a mission to solve one of infrastructure’s most persistently painful problems: authorization.

The Quay Years: Learning Infrastructure the Hard Way

Jake’s path to Authzed began at Quay, a container registry company he co-founded. The journey through acquisition taught him lessons that would shape everything about Authzed’s approach to market. Quay was acquired by CoreOS, which was then acquired by Red Hat, eventually becoming part of the OpenShift ecosystem.

Working inside Red Hat’s OpenShift organization gave Jake a unique vantage point. He wasn’t just building one authorization system—he was observing how dozens of enterprise engineering teams approached the same infrastructure challenge. The pattern was impossible to ignore.

“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. But observation alone wasn’t enough to justify starting a company. What convinced him was what happened after teams built their first authorization system.

The Rebuild Cycle

Every company followed the same tragic arc. They’d build an authorization system to solve their immediate needs. It would work well enough initially. Then, inevitably, assumptions would break. “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 wasn’t a problem affecting inexperienced teams. These were sophisticated engineering organizations with talented developers. The issue was fundamental: authorization is deceptively complex, and the requirements evolve faster than most systems can accommodate.

Jake saw teams burning months of engineering time on their second or third rebuild while knowing they’d eventually need a fourth. The waste wasn’t just monetary—it was opportunity cost. Every hour spent rebuilding permissions infrastructure was an hour not spent building product features that differentiated the business.

From Observation to Opportunity

The insight crystallized: if every company was rebuilding the same infrastructure component multiple times, there was an opportunity to build it once, correctly, and make it available to everyone. But Jake understood that building the product was only half the challenge. The go-to-market motion would determine whether Authzed succeeded or became another failed infrastructure startup.

The decision to build SpiceDB as open source wasn’t idealistic—it was pragmatic. Jake knew that authorization systems require deep integration into critical application infrastructure. No engineering team would adopt a closed-source, black-box solution for something this foundational. “We have something like 4500 stars on GitHub now for our main open source product, SpiceDB,” Jake shared, reflecting on the growth of their open-source community.

But open source solved another problem: qualification. By making SpiceDB freely available, Authzed created a natural evaluation process. Engineers could download it, experiment with it, and validate it in their own environments before ever talking to sales. This aligned perfectly with how sophisticated technical buyers wanted to evaluate infrastructure tools.

Choosing the Harder Path

Early in Authzed’s journey, Jake faced pressure to simplify. Investors, advisors, and conventional wisdom all suggested making the product easier to understand and the sales pitch simpler to deliver. Jake refused.

“I actually fundamentally disagree with that advice for what we’re building. The problem that we’re solving is one of the hardest problems in infrastructure,” he explained. This wasn’t stubbornness—it was strategic clarity about who Authzed served.

The decision had real consequences. “It’s actually very, very difficult for us to get someone new into a call and have them understand what we do and why it’s valuable in 30 minutes or less,” Jake admitted. Sales cycles were longer. Conversion rates on cold outreach were abysmal. But the customers who did convert stayed forever.

Jake identified their ideal customer profile with precision: “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.” These weren’t customers who needed convincing about the problem—they needed confidence in the solution.

The Anti-Outbound Philosophy

While competitors built SDR teams and scaled outbound engines, Authzed went in the opposite direction. “We don’t do any outbound whatsoever. We’ve tried it a couple of times and it really doesn’t work for us at all,” Jake explained.

This wasn’t a resource constraint or a temporary strategy. It was a fundamental recognition that their market didn’t respond to traditional enterprise sales tactics. Developers hate being sold to. They especially hate being sold to about complex infrastructure decisions by salespeople who don’t understand the technical nuances.

Instead, Authzed invested in content, conference talks, and community building. They optimized for showing up in search results when engineers were actively researching authorization solutions. “If you search for Google Zanzibar, which is the paper that kind of kicked all this stuff off, there’s a good chance that we’re on the first page of that,” Jake noted.

The approach required patience, but it worked. By the time prospects reached out to Authzed, they’d already invested hours understanding the problem space, evaluating alternatives, and testing SpiceDB. The sales conversation focused on commercial terms and implementation support rather than convincing buyers the problem existed.

Scaling Without Compromising

As Authzed grew to approximately 25 enterprise customers with an average contract value around $50,000, they faced new scaling challenges. The product-led growth motion that worked early couldn’t be the only motion forever. Enterprise customers required different engagement models.

“It’s been very painful to try to figure out what does that look like to bring on more of the sales assist type motion, especially when we haven’t historically had one,” Jake shared candidly. The company brought on experienced enterprise salespeople, but the cultural integration was challenging. “We are all engineers. Nobody on the team actually has done this before.”

The key was timing. Authzed waited until they had proven patterns and repeatable success before hiring traditional sales talent. This foundation made it possible to transfer knowledge and scale the motion without losing what made their approach effective.

Jake noted their retention metrics reflected the quality of their customer fit: “The churn in the people we actually sell to is pretty much zero.” When customers spent months evaluating before purchasing, they didn’t leave after a few quarters.

Building the Category, Not Just the Company

Jake’s ambition extended beyond Authzed’s direct commercial success. “We built a language called the authorization language that other people are trying to adopt, even if they’re not using our product,” he explained.

This ecosystem play represented long-term strategic thinking. By establishing standards in authorization, Authzed positioned itself as a category leader regardless of specific product adoption. If their concepts became industry best practices, it created natural gravitational pull toward their implementation.

The Path Ahead

Looking forward, Jake outlined a measured growth trajectory. “I think by the end of this year, we’ll get to about thirty people total,” he shared, describing an approach focused on sustainable scaling rather than explosive headcount growth.

The vision was to continue expanding within their core market of sophisticated engineering organizations while deepening their product capabilities. Each new customer validated the thesis that companies would rather adopt a proven authorization system than rebuild their own for the fourth time.

Jake’s bet was that authorization would follow the same path as authentication. Two decades ago, every company built custom authentication systems. Today, most use OAuth and standardized identity providers. Authorization is following the same trajectory—it’s just a harder problem that’s taking longer to standardize.

Authzed’s story demonstrates that contrarian bets can work when they’re grounded in deep domain expertise and clear-eyed assessment of market dynamics. By refusing to compromise on product complexity, avoiding traditional outbound sales, and building for the long term, Jake created a company that solves a problem every engineering organization faces but none want to solve themselves.