Authzed’s 3-4 Year Trap: Solving the Authorization Problem Companies Rebuild Forever

The best business opportunities hide in patterns most people think are normal.

In a recent episode of Category Visionaries, Jacob Moshenko, CEO and Co-founder of Authzed, explained how he built a company around a pattern that engineering teams had accepted as inevitable: the authorization rebuild cycle. “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 observed. This wasn’t happening to bad engineering teams or poorly run companies. It was happening to everyone.

The cyclical waste represented billions of dollars in redundant engineering work across the software industry. More importantly, it represented a category-defining opportunity for whoever could break the cycle permanently.

The Pattern Nobody Questioned

Most engineering teams experience the authorization rebuild cycle as a unique failure. They build their first permissions system with what seems like reasonable assumptions. It works fine initially. Then business requirements evolve, and the system can’t adapt. So they rebuild it, more sophisticated this time, convinced they’ve finally got it right.

Three or four years later, they’re planning rebuild number three.

Individual teams think they made architecture mistakes or didn’t anticipate scale correctly. They don’t realize they’re experiencing a predictable pattern that affects nearly every growing software company. Jake saw this pattern because his vantage point—working through multiple acquisitions at Quay, CoreOS, and Red Hat—let him observe dozens of engineering organizations simultaneously.

“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. The pattern wasn’t about individual team failures. It was about authorization being fundamentally harder than teams initially understood.

Why Authorization Systems Fail on Schedule

The three-to-four-year cycle isn’t arbitrary. It reflects the natural evolution of growing software companies. In year one, a startup builds an MVP with simple authorization—probably just admin and user roles. This works perfectly because their authorization needs genuinely are simple.

By year two or three, the product has real customers with complex needs. Sales teams want to sell to enterprises that require organizational hierarchies, delegation capabilities, and fine-grained resource permissions. The simple role-based system becomes a constraint. So the engineering team rebuilds, creating something more sophisticated—maybe a custom policy engine, maybe an internal authorization service with a domain-specific language.

The second system feels like a proper solution. It handles the current complexity and seems flexible enough for future growth. But business evolution continues accelerating. The company expands into new markets with different regulatory requirements. They add new products that need different permission models. They grow large enough that performance at scale becomes critical. They acquire other companies with different authorization patterns that need integration.

The assumptions baked into system two—the same assumptions that made it better than system one—prove limiting. Maybe they assumed all resources live in a single database. Maybe they designed for thousands of users, not millions. Maybe they optimized for consistency over performance, or vice versa. Whatever the assumptions, they break.

Three to four years after the second build, the team is planning rebuild number three. And the engineers who built version two have likely moved to other companies, taking their hard-won knowledge with them.

The Hidden Costs

The direct cost of each rebuild is substantial. A typical authorization system rebuild consumes three to six months of senior engineering time. With fully loaded costs, that’s easily $200,000 to $500,000 per rebuild. Companies that have rebuilt twice have already spent half a million to a million dollars on authorization infrastructure.

But the direct cost understates the real damage. During the months spent rebuilding, those senior engineers aren’t building product features that differentiate the business. They’re not improving performance or reliability of revenue-generating systems. They’re rebuilding infrastructure that already existed because the previous version can’t evolve.

The opportunity cost extends further. Once a team commits to rebuilding authorization, they typically freeze changes to the existing system. Adding new permission types or changing authorization logic in a system slated for replacement creates technical debt that complicates migration. So product teams learn to work around authorization limitations rather than fixing them, accumulating workarounds that eventually need cleanup.

The knowledge loss amplifies these costs. Authorization systems are complex, with subtle edge cases and performance considerations that aren’t obvious from the code. The engineers who built version two understood why certain architectural decisions were made and what trade-offs they represented. When those engineers leave, the next generation inherits a codebase without context, making the third rebuild harder than the second.

Why Companies Keep Rebuilding

If the cycle is so expensive, why do companies keep choosing to rebuild rather than adopt existing solutions? Jake’s answer reveals something fundamental about infrastructure decision-making: teams don’t realize they’re in a cycle until they’ve been burned multiple times.

After the first rebuild, engineering teams think they just got the architecture wrong initially. The second system feels fundamentally better, properly engineered, built with lessons learned. They don’t anticipate needing a third rebuild because they don’t yet understand that authorization requirements evolve faster than any point-in-time architecture can accommodate.

Only after the second rebuild—when teams realize even their sophisticated second system can’t adapt to new requirements—do they start questioning whether building authorization in-house makes sense. “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.

This creates a market timing problem. The companies that would benefit most from adopting Authzed are the ones who’ve already invested heavily in homegrown solutions. They’ve sunk costs into systems that need replacement. Switching to Authzed means abandoning that investment and admitting that massive engineering effort was wasted.

But this sunk cost also makes them better buyers. They’ve already allocated budget to authorization infrastructure. They have executive buy-in that permissions are critical enough to invest in. And they viscerally understand the cost of getting it wrong. When Jake tells these teams that Authzed’s average contract value is around $50,000 annually, they’re comparing it to the million-plus they’ve already spent, not to zero.

Breaking the Cycle

Authzed’s entire business model is built around breaking this cycle. SpiceDB, their open-source authorization system, was designed to accommodate evolving requirements without architectural rewrites. The graph-based relationship model can represent virtually any permission structure. The authorization language lets teams define new permission types without changing code. The separation of authorization logic from application code means changes don’t ripple through the entire codebase.

These architectural decisions weren’t arbitrary—they directly addressed the reasons previous authorization systems failed. Jake understood that the cycle continued because homegrown systems optimized for today’s requirements, not tomorrow’s. Building a system flexible enough to evolve required accepting more upfront complexity in exchange for long-term adaptability.

This explains why Jake refused to simplify SpiceDB despite pressure from advisors. “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. The complexity wasn’t accidental or excessive—it was essential to building a system that could finally break the rebuild cycle.

Engineers who’ve only built authorization once don’t appreciate this trade-off. The upfront complexity seems like over-engineering. But engineers who’ve rebuilt twice immediately recognize why the complexity matters. They’ve experienced the pain of systems that seemed simple initially but couldn’t evolve. They’ll gladly accept upfront complexity if it means never rebuilding again.

The Category Play

Jake’s insight extended beyond just solving authorization for individual companies. He recognized that the rebuild cycle represented a category-level problem requiring a category-level solution. Authorization needed to evolve similarly to authentication—from something every company built themselves to something everyone adopted as standard infrastructure.

Two decades ago, every company built custom authentication systems. Today, most use OAuth and standardized identity providers. The transition happened because authentication is hard to build correctly, and the consequences of getting it wrong are severe. Companies eventually recognized that authentication was undifferentiated infrastructure not worth maintaining in-house.

Authorization is following the same path, just slower. “We built a language called the authorization language that other people are trying to adopt, even if they’re not using our product,” Jake explained. By establishing standards and patterns that extend beyond Authzed’s specific implementation, he’s helping create the category conditions where adopting external authorization systems becomes normal.

This ecosystem play represents patient, long-term thinking. Not every company using authorization concepts Authzed pioneered will become a customer. But every company that adopts those concepts validates that authorization is solvable infrastructure, not a custom problem each company needs to build themselves. As more companies adopt this view, the market for authorization-as-a-service expands.

The ROI Calculation

For companies stuck in the rebuild cycle, the ROI calculation for adopting Authzed is straightforward. A five-year contract at $50,000 annually costs $250,000. A single authorization system rebuild costs $200,000 to $500,000 in engineering time. Companies that have rebuilt twice have already spent more on homegrown solutions than they’d spend on a decade of Authzed.

But the calculation extends beyond direct costs. Authzed eliminates the opportunity cost of senior engineers spending months on infrastructure instead of features. It eliminates the risk that authorization limitations block product development. It provides access to a team that’s spent years solving authorization edge cases rather than learning them the hard way.

Most importantly, it breaks the cycle. Companies adopting Authzed aren’t just avoiding rebuild number three—they’re eliminating rebuild number four, five, and beyond. The cumulative savings over a company’s lifetime dwarf the contract cost.

The Pattern Recognition Lesson

Authzed’s success demonstrates a broader principle for technical founders: the best business opportunities often hide in patterns that seem normal. Every company rebuilds authorization systems. Every company accepts this as part of scaling infrastructure. Nobody questions whether the pattern itself is the problem.

Jake questioned it. His unique vantage point across multiple organizations let him see the pattern as systemic rather than random. Once he recognized the cycle, the opportunity became obvious: build authorization infrastructure so flexible it never needs rebuilding, then make it available to every company trapped in the cycle.

The companies trapped in the three-to-four-year rebuild cycle represent Authzed’s entire addressable market. They’re the ones who understand the problem deeply because they’ve lived it. They’re the ones willing to pay for a solution because they’ve already paid more trying to solve it themselves. And they’re the ones who’ll never churn because going back to homegrown authorization means restarting the cycle they just escaped.

Jake built a business model around breaking a cycle most companies thought was inevitable. That’s how pattern recognition becomes category creation.