Why Every SaaS Company Eventually Needs Cerbos (And How Alex Olivier Figured That Out)

Authorization might not be the sexiest problem in software development, but it’s one of the most critical—and most frustrating. Alex Olivier, co-founder and CPTO of Cerbos, spent years rebuilding the same permissions system at different companies before deciding to turn that pain into a product. Here’s how they built a policy-as-code platform that’s now powering thousands of deployments worldwide.

The Problem Nobody Wants to Solve (But Everyone Has To)

Let’s be honest: authorization is boring. It’s not the kind of problem that gets your blood pumping or makes for good dinner conversation. But it’s also the kind of problem that every single company building software for enterprise customers eventually runs into—and it’s the kind of problem that can absolutely tank your ability to land those customers.

Alex Olivier knows this intimately. Over the course of his career at companies like Comptable Cupid (an e-commerce analytics platform) and in the supply chain space, he found himself solving the same problem over and over again: how do you build a system that lets different users, roles, and organizational structures access different parts of your application in different ways?

At Comptable Cupid, customers ranged from Emirates Airlines to Staples to companies in Australia. Each one had a completely different organizational structure. Some organized by geography—you don’t want someone in the US accessing European campaign data. Others organized by department. Still others used a matrix structure. Every time, it meant rebuilding the entire permissions system from scratch.

“It always bugged me,” Alex says. “Every time we did it, I got annoyed about how long we spent trying to solve this problem.”

The Aha Moment: This Shouldn’t Be This Hard

By the time Alex had solved this problem three times at three different companies, he realized something: this was a massive blocker for enterprise adoption of any product. If you’re building a SaaS tool that wants to serve enterprise customers, you have to solve authorization. But there wasn’t really a product-level solution out there—just low-level infrastructure tools like policy engines that were way too complicated for most teams to use effectively.

That’s when Alex connected with his two co-founders: the CTO from his first company and a former tech lead. The three of them had worked together for over a decade, and they all recognized the same pattern. In 2020, during the COVID era, they decided to do something about it.

They raised funding and started building what would become Cerbos.

Starting with Open Source: A Smart Move

Here’s where Cerbos made a brilliant strategic decision: they didn’t start by building a commercial product. They started by building an open source core.

This wasn’t just altruism. It was strategy. Alex and the team knew that the biggest hurdle they’d have to clear wasn’t going to be business adoption—it was going to be technical adoption. Authorization logic gets wired deeply into your codebase. Every part of your application that checks permissions needs to interact with this system. It has to be performant, it has to integrate cleanly, it has to be observable. Before you can even think about talking to security teams or CSOs, you need developers and architects to actually want to use your product.

So they built a policy engine as an open source project under an Apache 2 license and released it on GitHub. And it took off.

The Smart Abstraction Layer

Here’s the technical insight that made Cerbos different: they didn’t just wrap existing policy engines (like Open Policy Agent). Instead, they built a simpler, more intuitive way to define policies.

The existing tools out there used complex policy languages like Rego. Powerful? Sure. But way too complicated if you ever wanted product managers or security teams to actually write policies.

So Cerbos built an abstraction layer. Under the hood, they still used OPA, but on top of it, they created a much simpler manifest-driven approach using YAML and Common Expression Language. This meant they could iterate quickly on what actually matters for business requirements while still leveraging battle-tested policy engines underneath.

They landed on the concept of “resource policies”—defining policies around the resources that users are trying to interact with—and then layered on additional concepts to make it easier to build repeatable logic and conditions. It was testable. It was versionable. It worked.

Within six to twelve months of launching the company, they had large enterprises adopting their open source core.

From Open Source to Product: Listening to Users

After about two years of just the core engine out there in the wild, something interesting happened: patterns emerged.

Companies were using Cerbos’s core engine, but they were all building the same extra infrastructure around it. How do you distribute policies when you have hundreds of thousands of decision points running across your architecture? How do you get a single pane of glass to see all authorization decisions? How do you ensure that when a policy changes, you don’t have to manually set up complex CI pipelines to test everything?

This is where Alex and his team made another smart move: they listened. They had community Slack channels. They gathered feedback from real-world deployments. And they pattern-matched on the problems they heard most frequently.

The roadmap essentially wrote itself. The next logical step was building a control plane—an administration layer for all those distributed decision engines. That became their first commercial product, and it became the foundation for the business.

Building a Global, Senior-Heavy Team

Cerbos is a remote-first company from day one. Registered in the UK but with no office, they made an early decision to hire predominantly senior roles. Why? Because when you’re distributed and can’t hand-hold people as easily, you need people who can operate independently and bring deep expertise.

They were also heavy on the engineering side early on, deliberately avoiding hiring marketing or sales roles initially. The bet was that a great product would speak for itself—and in the open source world, it did.

The Lesson Here

What’s fascinating about Cerbos’s story is how they turned a painful, repetitive problem into a business by:

1. Starting with open source to build trust and get real-world feedback
2. Creating a better abstraction than what existed, making complex problems simpler
3. Listening to users to understand what infrastructure problems they were actually solving
4. Building the next layer of the product based on real patterns they observed

It’s a masterclass in how to build infrastructure software in the modern era. You don’t start with a grand vision of a complete platform. You start with the core problem, you solve it better than anyone else, you get it into people’s hands, and then you let your users tell you what comes next.

Want to hear the full story of how Alex Olivier and the Cerbos team built their authorization platform? Listen to the full episode with Alex on Code Story. Dive deeper into their engineering decisions, their go-to-market strategy, and how they’re thinking about the future of authorization as AI agents start accessing systems autonomously.