The evolution of Cerbos' pricing model

Alex discussed the evolution of Cerbos' pricing framework, emphasizing the transition from an open-source project to a commercial product. He highlighted the importance of choosing a pricing metric that resonates with both the company and its customers. Cerbos opted for a model based on "monthly active principles," a more encompassing metric than just active users, which accounts for all unique identities interacting with the system, be they human or machine.

Addressing market needs through open core strategy

Cerbos operates on an open core business model, which offers core functionalities for free while charging for advanced features. Alex detailed how Cerbos initially open-sourced its authorization solution, providing basic services without charge, and how customer feedback led to the development of enhanced, paid features designed to support large-scale, enterprise needs such as audit logs and enhanced security.

Customer-centric approach to product development

A significant portion of the podcast was dedicated to how Cerbos listens to its customers to shape its offerings. Alex shared anecdotes about discussions with enterprise users that directly influenced the additional features in the commercial layer of Cerbos. This approach not only aligns product development with actual market demands but also ensures that Cerbos remains a customer-first company.

The challenges of pricing in the open source ecosystem

Alex discussed the intrinsic challenges of pricing within the open-source ecosystem, where perceptions about cost versus value can significantly vary. He revealed how Cerbos navigated these challenges by focusing on value provision rather than just cost recuperation, aiming to make the pricing predictable and transparent to eliminate customer surprises and hesitance.

Conclusion

The podcast episode with Alex Olivier offers invaluable insights into the strategic thinking behind Cerbos' approach to open source and commercial product development. For anyone involved in SaaS, open-source projects, or product management, this discussion sheds light on balancing community-driven products with commercial viability.

To learn about how Cerbos empowers developers to implement, manage, and delegate fine-grained access control in software applications, in a fraction of the time spent building and maintaining it in-house, click here.

Transcript

Emily: Welcome to the business of open source. I am Emily Omier, your host. And today I am chatting with Alex Olivier, who is the co founder and CPO at Cerbos. We are recording on site in Paris at KubeCon EU. And today we're going to have a really sort of in depth discussion that's about the process Cerbos went through after launching their commercial product to get pricing.

Maybe not like perfect, maybe not. I'm not even sure if we can say right, but hopefully like more right. But before I really dive into that discussion, Alex, can you introduce yourself for people who don't know you and also introduce Cerbos a little bit? 

Alex: Absolutely. Thank you for having me. Yes, I'm Alex Olivier.I work on Cerbos and I am, at heart, a software engineer that turned into the OXIDA product. And now we have built launch servers to ultimately solve us a pain. We had many, many times in previous businesses around authorization. So anyone that's building a SaaS business, of which I'm sure many of you are, you have to worry about kind of user roles and permissions.

And this is something that's very simple to start with. You might just have, you know, employees or regular users, and your checks are pretty simple. But as your business grows, particularly if you start signing bigger clients, enterprise deals, these sort of things, you end up having to implement much more fine grained permissions and access controls that not only are manageable and scalable, but also auditable as you start going for compliance and these sort of things.

So Cerbos is a solution to a problem of something I've had to build in my previous lives, previous companies, dozens of times. It takes about three months to do right, and then six months later you have to rebuild it again, which sucks, and is a waste of everyone's time. So Cerbos is an off the shelf solution that I always wish I had.

And so we've made it to make sure no one else ever has to implement that. And we've approached it as an open source an open core business, and we have our commercial layer on top, which is what I think we're going to talk about now. 

Emily: Yes. So tell me a little bit about the process of figuring out what you wanted to put in the commercial layer on top.

Alex: Yeah, it's always a fun one. So we open sourced our solution about three years ago now, in fact nearly exactly three years ago and the idea was that we wanted to, We have an open core model. So the core engine of Cerbos, the bit that really handles, can this user do this action, this resource? It's open source, Apache 2 license, grab it off GitHub.

If you're happy to run everything yourself, you never have to talk to us, never give us a penny. Just go and enjoy your lives and not have to worry about authorization. But during those intervening years, obviously we hadn't, we went down the VC route, we had, you know, great investors that kind of supported us, but we started getting these asks from users about the kind of value add services on top and wanting a way to basically operationalize Cerbos in a much more streamlined way and a much more Standardized way and supported way because they've asked me the businesses required it So very early on we had kind of big enterprise users of the open source project kind of approach I was saying like hey firstly love the product which is amazing to hear But secondly like we want to pay you guys, which is a very strange discussion to have Early on and we're like, well, we haven't actually got a way for you to pay us yet We haven't got a product you'd pay us for But, through those discussions you start going into kind of, you know, what, what, what are the pains, what are the issues, what are the challenges you've had with the open source product and, you know, a few themes sort of appear around things like much more of a managed workflow, much more of a visible workflow that you could open up and enable more team members kind of work and authorization.

And then more on these for larger businesses, more on that security side of things like audit logs, visibility, and those kinds of things. So we had this kind of feature set growing and they had to go through this decision process of what do we build into the open source core versus what we put in the commercial product.

And so Cerbos hub is this commercial control plane that we've built that sits on top of the open source core, like even the API is between the core and the control plane or open source. So someone can come build their own one if they want, but we want to keep it very clean in terms of how we implement it.

And so we actually at last GeekCon so in Chicago in the last year, we launched Servers Hub, which is the management control plane for the open source project. And that's where we kind of go through this journey of how do you price this thing when you have an open core component and then open source then a commercial layer on top which was a tricky process to go through.

And we certainly haven't got the right model just yet. It's going to be a constant evolution as everything always is in software. And that's kind of where we are today. And I think it's a kind of an interesting journey that lots of open core companies kind of have to go through around the pricing side.

Emily: So to be completely fair, I'm not sure if you were to talk to a proprietary company, a non open source company, I'm not so sure that they'd be like, yeah, pricing totally easy. That was so easy. We got it right the first time. 

Alex: Yeah. It is. It's a, Is a hard one and and the way we kind of approached it This is something we started nearly two years ago now, even though we've only just launched our pricing very recently where the thing we fixated on most was not like the number or the Kind of the the metric or anything like that.

We focused on what's the variable? What's the dynamic thing that people will be able to not only? understand but also be able to like Comprehend the compute themselves. So we started looking at relevant, uh, sort of relevant services and systems that people are already using today.

So we're doing authorizations. We looked at things like authentication platforms, you know, what's their pricing metric and monthly active users is kind of a typical one. Other systems may look at like API calls. Others might look at just data volumes. And one thing we were always fixated on is like, okay, when we have early discussions about pricing.

What's the thing people can actually on the spot come up with a rough idea of what their numbers are? And when we started talking about data volumes api requests like people it's really hard to come up with like What is this actually going to cost me without you having to go and set up the whole system do a poc See the numbers, etc, etc So we were always looking at okay.

What's the thing people understand and with the server solution? We kind of narrowed it on this monthly active principles So it's very similar to monthly active users essentially analogous. And that was the thing we really focused on getting right before we even figured out what the pricing behind that is, is like narrowing in on picking a metric that is kind of crockable to someone that's just looking at Cerbosses for like a simple POC.

And then making sure obviously it scales and has like a nice pricing curve and etc as a kind of a second process 

Emily: yeah, I think that that's really important actually because it's not that difficult to change your price. Well, it's usually like Quite frankly usually you want to increase your price not decrease it because if you're decreasing it means like maybe Not a good signal.

But it can be a lot more challenging to figure out To change how you're calculating the price because it's more of a shock for your customers. So I'm really curious actually, first of all, you said that monthly active principles is essentially the same as monthly active users, but clearly there's a difference and I do not know what it is.

So what is it? 

Alex: Yeah. So for authentication systems, the thing you're mostly authenticating is a human being. So Monday active users kind of kind of make sense. With, Cerbos, the thing you're authorizing most of the time, most systems is a user, but it is, we call it a principle, not a user because you also want to be able to authorize things like API calls or service accounts or kind of machine identifiers, service to service authorization.

So we wanted to basically make sure that we had a metric that kind of encapsulated that, but ultimately we're looking at the monthly unique identities, which you're authorizing through the system. And we went for monthly unique, Rather than just raw number because we didn't we didn't want it to be basically a blocker of adoption because if we were to go if we were to say things like You should We're charging based on api calls, etc The natural kind of engineering instinct in me and it kicks in it goes like, okay How can I work around this to keep the numbers down?

How can I basically fake these numbers to basically? Caching adding caching adding like duplicate ids these sort of things to basically keep our costs down You But by just going monthly unique, you know, you pay the cost once for that user doesn't matter if they do one request, it doesn't matter if they do a million requests, you're going to say pay the kind of same amount and you're not going to have to waste engineering time hacking around the system to keep your costs down, which is you know, something that.

Ideally, we don't want our users to have to worry about it. 

Emily: So basically, like, it sounds like the criteria for you is just like, A, we want something that's going to be predictable for people, predictable even before they start using Cerbos. And two, that is going to be really hard to mess around with, to, to fake.

Alex: Yeah. And that's not so much because, you know, we're, we're assuming our users will do that, but it's more like. You shouldn't have to put the waste the brain cycles trying to figure out ways of doing it It's just keep it clean. Keep it coming something simple something that's predictable. There's a nice slider in our pricing character on our website.

You can just punch it in and see those numbers straight away and yeah make it as simple as possible to users get up and running with servers hub 

Emily: it is interesting because there's different different types of usage based pricing and It is true that it can end up being very unpredictable for users and for customers and one thing that people hate is unpredictability in their their costs and you know if you're listening like think about in your personal life if you would like to You're like your rent to be like this This month it's 10 and next month it will be 100, 000.

Alex: Yeah, sounds like the housing market in the UK at the moment. Yeah, and pretty sweet. So in previous lives, in previous companies, I was the one that had to look after all like the Google bills, AWS bills. And rightly I was being looked upon quite closely by our CFOs like, what are the numbers, what we forecast here.

And so a lot of the, the, The models you get with like the cloud providers, where you do committed spend and kind of upfront predictions and kind of baked in pricing is the kind of discussions we're having with our enterprise for enterprise users and making sure that they do kind of get that predictability in there.

You know, we've said early on that we'll never just cut off your account, and which some systems will do because where authorization sits in the system, it is so key. And so very much taking a, here's what you've committed to, here's what was going through the system. Let's have a discussion type approach right now.

Obviously want to standardize that going forward But yeah making sure that everything's kind of predictable and again It ties back to a metric that you internally can understand attract yourself if you wanted We're not we're not hiding these to you. We're not trying to give you a sort of sticker shock at the end of the month And kind of ties back to that Monthly active principles, we believe is far more easier to understand than like API calls, for example, or data volumes, which is impossible to understand upfront.

Emily: So you've done a really good job explaining this in 10 minutes, but I'm assuming it wasn't a 10 minute conversation when you were figuring out that this is what you were going to do. So tell me a little bit more like what was the discussion like when you were trying to decide what, what the metric was that you were going to that you were going to be measuring to figure out how much people should pay you.

Alex: Yeah, so we started off kind of Yeah, we're fortunate amongst our founding team. We've run multiple companies now, we kind of understand what are the things we didn't like talking specifically about our predictability so we started looking with a base sort of set of initial assumptions around what metrics could work here and What things we also didn't want?

Sort of the opposite of what we definitely didn't want and you know one trap I always kind of fallen into previously is trying to apply my lens of looking after the our costs to our pricing model So we're very clear like we shouldn't tie our pricing model to how expensive it is for us to run our systems We should have an idea of what that is, but we shouldn't couple those two together.

You know, we don't want ultimately to to just Also passed on across one to one that isn't really there and it's up to us to re optimize our system and such. So we had these kind of basic assumptions, monthly active users, data volumes, API requests, maybe just a fixed price, these kind of things, or like a platform fee plus a volume base on top were kind of the initial, initial ideas we had.

And then essentially, with our open source kind of approach and kind of go to market every week. I'm speaking to dozens of companies who are like going through a PSE server. So we just started basically making that one of the discussion points and everyone in these workshops. So even though they weren't trying to buy anything from us at that point, it was like for them to buy, we were already starting to have those initial Kind of discussions around like, you know, for this kind of service, how would you value it?

How would you think about it? What are the analogous systems in your current architecture that you're already paying for? You know, how do you price those? What are the things that would put you off buying a serverless on top? And you know, this discussion really kind of fell into two buckets. One was around we are an established business.

We have like a whole SRA team, DevOps team, et cetera. We're happy to run all the open source projects ourselves. We don't really need you. Actually. One thing that does come up is we have a, a sort of an SAP within our side of business that even for any open source projects we're running, we need to have an enterprise support agreement in place.

So we were talking about like the variable cost of a serverless hub, but the other kind of thing we offer is an enterprise support contract for the open source project. So there was a kind of, that opened up a whole new set of discovery work that we had to do. We started talking to predominantly our enterprise customers, which thankfully we have now.

Quite a few by now around kind of what's, what would they expect and what kind of other support contracts they're paying for open source components out there. And then we kind of narrowed in on the cover price model for that, which is basically a fixed price, basically per the number of users that get access to support is actually a model that Google cloud has done historically.

I'm not sure they do now, but we use I certainly was involved in previous business. So like a per seat support cost, which So that was kind of set what our enterprise support offering is for the open source project. And then going back to kind of the variable cost of the commercial product, then it was very much like analogous products.

Well, while the systems are using us in your architecture, you know, we caught quite early on this feeling that people are willing to pay for authorization, but then willing to not as pay as much for authorizations, they would for authentication. Authentication was seen as you know, more. worthwhile paying maybe slightly more for.

So we kind of knew, okay, we sort of a bit of a price anchor here against authentication systems cause that's what we got compared to mostly when we had these discussions. So we went through numerous iterations of kind of what these models look like. We actually kind of put together basic calculators and Google sheets and actually shared them as our initial users.

Like here's kind of what we spoke about last. Here's based on the numbers you gave us what it would look like. We essentially put basic proposals together very early on and just basically tested the waters, like Is this does this number scare you does this number like not really an issue Does this number or this model kind of work for your business and based upon that we just kept refining refining it down but that was a year long process really until we locked in on what we wanted to do and went through that journey and After a year, we then actually like committed to the initial I wouldn't call it a v1 I'll call it v0.

1 at this point and kind of that's we created the pricing page on our website and and put it in there Calculator on on the site, etc And now we're at the point where I actually start to close the deals around it based on that model and you know, there's already a few things we've tweaked, you know around how we particularly do the support side of things but definitely this monthly active principal metric is the one that that has stuck Around the most in terms of what people can understand and are willing to pay for.

Emily: So I really like this idea that you decoupled the amount that you're charging customers from how much it costs you.

Because ultimately how much you, how much a customer is willing to pay for something doesn't really depend on how much it costs to, to produce it. It depends on how valuable it is to that customer. I do have a question, because I sometimes hear from people, particularly in the open source, commercial open source ecosystem, that they think open source companies or stuff based on open source should be cheap.

So I am curious, A, what do you think about that? But B is it comparable? Cheaper or more expensive to buy from Cerbos than say your, your closest competitive alternative that you think of. You don't have to say who it is. 

Alex: Yeah, well the competitive one is kind of an interesting one. Mainly because of the space we're in.

Most, our like quote unquote competition most of the time is a team building this in house. So really when we're having those discussions, the comparison isn't between us and another kind of solution. The comparison is between us and Dedicating an engineering team three months to go and build the system themselves.

And then it's much more of a discussion with the decision makers around You can go build this, you know from our experience across multiple companies multiple industries We know this takes about three months to do, right? And then when your requirements change, which they will for authorization You're going to be have to rebuild again in six months time or a year time So now it's not just three months of engineering time It's three months times by the number of times you have to go and change it change this logic Getting that message across in a way that isn't selling on fear, as it were, is sometimes a bit challenging and there's definitely a bit of experience required on the decision maker.

You know, if it's their first business, they think we just hack something together and get, they want to move their life. Great. It's the second time founders or the more established businesses that have been through this pain before that they realize I'm not going to waste time, cash, runway on building this, this common infrastructure component ultimately.

So that really is our competition and it's it's all about how can we give that message across in a way that's again kind of grokkable understandable, up front without without sending To without sounding like we're trying to put the fear of god into them basically 

Emily: I mean fear of god is okay.

Alex: Yeah I'd much rather have a positive conversation than a negative one so yeah, that's kind of kind of kind of how we approach it and then on the on the cost side of things My view is The core engine of these open source projects, which is thousands and thousands out there. Okay, that, that's the smarts.

Like, that's the bit that really, you're just saying, I'm not going to build this myself. I'm just going to bring in this component, deploy it in my stack, and get up and running. The commercial layer on top really depends on what that commercial layer is. If that commercial layer is a fully hosted version, and that does everything for you, you don't have to do anything, then yeah, that probably should be on the more expensive side of things, because not only are you getting a fully hosted version, but you're also getting that run by the people that know how to do that the best in the world, because they're the people that built the core version.

And I'm all up for saying like, yeah, this is not core to our business. I'm happy to go and pay X supplier to go run. This project, which finally is open source cause they'll know how to do it best. And it will have, you know, probably more bells and whistles on talks. It's not just a fully hosted version.

It's also much more added value on top on those sort of things for solutions. And this is what we do a service where it's kind of a hybrid where you have a self hosted component and then a management control plane. The pricing gets a bit more, maybe vague, but a bit more different to kind of understand.

Because it's actually much more of a technical thing around why you run serverless internally and then have this management control plane on top. And in that case, it's really about how can we make the control plane firstly give you the best experience possible running serverless, but also remove as many pains as possible from running the self hosted version.

So one of the big issues with authorization and it's kind of distributed and decoupled approach right now is You would have to basically have a set up and deploy a CI pipeline and continuous integration pipeline, which distributes your policies to all your running instances and synchronize the changes and rolled out policy updates whenever you want to add new role to your system.

That is something that you could do, but it's a lot of engineering work to go and set up and deploy. You need like a team that can now deploy pipelines. You need SRE and such and to monitor these things. Everything up and running while Cerbos hub is there. Not just say a managed version. It's actually definitely not a managed version due to sort of latency security needs, but it's actually a system and a layer which helps you operationalize Cerbos and gadget up and running much faster with Cerbos in a way that's much more production ready, removing a lot of the headaches of having to run the open source project.

And in that case, the pricing is less about fully hosted. Great. I'll just pay whatever. This is Okay, how much time is this saving for me or how, how how many fewer DevOps or SRE types do I have to dedicate to the system? And it's removing that pain and giving you a much more standardized and operationalized version of Cerbos.

And that pricing is more of a understanding of kind of what your, how your business thinks about that. Risk and scalability and teams and operationalizing around our services. 

Emily: So if you were to compare your pricing to your closest commercial competitor, cheaper, the same or similar, more expensive. And did you even think about that when you were setting prices?

Alex: We definitely looked at it, but there isn't, it wasn't a direct sort of comparison and there were a lot of kind of. I don't want to say legacy, but more kind of alternative, let's say slightly older models for handling authorization, which much more like on prem deployments, you know, in some cases hardware that you go and set up and deploy.

And it was like a semi comparison. With Cerbos, it's, we're cheaper than those, I would say those, there's massive kind of or maybe legacy providers. And then also looking at the authentication part of things, we kept ourselves under kind of what an authentication provider We do because that's just something we learned during the discovery process that actually, um, the expectation of cost authorization is slightly lower than authentication, even though those are sometimes muddled terms and muddled concepts to some business some, some users.

So we kind of benchmarked and sort of aligned ourselves with kind of what we were seeing in terms of expectations of these more modern authentication providers. 

Emily: This is still, like, relatively new, it seems, so I am going to ask you to do a pre mortem for us. Why do you think, or what reasons do you foresee that you might have to do this?

Completely change your pricing model. Like what are the weaknesses? 

Alex: Yeah, great question. So we have really been focusing on the b2b sas use case for servos and that's what servos has been priced around where you know You might have hundreds ten a thousand tens of thousands, maybe a hundred thousand users and you know That's a pretty sizable size of the sas market.

But even today we're already starting to get questions from businesses that are more like b2c b2c where your users or your monthly editor principles isn't 10, 000 or 100, 000, it's 3 million and our pricing calculator just like, well, it doesn't, it doesn't break. It just says contact us. So we haven't, we haven't right now set up kind of the pricing for the BTC on the public kind of, kind of outward facing pricing, but that's definitely one where.

If you start getting a lot of more inbound around kind of BTC and these millions and millions of identities type approaches, then the pricing model breaks. isn't really set up for that. And we're having to do much more kind of bespoke deals. And I would say that's the one where, you know, if, if if we speak again, like six months time and I'm running around with my hair on fire, it's probably going to be because of that.

Emily: Excellent. What advice would you give to other founders that are working through how to price their first commercial product? Open source founders. 

Alex: Yeah. Focus first on what the metric should be. Get that right, get your users on the same page that this is a sensible thing to price around, look at your adjacent technologies and really find a pricing, find a metric that when you have that initial discussion, just with your open source users, you can almost see in their eyes that they like doing the math because they know like the metric that they need to do the calculator on.

And once you've got that, and once you're going to get that agreement on those early discussions, like, okay, I can figure out what that is, I know roughly what that is. Then go into the next step, which is, okay, now work out what the actual dollar amount is and then go on from there. Don't get fixated on the actual, the dollars and cents until you really lock down on kind of what that metric is.

And secondly, like don't get hung up on what your costs are. 

Emily: Excellent. Anything else that you want to add around pricing or anything else? 

Alex: Your first version won't survive. More than your initial discussions. You know, don't get wedded to it. You know, you can do as many simulations as you want inside of your you know, dummy Google Sheets calculators.

I've spent many, many, many a day going through those. It's only when you really start getting your initial first batch of pricing proposals out where you really understand whether this thing is gonna work. So, you know, don't get wedded to your initial model. It won't survive the light of day. www. microsoft. com 

Emily: Excellent. Cool. Alex, how should people connect with you or learn more about you.

Alex: Follow Cerbos. Yeah, absolutely. You can find me on Twitter, Alex Olivier. And then you can find Cerbos at Cerbos.dev. 

Emily: Excellent. Thank you so much. 

Alex: Thanks for having me.