The Authorization TCO Framework from Oso
Cut through the guesswork. This framework helps you calculate the real costs of building, self-hosting, or buying authorization.
Authorization is one of the hardest problems to scope—and one of the easiest to underestimate.
This framework helps you calculate its Total Cost of Ownership (TCO) across every phase of the authorization lifecycle, giving you the clarity to make smart, long-term decisions about whether to build, self-host, or buy a fully-managed solution.
Why a TCO Framework?
When you start building your apps and services, authorization requirements are typically easy to address. But over time, authorization questions and logic become more complex.
If you find yourself answering “YES” to any of the following, it's time to start evaluating what comes next.
Are you still relying on hard-coded roles buried deep in your app code?
Are business stakeholders frustrated by how long it takes to ship new features?
Do you need more than RBAC — e.g. ReBAC, ABAC, custom roles, field level access — to handle increasingly sophisticated needs?
Are you trying to integrate access controls across LLMs and vector databases?
Are you juggling access control across tenants, teams, and services?
Are you risking security due to fragile edge cases?
You’ll weigh technical and organizational tradeoffs based on your stack, your team, and your growth stage. But one factor cuts across every decision: total cost of ownership. Until now, there’s been no consistent, reliable way to measure it.
That’s why we built the Oso TCO Framework for Authorization—breaking TCO into clear, comparable categories across the full project lifecycle.
Comparing potential authorization options
There are four options most engineering teams consider as they plan their authorization strategy. Understanding the TCO of each option is a crucial factor in your decision making. Therefore we compare these options across each phase of the authorization lifecycle in the TCO framework below.
Oso
Use the fully-managed authorization service from Oso
Authorization Lifecycle Phases
The following tables estimate the full lifecycle cost of an authorization solution—spanning development, deployment, and ongoing operations.
These estimates are based on patterns the Oso team has observed across hundreds of customer engagements.
Lifecycle Phase: Development
The development phase covers the foundational work of designing and implementing the authorization system—defining the model (or building it from scratch for custom solutions), mapping query patterns, and ensuring data stays synchronized between the application and authorization layers.
The values in each Solution column represent engineering-months (number of engineers × months required to complete the activity).
Development activity & key considerations | Build it yourself | Self-hosted solution | Managed solution | |
|---|---|---|---|---|
Authorization model
| 18 | 12 | 12 | 1 |
Data model
| 3 | 2 | 2 | 0 |
Query patterns
| 9 | 6 | 6 | 0 |
Data sync
| 13 | 8.5 | 8.5 | 1.5 |
Data reconciliation
| 4 | 2.5 | 2.5 | 0.5 |
Total Engineering Months | 47 | 31 | 31 | 3 |
Lifecycle Phase: Operational and Deployment Readiness
This phase accounts for the engineering effort required to make an authorization system production-ready. It includes building out performance optimizations, ensuring high availability, auditing activity in the system, and executing on a developer adoption strategy.
Development activity & key considerations | Build it yourself | Self-hosted solution | Managed solution | |
|---|---|---|---|---|
Performance optimization
| 12 | 8 | 1 | 0 |
Uptime and reslilience
| 16 | 10.5 | 4 | 2 |
Auditing
| 9 | 6 | 2 | 1 |
Developer adoption
| 8 | 5 | 2 | 1 |
Total Engineering Months | 45 | 29.5 | 9 | 4 |
Lifecycle Phase: Ongoing Solution Effort
Ongoing costs capture the long-term investment required to operate, maintain, and extend the authorization system after initial deployment. This includes on-call support, handling internal developer requests, bug fixes, system upgrades, and the infrastructure required to keep the system performant and reliable at scale.
Cost metrics are expressed as the number of engineering FTEs required per annum, along with the annual recurring costs for systems infrastructure.
Development activity & key considerations | Build it yourself | Self-hosted solution | Managed solution | |
|---|---|---|---|---|
Maintenance and ops
| 2 | 2 | 1 | 0.5 |
Infrastructure
| $ required | $ required | Included in service cost | Included in service cost |
3-Year Authorization TCO Estimate
As the table below shows, compared to a custom solution…
What’s more, Oso requires 85 fewer engineering months (that's 7 engineering years) when compared to the custom solution!
The following table consolidates efforts and costs across each phase of the authorization lifecycle, normalizing them to 100% of the 3-year cost for the custom solution (the most expensive option).
Cost category | Build it yourself | Self-hosted solution | Managed solution | |
|---|---|---|---|---|
Development (eng-months) | 47 | 31 | 31 | 3 |
Deployment (eng-months) | 45 | 29.5 | 9 | 4 |
Ongoing (eng FTEs + infrastructure costs per annum) | 2 FTEs + infrastructure costs | 2 FTEs + infrastructure costs | 1 FTE + service cost | 0.5 FTE + service cost |
3-Year Total Cost of Ownership | 100% | 68% | 39% | 17% |
Why is Oso's TCO so much lower than other authorization solutions? The table below summarizes the key cost drivers for each solution.
Build a custom solution
Provides for maximum control—but expect high upfront costs, long timelines, and a growing support burden. It takes a dedicated team to build and maintain.
Self-host dedicated authorization software
Open source options— often loosely inspired by high-level ideas from Google Zanzibar—offer a starting point. But they still require significant custom development to get production-ready. You'll need to adapt to their ReBAC-only models, build around query limitations, and create your own data sync and drift-handling tooling. You’ll also need to build and manage all of the operational concerns in running the service for your apps.
Use a hosted service
These services, based on the loosely Zanzibar-inspired systems mentioned in option 2 above, reduce operational overhead compared to self-hosted solutions. But they still require custom development to match the ReBAC-centric design and overcome the list filtering limitations discussed earlier. As with any managed service, a third-party dependency is introduced on the application’s critical path.
Fully-managed authorization service
Purpose built for application authorization, it comes with native support for RBAC, ReBAC, ABAC models. Unlike the managed Zanzibar imitations, Oso allows teams to keep authorization data local to the application tier as needed, limiting and in many cases avoiding the need to centralize authorization data. It also supports the most complex queries and list filtering use cases natively. The third party dependency noted for the fully managed Zanzibar-like solutions also applies to Oso.