The Scripting Den podcast: Exploring the evolution of security post-MVP | Cerbos

The role of security in product evolution

Alex emphasized the significance of security as products transition from MVP to full-scale solutions. He discussed how initial simple authorization mechanisms often need sophisticated upgrades to handle increased user roles and complex interactions, especially in B2B environments. Tools like Cerbos provide scalable, maintainable solutions that adapt to growing needs without the constant rewriting of authorization code.

Importance of choosing the right tools

Highlighting a common startup pitfall, Olivier advised against developing custom solutions for problems already well-addressed in the market. For instance, when it comes to authentication, leveraging existing, robust solutions like Auth0 or SuperTokens can save invaluable resources and time. This strategy allows teams to focus on unique aspects of their product that truly differentiate them in the marketplace.

Planning for scalability from day one

One of the critical strategies Alex shared revolves around scalability—thinking long-term about how a product will handle increased loads and user demands. This foresight involves selecting the right infrastructure and services that grow with the company, avoiding costly overhauls down the line.

Ensuring reliable and secure user experiences

Alex also touched on the importance of reliability and monitoring, ensuring that as systems scale, they remain stable and secure, providing consistent user experiences. The discussion included practical tips on using services like Cloudflare to manage traffic effectively and protect against common threats.

Engaging with the user community for continuous feedback

Olivier highlighted the necessity of maintaining open channels for user feedback through tools like in-app chats and community forums. This ongoing dialogue helps in refining the product to better meet user needs and addressing any emerging issues promptly.

Conclusion

The conversation serves as a crucial resource for anyone involved in the tech product lifecycle, from developers to product managers. The discussed strategies not only alleviate common post-MVP challenges but also pave the way for building a sustainable and successful product. We encourage you to listen to the full episode to gain a more comprehensive understanding of these topics. For those who prefer reading, the full transcript is available below. Dive deep into this insightful discussion and leverage these strategies to enhance your product's journey from MVP to a mature offering.

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

Fernando: Welcome to another episode of The Scripting Den podcast. Today with us, we have Alex Olivier and please, Alex, introduce yourself and then we'll, we'll start talking. 

Alex: Yeah. Hi, thanks for having me. Hi everyone. I'm Alex Olivier. I am a software engineer at heart turned to the dark world of product and now spending my time working on solving a pain I had in lots of previous lives and previous companies around authorization, at Cerbos, were I'm a co-founder and chief product officer. 

Fernando: Yes. And we're definitely going to touch on that pain. Because today we're going to be talking about the journey from MVP into maturity, essentially or to put it bluntly, what happens after we just deployed our first version of our product.

And then we say, well, now, you know, what comes next? It's working. It's in the servers but it's definitely missing a lot of features. It's definitely missing a lot of things. So I just want to go through that journey with you. So let's just answer that question first. And then we'll go into more specific things, but what comes after the MVP?

Alex: Yeah, great question. So I've spent a lot of time myself building little hacky projects in my spare time, and then in my day job building and scaling software from early days of my career working at Microsoft in like a consulting arm. So seeing massive enterprise projects that take X number of years to complete and seeing those through but then also in the world of startups.

So I've worked as a, just a straight off full stack developer and then gone to tech lead and even into like sales engineering side of things, and then venturing towards product. So I've actually seen development of lots of different products verticals with both small and large companies. And i've done a bit of consulting on the side, for businesses and they're just trying to get off the ground with their first version When they've been struggling to find a a technical co founder and such so i've seen quite a lot of great mvps where You know, you can go the very extreme method where your mvp is just a you know a google form a type form and then some You know magic behind the scenes and you get an email with some output which is being done by some poor suffering founder who's definitely trying to get an idea off the ground do you get the slightly more mature ones that I built on top of one of these like low code no code type type systems which is great to kind of validate just the idea But then it really does come this point and I always put it put this point down to the moment You start accepting money to your product where you do need to start You taking a bit more thought and ownership over kind of your underlying technology because it's all very well, you know, you've got this great validated problem.

You're out in the market. You've got willing users, you've got now people that are willing to part with their hard earned cash for your product. So I always look at it as kind of, you know, it's a bit of a mor, a mor a moral thing. Absolutely. But you have that responsibility to make sure what you're designing and what you're building and ultimately what people are paying for and exchanging cash for.

To be stable and scalable secure reliable and there's a number of things that i've always kind of gone through When talking to various businesses and myself As a bit of a checklist of things to get in place before I really kind of push the button And go go live to a larger audience beyond that small mvp group so There's kind of five different buckets.

And I guess we can get dive into each one separately but I always look at scalability You So, not necessarily building a system ready for hundreds of thousands of users, those kind of things. But, scalability in the sense of, you're going to get more traffic on, you're probably going to spend money on marketing, you don't want users landing on your site or your app to have a bad experience.

So, just making sure, you know, whatever you're running on can grow with you. So, I'm sure, Fernando, you've probably, you know, spun up a small digital ocean droplet, or a small, you know, thing in maybe the cell these days. And as great as you go far. But can the way things are architected scale up to kind of meet that?

And it's not just the physical service but also like the underlying data databases and these sort of things or if you're using like a Database as a service back end or something like fire store with firebase, you know Is the is the system be able to scale but also the data model being able to scale is one aspect Security is obviously the next one and kind of front of mind for me and this is why ultimately I work on servos You In the early days, you could probably get by without having very detailed user roles or these, or, or access patterns or access controls and those sort of things in place.

You might get away with, if the user email address is your company domain, then they can do everything. If not, then they're a user and they're kind of stuck in, stuck in those little things. Very easy to kind of get up and running. You can hard code all that logic but the moment you start scaling up the moment you start bringing if you particularly need to be bringing larger businesses on you know having those tighter access models is is going to be a Not necessarily going to win business, but it will be a make or break for a deal And i've been a burnt plenty of time for that in the past with some massive companies so we could security is this one reliability monitoring monitoring, so Is your system reliable?

Is it staying up? Are you getting good API response times, etc.? If you're going to get these massive traffic spikes, is your API just going to fall over these sort of things? So, you know, being sensible in terms of having using something like Cloudflare in front of your, your site to kind of handle all the bots and all that sort of stuff that may occur.

And then on the flip side, making sure you have the right monitoring in place. So you can't, you can't understand what's happening if it's not monitored. So you get a lot out of the box with some of these existing sort of solutions and cloud providers, but are there any specific actions or specific API calls and things inside of your system that are kind of critical, maybe adding in some bit of extra money around that.

And there's a whole great ecosystem of tooling out there to help you with that. And then kind of away from the more technical side of things. So I'm now, you know, focused very much on products. So I, the number one thing for me is. getting feedback and getting input from our users. Like, what are people liking with Cerbos?

What are people, where are people getting stuck? Where are people getting annoyed? Where are people dropping out the journey? So there's a mixture of like making sure your sort of analytics stuff is in place, but also making sure you have those communication channels open. So with us with Cerbos, we use an in app chat tool called Crisp, which I recommend but you're kind of familiar with intercom and these style tools very low friction way of, of communicating.

And then also thinking things like your communities, discord, those sorts of things also go well. And the final one I always kind of go through, go through kind of companies that I get going is probably the least sexy of them all, but it's kind of the compliance and the legal side of things. I helped found a platform in the States called Vanity which is like a cognitive behavioral therapy management platform for children and family, and obviously there's very sensitive Data in there.

And you have all sorts of extra regulatory hurdles to meet and rightfully so to, to make sure you tick all the boxes and are handling data as you should. I always tell the story, like I did computer science degree here in the UK at university and, you know, lots of interesting modules, you know, going into compilers, how, how processes work, formal specification, et cetera, et cetera.

But the one module, which I probably have referred back to the most of my career. Is the one that was the least sexy on the on the curriculum, which is like the legal and ethics or computer science Where we went through things like data security data protection the ethical side of things as well, and that's actually one that It's worth really up and reading into if you've maybe just getting into coding or getting into development there's this whole other world that will Ultimately give you requirements for kind of your software, but making sure We're in the now the world of GDPR, CCPA, all these other kind of regulatory frameworks, make sure you comply with it.

And if you're particularly going into markets. Healthcare being an obvious one or anything to, with finance, you've got all the different, you know, PCI compliance Absolutely. Et cetera, to worry about. And, and there's things that definitely come with the maturity side. Yeah, absolutely. Yeah. They're the five factors that I like that, I like how you broke, 

Fernando: You broke them map, but, but essentially three to start thinking about everything else. About any of these categories is just, am I, am I charging money, am I liable, am I responsible for serving a product or a service because people are now paying for it. I like that. Definitely. And honestly, I would like to make an episode on each of these categories because each of them is very interesting, but today we're going to focus on security.

And so you definitely are close to it because of service, because of your work because of your experience. Now tell us a little bit of how relevant is the role of security in a Nelly stage product in a, you know, just post MVP stage. And What exactly do you understand by security? Because I think that the term security is a little bit abroad and we can probably start thinking about many areas where security can be applied or maybe should or should not be applied at this early stage.

So where would you suggest people focus on and pay attention to at this stage, once they have their product working and they're ready, like I said, to start getting paid for it and getting more users. 

Alex: Yeah, so I, I've kind of looked at it on two fronts. Firstly, I look at it as from like kind of the customer point of view on their kind of journey.

So what, how they interact with the application. So the first thing they're probably doing is signing up and authenticating with the application and they have a session inside your app. We are very fortunate to be in a world now where there's some great authentication systems out there. It's very easy.

Rare, and it's probably worth maybe a bit of a broader discussion side of your business. If you're building your own authentication system, you know, either pick one of these services off the shelf by what, by in the service. So if you were to buy one, maybe go and look at or zero or clerk or super tokens, one of these things equally, if you want to do something a bit more self hosted again, don't build an authentication system, go and pick a, and self host a super tokens, for example, or go and look at fusion or for one of these other.

Imid key type type solutions and the reason for that is firstly if your guests getting going You know money's probably a bit tight You don't want to be burning Two three four five six weeks or even you know months if it's going to be a complicated Solution building building out an authentication platform.

That's like just commoditized at this point Go and pick one off the shelf and it's commoditized the point where you get all the feature sets You get out of the box, all the capabilities that people expect these days. So log in with Google, log in with GitHub, all those sorts of things. And also you're not having to deal with things like picking a encryption algorithm or how you hash and sort your passwords and those sort of things.

Just the world's moved on you know, past keys are now here. That's the thing. Authkit is another solution to go look at. I recommend from WorkOS. Authentication is the sole problem. Don't waste time doing it. Pick a solution off the shelf. Off you go. The next step, and this is where kind of why we started doing serverless, is okay, great.

You now authenticated someone. You now know who they are. But what can they actually do inside your application? So the style is talking about maybe you have a very simple logic that says if this person's email address ends in your company domain, they're an admin, they can do everything, otherwise they're just a user they should be limited.

That's it. Most applications these days, particularly if you're working in the B2B space, are really about workflows between different user roles interacting. So, for example, in one of my previous jobs, I was leading product for a supply chain system. So you have buyers, you have sellers, you have shippers, you have custom brokers, and they all need to interact with different kind of controls and different permissions to do their roles.

And, you know, if you go and look at any sort of, you know, if you can look at, I'll just pick another one, let's say GitHub, you know, you have a team, you're on GitHub, you're an, you're an organization, being a part of the organization gives you access to your repos, your repos are configured. So only certain users maybe have the rights to bypass the checks or all that sort of fun stuff.

So these are kind of the, the, the more fine grained permissions that you kind of inevitably come to. So you might have heard of RBAC or role based access control. So that's where you are assigning user a role, and that role allows them to do certain things inside of your system. It's pretty easy to implement these days.

One of your authentication providers most likely has a mechanism of attaching roles or scopes to the token Maybe they're the issue so you can check. Okay, this user's authenticated their token's valid They have the role of manager and then in your code You have a load of if statements if user is manager do the action if not return some sort of thing And that's kind of a good place to start get you to that next level of granularity What you generally also then need and may be doing without realizing is attribute based access control, where it may be only the owner of a resource can do that particular action.

So imagine you're like filing an expense in like an expenses claiming system. I can create the expense, I can delete the expense because I created it, but I can't approve it because I'm not the manager. So you end up having to hard code this logic, which is like, Okay, if the user is a manager and they are not the owner, then they should be able to do the approve those kind of logic.

And that is stuff you kind of hard code. Now, that complexity might not be necessary for your first version after an MDP, but that complexity I guarantee will come. So I've grown in scale businesses and software from very small systems to the point where we were winning multi million dollar contracts with some of the largest companies in the world.

Like one example like a big middle eastern airline the largest, office supply retail in the u. s Two of my clients and one of my previous roles And they come with a whole new suite of requirements around authorization and access controls And in that case we had to go back and re architect our whole d permissions multiple times every time I did it took about three months.

It sucked and This is something that you can get right early And it will grow with you and so You Shameless plug, Cerbos is a solution for exactly that. But from a mindset point of view, it's like, what are the things that are likely to be requirements in a year's time, two years time, three years time, that can help you influence and design and architect your system today?

And that may be small things, you may have to do a little bit extra work today, but all their payoff will be massive down the line. And that's not just around the security side of things, but like getting your monitoring right. You know, you do the work to implement your metrics and your APIs and set up tracing early on, that will pay off down the line where you've got, you know, hundreds of microservices all talking to each other, etc, etc.

So it's really about looking and thinking, you know, where's this, where's this gotta go? You know, what is the incremental effort to get it right now? And some things you might say, nope, actually that doesn't make sense. We'll park it, we'll do it in a year's time. Absolutely fair enough. But particularly if you're going like b2b enterprise, there will be requirements for authorization There'll be requirements for a single sign on there'll be requirements around audit logs.

There'll be requirements Around the directory syncing all this sort of fun stuff, which you know, if you know, that's going to be your customer You know, that's going to be the market you're going after it's worth putting the effort in now So it'll be there to grow with you as time goes on. 

Fernando: Absolutely. I think that if you're going If you're targeting enterprise customers right off the bat, then I think that this is probably something that you might want to start thinking from day one.

But if, but if not, if that's not your case and if, if you're eventually thinking about it to be not enterprise level, but then definitely I see that progression that you mentioned of, of going, well, at first I may not need it, the MVP, it's just hard coded, but then. I gotta start seriously thinking about this because those are the clients that are going to be bringing all the money I should probably be ready for that. So, yeah, I can see that.

Alex: Absolutely. And and you know part of that just comes with sort of obviously knowing the market also, you know from experience and and i've made every mistake that you can Through this in previous roles and you do just kind of pick it up as you go You kind of muddle through those mistakes and have to spend the sleepless nights trying to fix things or re architect things to to get things right.

But yeah, there's small things you can do now, which may may only be a little bit of incremental effort today but the payoff is massive down the line and and you know security is just one of those I always kind of highlight to businesses i'm working with 

Fernando: And when you say that there are little things that might require a little bit more work, but would you say that integrating a third party solution like services right now, right off when, when you finish your MVP, would that be more work than actually hard coding your whole authorization logic?

Alex: I mean, it's a bit of a, a bit of a string type question. Again, it kind of goes back to the kind of complexity of your application, particularly if you're looking at an application that has a different user roles, interacting to achieve some goal, which is an outcome. Yeah. That business logic is going to be complicated.

And you know, it may not be today. You might have a single service in one language. There's only a few API end points and your authorization check is pretty simple. Has a user got a role or not? Yeah. Check out a statement and fine. But if you're going in and you're starting to like. Determine access based on attributes or to determine access based on other kind of context about the use of the resource That logic is now going to be in code It's now going to be only kind of accessible and grokka ball by the engineer that wrote it And you know if we look at the world now where you know, I hate to always bring out by like AI That whole world of for example is in Python You know that that is the de facto language Some c optimization, but ultimately it's python and all those kind of models and such Most web applications we're seeing today particularly the ones we see with servers, you know, you're using typescript or go or one of those kind of kind of languages But if you're building a system that has some sort of ll component you now have some service that's going to be in Go or javascript, whatever and you'll have another service that's going to be in python and you might have some legacy components in java or whatever But to do authorization Probably you're gonna have to implement that authorization logic in n number of services and n number of languages That's that means the work is basically multiply because you're gonna take those business requirements and have to go through it's like logical Translation into each of the relevant programming languages And not just once but the moment the requirements change like you want that that sounds like a nightmare 

Fernando: That sounds like a nightmare.

Alex: Yeah absolutely, absolutely. You know, then you have to touch all this code, you have to retest it or redeploy and, you know, hope you have some rockstar quote unquote 10x engineer that can do all that all at once. In reality, you know, you'll have multiple people working on it. So the incremental effort of going through and using a decoupled authorization system like a Cerbos or one of the other solutions out there, you, you make, rather than hard coding that logic across all those services in different languages, It's now a standalone service as an authorization service a box on your architecture diagram It's deployed in your kubernetes cluster.

It's deployed wherever Around alongside your application and that's the the self contained service that does all the authorization So now each of your services now doesn't have to have the hard logic hard coded into it You just do the extra step the mutation to send the context to that service That service based on authorization policy makes a decision and now each service just simply has to handle and allow or deny decision.

And there's no longer having that logic hard coded. So when those requirements change, you just update that essential service and all the other applications are up to date. And that's kind of a, one of those examples of, you know, it's a little bit of extra effort on the day one or day two, how we're going to call it to implement the API calls in the context of the Hedgefront deploy service.

But a year down the line when you're changing requirements, you add new features, you've got some massive enterprise deal that's asking for like five custom roles. You could just do it in one place without having to touch the rest of the application. 

Fernando: Yeah, I can see that. Now I'm going to ask you a question that you might not like, but is there a downside to this approach?

Alex: Yeah, absolutely. So, you know, that everything's always a trade off. It's always going to be a balance. So if you were to take Authorization versus an authentication in this case. So authentication relying on some third party services Or third party be it another component in your stack that you self host or an actual third party service That is something which is okay to take from a performance related point of view a bit longer and because You Someone lands, you redirect them to authenticate, they return back and you get a token that's valid for say 10 minutes or 30 minutes or an hour or whatever you set your session time as.

So in your application code when you're processing requests, you're not having to hit this external service every time to check the token. You can validate the token offline if you have the key set and you don't have to hit some external service etc. And you know, that's fine and after an hour the session time's out, you have to redirect the user again, they come back, all good.

Something like authorization is a bit different because authorization is in the blocking part of every single request. Every API that comes in, you can verify the token synchronously, but the authorization check you need to do on every single call. And what you don't want is have some external service that you're having to hit over the internet.

It's going to add 20 milliseconds, let's say to every API call when your application returns in one millisecond, even, but you're not going to have to be 21 milliseconds because authorization is 20 milliseconds. So again, it comes to kind of looking at. Your architecture, your, your appetite of risk, your willingness to self host and manage components.

So when it comes to access controls, looking, is there a self hosted version of component that I can run right alongside my application? You know, is this thing required a big heavy database? Is it stateful? Can it horizontally sail? The actual interface it speaks over, is it REST? Is it gRPC? Is it just a Unix socket?

Yeah, all these kind of Things you can do to get all the benefits of a decoupled approach, but still make it feel like a native component And in some cases using some of the newer technologies like web assembly, etc Which is something we enable in a server service hub You can actually embed a dynamic component inside of your codebase, but it's actually a dynamic evolving policy library that's generated for you so It goes back to kind of look a bit more holistically to your application architecture you know, what can you distribute to the edge?

What can you run in sidecars? What just needs to be a concrete service inside of your stack? And kind of managing those trade offs. So, you know We get asked this a lot obviously with serverless because it is another service you run in your stack. It's all self hosted From a performance perspective.

It's fairly stateless. So all All decisions are being run in memory. It's not having to fetch disk or query database So that there's no disk time or anything like that waiting for You The interface you speak over is grpc. So there's not the overhead of rest http etc and It's because it is stateless.

It can be horizontally scaled or scaled So we always recommend just like run one server right alongside your application so looking at what solutions you're going for authorization authentication logging, etc, etc, and trying to Find one that fits your architectural pattern in terms of performance and latency And then just kind of come up with, you know, what your SLO, your service level objectives of your system and make sure it fits that profile.

Fernando: That's right. Yeah, definitely. Definitely. That was kind of my, when I was learning about you guys that was kind of my question. You know, I'm, I definitely, I see the benefit of extracting that logic from my code, but it's like you said, I mean authorization happens every single request. So I need to, what, hit an external resource now on every external resource on every request, but I can see that there are many solutions, many ways to improve implemented, keeping performance in mind to not affect the final product as much, at least definitely I see a trade off.

Alex: Yeah, I mean in all likelihood your api handler is going to be hitting a database. It might be hitting a cache They're all off box requests as well Especially if you now look in the world where things like planet scale are taking the world by storm where you have a cloud hosted Database which to me still feels a bit, backwards from everything i've learned in my own experience But we're in a world where the internet's fast you get vpcs, etc, etc You know private gateways and such you can hit performance numbers that are decent for that And then yeah, it's really just kind of an architectural an architectural decision and you know with servos we always Sort of keep an eye on our performance, etc.

So we know that our rule evaluation is always sub millisecond without fail Anything beyond that is just network So making sure there's good options for how you can deploy sci car using an efficient protocol these sort of things Had to keep things as snappy as possible. That's fair. And we just hope that the the trade offs are worth it.

Fernando:Yeah, yeah. For a business person, that's the main thing. Yeah, absolutely. But I can, I can, I can see that you know, the fact that and this goes back to when you were explaining the, the benefits of it and the trade offs. The fact that you remove the need to code this, you know, just, it's not that it's going to scale, which will, it's not that it's going to be flexible, which will, it's just that you're literally removing one preoccupation from you know, from my mind, I'm no longer thinking about authorization anymore.

You know, I might, I might, I don't know how hard or easy it is to implement servos into a project, but once I'm done. And I'm not longer thinking about it. You know, I'm thinking about any other features or things that I want to add to my project, but that's no longer a problem. I'm just thinking about you know, if a new requirement comes, I'm just thinking, well, I have to log in and create that role or whatever, or configure that, that change, but it's going to happen on an external interface.

And it's not going to happen on, on my code. You know, it's one less worry. That's fantastic. 

Alex: Yeah, absolutely. And I know this is like the Scripting Den podcast and we're developers here, et cetera. But if you're kind of building a business, you're probably going to have a point, you'll have a product manager, you'll have a security team, you'll have a sales team, et cetera.

And these are all going to be kind of funneling requirements in. And, you know, if in the quote unquote old world, Some horrible Jira ticket will land In there or your github issue will land in the air and you're like oh god now I've got to change these like paragraphs and paragraphs of text into actual code What we've actually seen with serverless in the way we do it by decoupling a bit out of the application code And it's actually in a policy language.

It's just human readable it's, it's, it's YAML at its core love it or hate it, YAML, interesting. Which clearly defines, you know, here are the different resource types, here are the different actions, and here are the conditions which must be met for an action to be done or not, or be allowed or not.

And what we kind of see and what we've heard from our users is actually for the first time, the product manager or even the security team has actually been able to manage policies themselves, and the developer hasn't even got to get involved at all. You know, you do that initial implementation you put in some test cases around it because you can write unit tests against policy once it's just extracted out like this And then you just hand it off And you know as a developer you're focused on building capabilities and features as a product person You're making sure that you're meeting the requirements of kind of the market the business user, etc and and you know, really why are you getting a developer to do something when They're not the ones with the requirements.

It's the product person. 

Fernando: Absolutely. Absolutely. Yeah, I I I like that approach You then let me ask you this last question. When would you recommend then not using something like servers? When would you recommend going just hard coded building yourself? Is there a world where, where that would actually make sense?

Alex: Yeah, I would say the scenario where we see kind of users not using a solution by service because there are others that do kind of deploy this like this is when it's either applications and processes that are running like on client devices. So you know, they're just like a mobile game or they're a very limited backend or it's the, the app, the model is you're a single user.

There's no complexity. You're not interacting with any other users. There is an argument there to kind of keep things simple, just hard code the logic into your code. There's lots of language specific frameworks that you could use even and that aren't services or kind of abstracted backends But, you know, the day and age where you have more and more kind of interaction between users and more add social, social capabilities to everything.

The the sample, the, the set of applications and, and. platforms that are just a single user As you can do a link and even an application that might be only for a single user You might have internal tools like a backoffice system that helps you as a business manage that quite simple user base But those internal tools need audit logs.

Those internal tools need authorization those instances authentication. So there's there's An argument to actually use decouple authorization as a concept in pretty much any application these days but if I were to just building like a single user on device client application thing, then maybe I wouldn't.

Fernando: Yeah. Sounds, sounds reasonable. All right. That's it. That's most of the time we had. So I want to ask you one last question, which I try to ask all my guests. What will be your number one recommendation to the listeners? If this was your podcast about security, about, you know, MVP or about software development in general, what will be your number one?

Advice, you know, to people thinking about the product, building the product, or maybe, you know, having the product out there, MVP, and thinking about, okay, what's next.

Alex: Unless it is core to your business, don't build it, pick a solution off the shelf. Be it an open source project that you just run and deploy or a paid solution, doesn't really matter. Unless, for example, if you take authentication, unless like building authentication is what you're doing as a business, don't build authentication.

You know, your job is ultimately to survive as a business. You've got to spend your time and valuable efforts and money on building the best product for your users. And you do that in the differentiated business layer, not the underlying undifferentiated infrastructure layer. You know, you will, you will live or die based on these kinds of decisions.

They're not the most sexy things to think about. But these are the bits that every system needs. Everyone's done it before. Don't reinvent the wheel. And focus on building what is actually core to your business.

Fernando: Oh, I, I love that advice. It might not be sexy, but I think it's definitely a great way to, you know, Remove that, that probably off your mind and, and, and, or at least make the decision, you know, maybe if you don't know whether you should build it or not.

That reasoning there it's perfect. If it's not caught to you, then just don't build it. Just get it from somewhere else. I love it. All right, Alex, thank you so much for your time, for being here and for the great advice. I'll make sure to add every, or as many of the links, as you mentioned on the show notes, but please tell our audience where they can find you, where they can find Cerbos and where they can reach out to you.

Alex: Yeah, excellent. Yeah. You can find me on Twitter or X at Alex Olivier, and you can find Cerbos at cerbos.dev or github.com/cerbos. 

Fernando: Awesome. All right. That's it folks. Thank you for listening. And thank you, Alex, again. Catch you on the next one. 

Alex: Thanks for having me.