Why Authzed Targets Burned Engineers Instead of Greenfield Customers

Why Authzed Targets Burned Engineers Instead of Greenfield Customers

Most SaaS companies chase anyone who might buy. Jacob Moshenko runs from customers who haven’t failed yet.

In a recent episode of Category Visionaries, Jacob Moshenko, CEO and Co-founder of Authzed, articulated one of the most counterintuitive ICP strategies in B2B: his ideal customers have already wasted hundreds of thousands of dollars building the wrong solution. Twice. They’ve burned engineering quarters on systems that eventually collapsed. They’ve experienced the pain of rebuilding critical infrastructure while the business waited. And that prior failure makes them perfect buyers.

“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 explained. This wasn’t market positioning or sales qualification criteria. It was a fundamental recognition that authorization is a problem you can’t understand until you’ve failed to solve it.

The Problem with Greenfield

Most infrastructure startups optimize for greenfield opportunities. New companies building new products represent the largest addressable market and the easiest sales motion. They haven’t built competing internal systems. They don’t have technical debt. They’re open to adopting vendor solutions because they don’t have the resources or time to build everything themselves.

Jake recognized that this logic breaks down for authorization specifically. A startup building their first product approaches authorization with dangerous naivety. They implement simple role-based access control—admin, user, maybe a few other roles—and think they’ve solved permissions. The solution works fine initially because their authorization needs are genuinely simple.

Selling to these greenfield customers requires convincing them they have a problem they don’t yet experience. They’ll ask reasonable questions: Why do we need a specialized authorization system when roles work fine? Why should we adopt external infrastructure for something we can build in a week? Why pay for a solution to a problem we don’t have?

Jake’s answer to these questions is brutally honest: you probably shouldn’t buy Authzed yet. Come back after your homegrown system has failed you twice.

The Rebuild Recognition

Authzed’s ideal customer has lived through a specific pain cycle. They built their first authorization system quickly—probably just roles hardcoded into their application. As the product grew, that system became a constraint. They needed more granular permissions, organizational hierarchies, delegation capabilities, or resource-level controls. So they rebuilt it.

The second system was more sophisticated. They abstracted the authorization logic, maybe created an internal service, possibly even designed a domain-specific language for defining permissions. It solved the immediate problems and felt like a proper solution. Then business requirements shifted again.

“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 moment—realizing the second system also needs replacement—is when companies become qualified buyers.

The difference between first and second failure is profound. After the first rebuild, teams think they just got the architecture wrong. After the second rebuild, they recognize authorization as a fundamentally complex problem that requires specialized expertise. They stop viewing it as a simple engineering task and start viewing it as critical infrastructure they’d rather not own.

The Economics of Prior Investment

Here’s where Authzed’s ICP strategy gets interesting from an economic perspective. Companies that have rebuilt authorization twice have already invested heavily in solving the problem. A typical rebuild might consume three to six months of senior engineering time—call it $200,000 to $500,000 in fully loaded cost. Do that twice, and you’ve spent half a million to a million dollars on authorization infrastructure.

This prior investment doesn’t make companies worse prospects—it makes them better ones. They’ve already allocated budget to this problem space. They have executive buy-in that authorization is critical infrastructure worth investing in. And they’ve developed sophisticated internal understanding of what good authorization systems require.

When Jake tells these burned engineers that Authzed’s average contract value is around $50,000 annually, they don’t balk at the price. They’re comparing it to the millions they’ve spent building systems that eventually failed, not to zero. The ROI calculation is obvious: even a five-year Authzed contract costs less than one more rebuild, and it eliminates future rebuild cycles entirely.

The Trust Transfer

Prior failure creates another advantage: earned trust. Engineers who’ve built authorization systems twice understand the problem’s depth. They know about consistency challenges in distributed permission checks. They’ve debugged race conditions in permission propagation. They’ve struggled with performance at scale. They’ve discovered edge cases in hierarchical permissions that seem simple until you implement them.

When these engineers evaluate SpiceDB, they recognize sophistication immediately. The graph-based relationship model makes sense because they’ve experienced the limitations of simpler approaches. The specialized authorization language resonates because they’ve tried to express complex permissions in SQL or application code. The consistency guarantees matter because they’ve dealt with eventually consistent permission systems that created security holes.

Jake doesn’t need to explain why these features matter—burned engineers already know. The sales conversation focuses on implementation details and operational considerations, not problem education. This dramatically shortens sales cycles despite the product’s complexity.

The Product Complexity Paradox

Authzed’s ICP strategy explains why Jake refused to simplify his product despite pressure from advisors and investors. “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.

Simplifying SpiceDB to appeal to greenfield customers would have made it useless to burned engineers. The sophisticated features that seem like overkill to someone building their first authorization system are exactly what engineers who’ve rebuilt twice recognize as essential. The complexity isn’t a bug—it’s the primary signal that Authzed actually solves the hard problems.

This creates a filtering mechanism. Junior engineers or teams building their first authorization system download SpiceDB, find it complex, and move on. That’s fine—they weren’t going to buy anyway. Senior engineers who’ve rebuilt authorization multiple times download SpiceDB, recognize the architectural patterns, and immediately understand its value.

Jake acknowledged the trade-off: “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.” But that difficulty only affects unqualified prospects. Qualified prospects—the burned engineers—get it in five minutes.

The Churn Advantage

The most powerful validation of Authzed’s ICP strategy shows up in retention metrics. Jake noted: “The churn in the people we actually sell to is pretty much zero.”

This near-zero churn makes sense given who they sell to. Companies that have rebuilt authorization twice and then adopted Authzed aren’t casually evaluating options. They’ve tried building it themselves multiple times. They know exactly what they’re getting from Authzed and exactly what pain it eliminates. They’re not going to churn because they’re not going to rebuild authorization a third time.

Contrast this with the likely churn profile of greenfield customers. A startup that adopted Authzed before building their own system might later decide they could build something simpler. They never experienced the rebuild cycle, so they don’t viscerally understand what Authzed prevents. When budget gets tight, that $50,000 annual contract becomes a tempting cost to eliminate.

Burned engineers don’t think this way. They’ve already calculated the cost of building and maintaining authorization infrastructure. They know the $50,000 is cheap insurance against a problem that will definitely recur if they go back to homegrown solutions.

The Market Size Question

The obvious criticism of Authzed’s strategy is market size. If you only sell to companies that have rebuilt authorization twice, aren’t you dramatically limiting your addressable market? Jake’s answer is implicitly yes—and that’s fine.

The total addressable market for authorization includes every company with a software product. But the serviceable addressable market—companies that will actually adopt a sophisticated authorization system—is much smaller. It’s companies that have grown large enough to need complex permissions, experienced enough pain to prioritize fixing it, and sophisticated enough to evaluate solutions properly.

Trying to sell to the full TAM would require dumbing down the product, increasing marketing spend to reach unqualified prospects, and accepting high churn from customers who weren’t really good fits. Jake chose to optimize for a smaller market with perfect fit, zero churn, and natural expansion potential as companies grow into authorization complexity.

The Pattern Recognition Signal

What makes Authzed’s ICP strategy work is that burned engineers self-identify. Jake doesn’t need complex qualification frameworks or extensive discovery calls. When prospects reach out after downloading SpiceDB, a few questions reveal whether they’ve lived through the rebuild cycle.

Engineers who haven’t been burned talk about their current system’s limitations. Engineers who have been burned talk about their previous systems’ failures—plural. They mention the first rebuild, explain why it also failed, and express exhaustion at the thought of doing it again. That exhaustion is the buy signal.

The open-source model amplifies this self-selection. The engineers who invest time deeply evaluating SpiceDB are disproportionately the ones who’ve tried building authorization multiple times. Casual explorers might clone the repo and skim the docs. Burned engineers run it in staging, test it against their use cases, and validate it handles the edge cases that destroyed their previous implementations.

The Contrarian Comfort

Jake’s comfort with this narrow ICP reflects deeper strategic clarity. Rather than trying to serve everyone and convincing skeptical prospects they have a problem, Authzed focuses exclusively on the segment that already knows they need a solution. The strategy trades market breadth for product-market fit depth.

For technical founders building complex infrastructure, the lesson is permission to specialize aggressively. Not every prospect needs to be qualified. Sometimes the best ICP is defined not by company size or industry but by specific prior experience—even if that experience is failure.