Building vs. Buying Access Management Infrastructure

The make-or-buy decision that will define your next two years.

The question lands in a CTO’s inbox on a Tuesday afternoon: “Should we build our own access management system or buy one?”

This decision will define the next two years. Get it right, and the organization gains scalable, maintainable access control. Get it wrong, and engineering teams spend those years maintaining a system that should have been purchased—or paying for a platform that cannot be customized.

The stakes warrant a rigorous decision framework.

The Build Temptation

Engineering teams gravitate toward building for predictable reasons.

“It’s just CRUD operations.” Create user, add to group, remove from group. The apparent simplicity masks the iceberg beneath the surface.

“We have unique requirements.” Every organization believes its structure is special, its security model different, its compliance needs complex. This belief is rarely validated against what commercial platforms actually support.

“We can’t find a vendor that does X.” A single missing feature becomes justification for building everything from scratch—a classic false economy.

“We have the engineering talent.” Smart engineers on staff, excited to build, eager for the learning opportunity. But capability does not equal optimal allocation.

“Vendors are expensive.” The $50K- $200K annual license fee looks daunting against a mental estimate of internal development costs. That mental estimate is almost always wrong.

These reasons are seductive. They are also usually incorrect.

What Building Actually Means

Year 1: Initial Development. Two engineers assigned full-time for six months. They design the data model, build the policy engine and orchestration layer, integrate with the first five systems (Okta, Google, AWS, Slack, GitLab), construct the admin UI, implement audit logging, and write documentation.

Cost: 2 engineers multiplied by 6 months multiplied by $150K salary equals $150K.

Delivered: An MVP that handles basic use cases.

Year 2: Production Hardening. Reality arrives. Edge cases emerge that no one anticipated. Performance degrades at scale. Ten more systems need integration. Security vulnerabilities surface. Users request features the MVP lacks.

One engineer now maintains and enhances full-time: 30% on bug fixes, 40% on new integrations, 20% on performance optimization, 10% on new features.

Cost: 1 engineer multiplied by 12 months multiplied by $150K equals $150K.

Year 3+: Ongoing Maintenance. The system is now “mature” but still demands attention. Vendor APIs change. New tools get adopted. Security patches accumulate. Performance requires tuning. Business units request features.

Cost: 1 engineer at 50% time multiplied by $150K equals $75K per year indefinitely.

Three-Year Total Cost of Ownership: $375K.

The organization receives a system that delivers 70% of what commercial platforms provide, creates an ongoing maintenance burden, concentrates knowledge in a small team (what happens when that engineer leaves?), offers no vendor support, and connects to no community.

What Organizations Actually Build

The “just CRUD” assumption collapses under examination. A real access management system requires eight distinct components.

A Policy Engine. What appears simple quickly reveals its complexity:

# Seems simple
def should_have_access(user, resource):
    if user.department == "Engineering":
        return True
    return False

# Actually complex
def should_have_access(user, resource):
    # Attribute-based logic
    policies = get_applicable_policies(user)
    for policy in policies:
        if policy.matches(user.attributes):
            if resource in policy.grants:
                # Check exceptions
                exceptions = get_active_exceptions(user)
                # Check graceful deprecation
                deprecated = get_deprecated_access(user)
                # Check conditional keeps
                conditions = evaluate_conditions(user, resource)
                # Handle inheritance
                inherited = resolve_inherited_policies(policy)
                # Calculate final access
                return calculate_access(
                    policy, exceptions, deprecated,
                    conditions, inherited
                )

An Orchestration Engine. Dependency graphing (Group A requires Group B), parallel execution (provision to five systems simultaneously), retry logic (exponential backoff), rollback (undo partial failures), state tracking (pending versus complete), and idempotency (safe to retry).

Integration Adapters. One adapter per system—Okta, Google, AWS, Slack, GitLab, Salesforce, and more. Each adapter handles authentication (OAuth, API keys, SAML), rate limiting (different per vendor), pagination (different per vendor), error handling (different per vendor), webhooks (if supported), and bulk operations (if supported).

Organizations need 15-20 adapters. Each takes 1-2 weeks to build properly.

Continuous Compliance. Daily drift detection, policy-versus-reality comparison, automatic remediation, audit trail generation, and compliance reporting.

Exception Management. Request workflow, approval routing, expiration tracking, auto-revocation, and extension requests.

Graceful Deprecation. Ruleset transition logic, grace period management, downgrade rules, and conditional keeps.

An Admin UI. User management, policy editor, exception dashboard, audit log viewer, and reporting.

Security. Authentication (for admins), authorization (RBAC for admin actions), audit logging (immutable), encryption (at rest and in transit), and secrets management (API keys and credentials).

This is not a six-month project. This is a two-year project.

The Hidden Costs of Building

Opportunity Cost. Two engineers for six months equals one engineer-year. What else could they have built? Revenue-generating features. Infrastructure improvements. Technical debt reduction. Customer-requested enhancements. The value of alternatives: $300K- $500K conservatively.

Time to Value. The build approach spans months 0-6 for development, 6-9 for testing, 9-12 for rollout. Time to value: 12 months. The buy approach spans months 0-1 for vendor selection and 1-3 for implementation. Time to value: 3 months.

Nine months of delay equals nine months of manual access management costs. At $1.4M per year for manual access (calculated in Article 20), that represents 9 months multiplied by $116K per month: $1.05M in delayed savings.

Maintenance Burden. Year 2 onward, organizations need 0.5-1.0 FTE maintaining the system forever. With a vendor approach, the vendor maintains the platform; the organization maintains integrations (a much smaller surface area).

Ten-year maintenance cost difference: Build totals 10 years multiplied by $75K per year equals $750K. Buy totals 10 years multiplied by $20K per year (integration maintenance) equals $200K. Difference: $550K.

Knowledge Concentration Risk. The engineer who built the system leaves. Options: hire a replacement (3-6 months to find, 3-6 months to onboard equals 6-12 months of reduced capability), cross-train an existing engineer (3-6 months while the system stagnates), or rebuild with a new approach (another 6-12 months). Risk cost: $100K- $300K. With a vendor approach, the vendor maintains institutional knowledge. Integration knowledge transfers much more simply.

Build-versus-buy decisions carry compliance implications. Custom-built systems require organizations to demonstrate control effectiveness independently—no vendor certifications to reference. Commercial platforms typically provide SOC 2 reports and compliance documentation that auditors accept as evidence. Building internally means owning the entire compliance burden for that system.

When Building Makes Sense

Build if the organization is in the identity/access business. The product IS access management. The company is building an IGA platform or developer tools for identity.

Build if requirements are truly unique—not “we do things differently” (everyone does), but more like “we integrate with proprietary internal systems that no vendor could support.” Examples: custom mainframe integration, proprietary hardware systems.

Build if excess engineering capacity exists. Engineers with free time (rare). Engineering bandwidth is not a constraint. The organization can afford 1+ FTE indefinitely.

Build if vendor solutions don’t exist. Emerging market. No vendors support the niche. Ten or more vendors have been evaluated, and none fit.

Organizations answering “yes” to three or more of these conditions should consider building. Otherwise, buy.

When Buying Makes Sense

Buy if the organization is not in the identity business. The product is SaaS, e-commerce, fintech, healthcare, or similar. Identity is infrastructure, not differentiation.

Buy if requirements are normal: HRIS integration, policy-based provisioning, multi-system orchestration, audit compliance, and exception management.

Buy if engineering capacity is constrained. More features to build than engineers available. Product features need shipping. Two engineers for six months is unaffordable.

Buy if time to value matters. The solution is needed in 3 months, not 12 months. Manual access management costs $100K+ per month.

Buy if vendor support is valuable. When things break, the vendor fixes them. When APIs change, the vendor updates adapters. When new features are needed, the vendor builds them.

Organizations answering “yes” to three or more of these conditions should buy.

The Hybrid Approach

The best of both worlds: buy a platform for core functionality—policy engine, orchestration, common integrations (Okta, Google, AWS, Slack, GitLab), admin UI, and audit logging.

Build custom adapters for unique systems: internal proprietary systems, legacy applications, and niche vendors without built-in support.

This approach reaches production in 3 months (platform), allows customization for unique needs (custom adapters), minimizes maintenance burden (vendor maintains core), and reduces risk (proven platform plus custom extensions).

Vendor Evaluation Framework

For organizations deciding to buy, evaluate vendors across eight dimensions.

Feature Completeness. Policy-based provisioning, multi-system orchestration, exception management, graceful deprecation, continuous compliance, and audit trails. Score vendors 0-10 per feature.

Integration Breadth. Okta, Azure AD, Google Workspace (identity). AWS, Azure, GCP (cloud). Slack, Microsoft Teams (collaboration). GitHub, GitLab (dev tools). Salesforce, HubSpot (CRM). Custom integrations (via API). Score by number of pre-built integrations.

Customization Flexibility. Custom policies? Custom adapters? Extended data model? API available? Score 0 (locked down) to 10 (fully extensible).

Ease of Use. How long to onboard an admin? Can non-technical users manage policies? Is the UI intuitive? Score based on trial/demo.

Performance and Scale. Users supported? Systems supported? Provisioning speed? Rate limits? Score based on vendor specs and customer references.

Pricing Model. Per-user pricing, flat-rate pricing, or usage-based pricing. Score based on total cost for the organization’s scale.

Vendor Viability. Years in business? Customer count? Funding? Roadmap? Score based on research.

Support Quality. Response time SLA? Dedicated support engineer? Community forum? Documentation quality? Score based on trial support experience.

Build vs. Buy Decision Matrix

Factor	Weight	Build Score	Buy Score
Time to value	20%	3/10 (12 months)	9/10 (3 months)
Total cost (3 years)	20%	4/10 ( $375K)	7/10 ( $200K)
Maintenance burden	15%	3/10 (1 FTE)	8/10 (0.2 FTE)
Feature completeness	15%	5/10 (70% of features)	9/10 (95% of features)
Customization	10%	10/10 (unlimited)	6/10 (API-based)
Risk	10%	4/10 (knowledge concentration)	8/10 (vendor dependency)
Engineering capacity	10%	2/10 (2 engineers, 6 months)	9/10 (0.5 engineers, 3 months)

Weighted average: Build: 4.35/10 (43.5%). Buy: 8.25/10 (82.5%).

Recommendation: Buy.

Real-World Examples

Company A: Built Their Own (Regret)

Profile: 600 employees, e-commerce company, engineering team of 40 people.

Decision: Build custom access management.

Timeline: Year 1 consumed 2 engineers for 9 months to reach MVP. Year 2 required 1 engineer for 12 months on production hardening. Year 3 needed 1 engineer at 50% time for maintenance.

Outcome: The system works but remains fragile. Every API change breaks integrations. Features are limited—no exception management, no graceful deprecation. Engineers resent maintaining a boring internal tool. The CTO regrets the decision.

Retrospective from their team: “We should have bought a platform. We spent $400K+ over 3 years and got 60% of what Provisionr does out of the box. Our engineers should have been building product features.”

Company B: Bought Platform (Success)

Profile: 800 employees, SaaS company, engineering team of 50 people.

Decision: Buy Provisionr (or similar).

Timeline: Month 1 for vendor selection (evaluated 5 vendors). Months 2-3 for implementation (0.5 engineers). Month 4 for rollout.

Outcome: Live in 4 months. 80% reduction in access requests. IT team freed for strategic work. Engineers satisfied (no boring internal tool to maintain). CFO satisfied ( $900K annual savings).

Retrospective from their team: “Nothing to change. Best infrastructure decision we made.”

Company C: Hybrid Approach (Smart)

Profile: 1,200 employees, fintech company, engineering team of 80 people.

Decision: Buy platform plus build custom adapters.

Timeline: Month 1 for vendor selection. Months 2-4 for platform implementation. Months 5-8 for custom adapters for internal systems (core banking, fraud detection, compliance).

Outcome: Platform handles 90% of systems. Custom adapters cover 10% (proprietary). Total cost: $150K (platform) plus $100K (custom adapters) equals $250K. Maintenance: $80K per year (platform) plus $30K per year (custom) equals $110K per year. Engineering capacity: 0.5 FTE ongoing (just custom adapters).

Retrospective from their team: “We would make the same decision again. The platform gave us 90% of functionality immediately. We only built what was truly unique to our business.”

The hybrid approach creates a clear control boundary: vendor-provided capabilities inherit the vendor’s compliance certifications, while custom adapters require internal control documentation. This separation simplifies audit scope—auditors can focus on the organization’s custom components rather than re-evaluating the entire platform.

The Decision Framework

Building access management infrastructure is tempting. Organizations should resist unless they have compelling reasons.

Build if: The organization is in the identity business. Requirements are truly unique (not just “we’re special”). Excess engineering capacity exists. No vendor solutions exist.

Buy if: The organization is not in the identity business. Requirements are normal. Engineering capacity is constrained. Time to value matters. Vendor support is valuable.

Hybrid approach: Buy the platform for 90% of functionality. Build custom adapters for the unique 10%.

The math: Build costs $375K over 3 years, delivers value in 12 months, creates ongoing maintenance burden. Buy costs $200K over 3 years, delivers value in 3 months, requires minimal maintenance. Buying saves $175K and delivers 9 months faster.

The decision tree:

1. Building an identity/access product? Build.
2. Unique requirements that no vendor supports? Hybrid.
3. Everything else? Buy.

Engineering pride should not drive this decision. ROI and time to value should.

---

Next up: Integrating access management with existing tech stacks—from HRIS to cloud providers to SaaS apps.

---

Evaluating build vs. buy for your company? Compare Provisionr to DIY options →