Building your own authorization solution vs. buying an off-the-shelf one

There is no standard answer to the perennial build vs. buy question, but the argument for rolling your own authorization is getting harder to make. The increasing complexity and security implications of authorization, combined with strong, off-the-shelf solutions makes purchasing the best choice for most companies today.

This is the same path authentication, payment and cloud storage solutions have already been down. Years ago, companies had to decide whether to buy authentication or roll their own. But with the solutions available today, most companies default “to buy for parity, build for competitive advantage”. And very few set themselves apart through their authentication system.

Many founders and CTOs I talk to don’t see it that way for AuthZ. Authorization logic is so deeply entangled with how a system works, deciding who can access controls, change data, or even change access roles, that third-party vendors can’t meet their specific needs. They’re right to be cautious. Inadequate authorization will result in breaches, compliance violations, and scalability issues or may simply cause enough lag that your software becomes unusable.

In this article, we’re going to help you speed-run the build vs. buy decision by breaking down your choices, so you can evaluate what’s best for your situation.

Table of contents

1. Quick framework for the build vs. buy decision
2. Deep dive into key factors to consider when making the decision
   • Business factors (time, team size, expertise)
   • Technical factors (flexibility, scalability, compliance)
3. Examples of when it makes sense to build, and when it makes sense to buy an authorization solution
4. Tying it all together - a step-by-step guide to making the right decision
   

A framework to clarify your needs and constraints

The simplest way to think about this decision is to frame it by defining your needs and any constraints. To help you do that, I created a rubric consisting of eight yes/no questions.

Question	Yes - Build it	No - Buy it
Is authorization a competitive advantage or part of your core purpose?
Are you operating in a regulated industry with strict authorization requirements (e.g. Finance, healthcare, insurance)?
Do you have exacting requirements that off-the-shelf products can’t give you? (Keep in mind nothing, including in-house built software, is perfect. Look for off-the-shelf software that meets 80% of your needs.)
Does your team have the expertise to build it?
Does your team have the bandwidth to spare a developer so they can focus on maintaining their expertise and the software?
Does your team have the bandwidth to spare two, so you don’t lose expertise if one leaves suddenly?
Do you have a long enough timeline that building is not going to set you back?
Do you only have one monolith service that uses authorization?

Other than the above points, there are some other considerations to keep in mind.

Weigh the cost in resources it would take to build vs. the cost in dollars to buy. It’s easier to calculate the cost of buying than it is to calculate the resources it will take to build.

You know both the upfront cost and the long-term costs of every piece of software you buy before you make your purchase. The only thing you don’t know is how much developer time it will take to implement and integrate it.

With building, the costs are more difficult to calculate and are subject to change. Developer time will be your biggest expense and is subject to​​ scope creep, underestimation, technical challenges. Then, there are hidden costs like the increased timeline to develop (which may push back your GTM strategy), testing, additional infrastructure management and other services your developers will require.

Understanding the risk level is also important. A failure in your authorization can range from unfortunate to catastrophic, depending on the data you are protecting. If you’re storing sensitive user data, the consequences of failure are high. In this case, it makes more sense to rely on a real-world proven solution. However, if the consequences are lower than the risk you incur by building your own, unproven authorization is also lower.

Deep dive into key factors to consider when making the decision

Once you understand your business’s capabilities, constraints, and your authorization layer needs, your answer to the build vs. buy problem will become clearer. To make this simpler, I’ve broken down the above categories into three subcategories.

Business factors

Half of the decision-making process is determining whether your business is well-positioned to build. You need to know if you have the time, the team and the expertise to build an authorization layer.

The first point I'd like to cover is time to market. Building takes time, often more than originally planned. Whereas, our clients will have Cerbos up and running in a couple of days to a few weeks, rolling your own can take months. Trying to compress that timeline puts pressure on developers, which can lead to corners being cut and even errors in the logic. If you have a short timeline, buying will help you meet that deadline. If you have a long timeline, with plenty of time for development, building is an option.

Year team is also a big consideration. Building and maintaining your own authorization requires a dedicated team that can tackle the project. Big tech companies, like Airbnb, have large developer teams that have the bandwidth to tackle complex projects like authorization. Most startups are running small, agile teams focused on delivering the software’s core purpose and can’t spare developers to bring their knowledge and skills up to date to develop authorization and maintain it as the company grows.

Finally - expertise is one more critical business-related factor. Authorization is complex, critical and touches almost everything each user does in your software. To meet your security needs, without adding latency to the user experience, your team needs in-depth domain knowledge which needs to be kept up to date. For example, in the past few years, authorization has moved from role-based (RBAC) to include attribute-based access control (ABAC). Up-to-date understanding of authorization is critical to keep your software secure with high availability, and minimal latency.

Technical factors

The other half of the decision-making process is determining the technical requirements you will need to meet your goals. Most businesses will require an authorization layer that is flexible enough to meet current and future requirements, can grow alongside the business without undue hassle, and complies with the laws of the countries in which they operate.

Let’s start off by talking about the technical factor of flexibility. While finding a perfect-fit solution is a major concern for most companies - custom-built, one-off solutions rarely make room for the most important aspect of a performant authorization layer, which is flexibility. Technology changes, the law changes or the competitive landscape changes and businesses that are not flexible enough to change with them rarely last. Extensibility and flexibility have to be considered first to ensure that the access management system can adapt and evolve with internal and external pressures without requiring a rebuild. By considering this early on in the decision process, you avoid technical debt that can weigh down your business.

Maintenance / scaling is yet another consideration. As your software applications scale, authorization becomes more complex. New users, logic and roles require more nuanced decisions, putting more pressure on your system and opening more areas of attack. For Je Sum Yip, the Chief Engineer of Human Managed, maintaining and scaling their authorization turned into a pain as they grew. Every time they had to change permissions, they had to go into the source code of the API, to make that change, then recompile, push it out into development, test it and then finally put it into production. That amount of technical debt slows down development and takes time away from developing the core product.

Another one to mention is compliance. The more sensitive data you store, the more regulatory compliance your business is subject to. This is especially true if your company operates in the fintech, banking, insurance, medtech, or government industries. If you’re operating in a highly regulated field, full visibility into how permissions and authorization is being enforced across the application is not just a nice to have, but a necessity. In this case, you may choose to build your own (or go with an open-source option) that the team can take ownership of. However, if you can find a trusted third-party solution to provide a secure authorization layer it gives you a strategic tool to meet compliance requirements.

Examples - when it makes sense to build, and when it makes sense to buy an authorization solution

When to build authorization in-house?

We’re big proponents of leveraging an existing authorization layer that fits your requirements and needs. But when you have simple, straightforward requirements - building is the quickest solution (check out our ebook on building a scalable authorization solution). If you have 3-4 well-defined roles that won’t change or need updating, simply hardcoding your authorization logic will suffice. In the same vein, a small startup trying to build its MVP may decide to code its authorization logic just to get it out the door and into the hands of users to enable rapid iteration.

However, when talking to startups, our sales teams came across a few other reasons that founders or development teams will cite as reasons they’ve chosen to build their own authorization layer.

In a conversation with one of those companies, the development team told us they built their own authorization, because getting a sign-off from their security team for every new version of a third-party vendor’s solution was too cumbersome. It made purchasing a solution more difficult and made them less flexible than rolling their own.

Those kinds of internal hoops are not very common. Typically, companies will bring up one of the following three reasons to justify rolling their own.

• The first is that they believe their needs are too custom for off-the-shelf software. Airbnb, for example, created their Himeji authorization system when they moved from Ruby on Rails monolith to microservices. With a strong team already in place, they were able to build an authorization system that met their specific needs.
• The second reason is some companies want to stay in full control of their stack. We touched on this above in the technical factors to consider, but it’s worth going into more detail here. For highly regulated companies, adding services to their stack which their team doesn’t have full access to, creates an unknown liability. In fact, for any company concerned about security, adding a black box to your authorization isn’t a good idea. That’s why we made Cerbos open source, giving your team full visibility into the code.
• Finally, some companies still see value in having the domain expertise in their organizations. Typically, these are large companies with access to both a deep team and deep pockets and a long-term commitment to the authorization layer they build.

Often, when companies are focused on these issues, they aren’t looking at the downsides of building their own authorization, many of which are shared with encryption. Just like with authorization, encryption is a critical part of your security software. That’s why most companies rely on encryption standards that have been inspected by experts and proven themselves solid. All rolling your own does is open the possibility of introducing mistakes into your encryption, which is very easy to do. Many of the same complications hold true for authentication.

The possibility of mistakes becomes even more apparent when you start adding new roles or permissions. This increases complexity exponentially, especially if you’re working with enterprise clients that need multi-tenant considerations. As those new requirements balloon, your team’s development time does as well, costing you hours and diverting attention from core features.

When to use a ready-made authorization solution?

I have a bias here, but, I honestly believe that most companies would benefit from selecting an authorization system ‘off the shelf’. Not only do you get a proven solution, but you’re also able to leverage the expertise of a company whose sole focus is authorization.

For startups, like Loop, that means you can get to market much faster. With Cerbos, Loop was able to cut six months of development time by relying on our expertise. This allowed them to get to their customers earlier and start making money.

It also means that you’re not stuck maintaining or scaling a system that was designed and built for yesterday’s requirements. Human Managed, who I mentioned before, had rolled their own authorization in the beginning, and after they grew, the maintenance and scaling was taking up hours of developer time. By switching, they went from updating authorization logic being a very involved process, to a five-minute job. Human Managed also leveraged the support from experts, as well as getting involved in an active community they could turn to if they needed guidance.

Finally, for highly regulated industries an off-the-shelf solution can be helpful in ensuring compliance, as it’s built by experts who understand the various compliance regulations and have built the solution to ensure it meets those needs. For example, Loop’s CTO and Co-Founder Mohsin Kalam, found it easier to demonstrate compliance with Cerbos in his stack which resulted in them getting their banking license in record time.

Why Cerbos? How it helps teams avoid the build vs. buy dilemma

Choosing between building your own authorization system or purchasing an off-the-shelf solution is a tough decision. Cerbos gives you the best of both worlds, offering the flexibility of a purpose-built system with the reliability and efficiency of a proven solution.

With Cerbos, security patches, audits, and compliance updates are handled for you; your team retains full control over policies, deployment, and management while avoiding vendor lock-in due to its open-core model; and you gain audit logs and policy testing capabilities, making it easier to meet regulatory requirements such as SOC 2, GDPR, HIPAA, and PCI.

Whether you’re launching a new product, scaling a platform, or navigating strict compliance requirements, Cerbos simplifies authorization, so your developers can focus on building core features, not reinventing authorization.

Flexibility without complexity

Authorization should adapt to your business, not the other way around. Cerbos supports advanced access models like RBAC, ABAC, and PBAC out of the box, allowing you to define permissions with precision while avoiding rigid, hard-coded logic. Whether you’re a startup launching your first solution or an enterprise managing complex multi-tenant access, Cerbos scales with you.

Cerbos is also designed to fit into any tech stack. It runs alongside your application as a stateless policy decision point (PDP), making authorization decisions in milliseconds while keeping your system performant.

Scalability

Building your own authorization might work in the short term, but scaling it as your user base grows, or as requirements change - introduces challenges. Every new role, permission, or policy update can become a bottleneck.

With Cerbos, your access control system is future-proof. It’s built to handle high-volume workloads, ensuring that authorization is never a bottleneck. As your application evolves, policies can be updated dynamically—without refactoring code or redeploying services.

Security and compliance

Authorization is a security-critical function. Mistakes can lead to data breaches, compliance failures, and trust erosion, all of which can be costly to recover from. Cerbos mitigates the risks of rolling your own by providing a battle-tested authorization engine used by hundreds of companies small and large.

Tying it all together - A step-by-step guide to making the right decision

Above, we covered high-level considerations you should take into account when deciding. Now, I want to give you concrete steps you can take as you decide.

Step 1: Define requirements

The first thing you need is to fully understand what you require from your authorization layer. That can be broken down into two categories of questions you need to answer, before you start defining your best-fit solution.

Category 1: Application-level requirements

• How many attributes will you need to consider? These can include roles, departments, cost centers, risk scores, subscriptions - anything relevant to the user or the resource.
• How dynamic are these policies going to be?
• What level of audit logging is required to meet the compliance team's needs?

Category 2: Technical-level requirements

• How many languages/frameworks/services do you need to support?
• How many different deployment models do you have to support? You might have some part of your system in Kubernetes, some other part of your system in AWS Lambda, and some other part of your system in bare metal or on-prem.
• Which upstream identity provider (IdP) does it need to connect with?
• Where is the user to role assignment going to be stored or managed (if not in the IdP)?

Whether you choose to roll your own or purchase, your authorization layer will need to support these requirements.

Step 2: Evaluate resources

Before making your decision, you need to know what resources you have in place, and if they’re sufficient to successfully implement your solution. That starts with an evaluation of your internal expertise and available engineering bandwidth.

If you’re choosing to build your authorization in-house, you need to know if your team is capable of not just building it, but if they can secure it, minimize future technical debt during the build and adapt it to changing application architectures.

Then, you have to make sure that you can keep that technical expertise. That means you need at least two experts so that if one leaves the second maintains the expertise and is able to pass it on. Without this overlap, your team will end up with a knowledge gap as the average employee turnover is 3-5 years.

Step 3: Run a proof of concept

Once you’ve defined your requirements and evaluated your resources, you should be able to narrow down your choices for solutions, including vendors and your ability to build in-house. The next step is to run a limited proof of concept with your top solutions to see what approach fits your needs better.

During the proof of concept, your team should be asking:

• Does it address the issue you have at hand?
• Can your business requirements be modeled in policy?
• Does it address any future requirements you may need? This should include asking:
  • Is it flexible enough?
  • How easily can it handle any future issues your team sees?
• Does it fit into your architecture?
• Is it fast enough? Every request goes through authorization. So, you want to make sure that as the load increases and you scale up, it will still be fast.
• Does it have a good developer experience? Was it breezy or was it a struggle? Because any struggle during the proof of concept phase is a symptom of future pain.

Step 4: Think long-term

After you’ve determined that you can meet today’s requirements with your chosen software, you have to look to the future to determine whether your chosen solution will work for you down the road.

That means considering maintenance, scalability, and compliance.

With regard to maintenance - if you choose to buy an authorization layer, the vendor’s team will be responsible for keeping the software up to date. However, if you choose to build your own, your team has to be able to maintain your code going forward. That means you need to have a team with the expertise to keep operating libraries and other aspects of your build.

Unless your need for authorization is strictly constrained to those 3-4 roles, any authorization you choose will have to scale to meet your future use cases. That means you need to know how your software will grow, and what it will require in the future. Then, find solutions that will help you scale into the future, without holding you back.

Before you sign off on a solution, you need to know if your compliance team will be happy moving forward. If the solution you’re looking at doesn’t satisfy compliance, your development team will spend a significant amount of time adding features to satisfy their requirements. If you built your own, that means even more hours adding features added on to the timeline.

Parting thoughts

When you’re looking for an authorization solution, it’s easy to see the roadblocks for buying off-the-shelf. There are always specific requirements and custom needs your software will have. But for most companies, it will be easier to take something pre-made and make it work, rather than to start from scratch.

Of course, there are situations where rolling your own makes sense, including internal roadblocks, or simple requirements that you can hard code without causing issues down the road. If that is the case for you, feel free to check out our ebook on building your own scalable authorization system. But, for most teams, finding reasons to go with a solution like Cerbos will save time, reduce risk and ensure they can scale seamlessly.

Get in touch to find out how Cerbos can help you bypass the risks and struggle of building your own, with an off-the-shelf authorization layer - book a call with a Cerbos engineer, or join our Slack community.