Build vs. Buy

Everyone thinks they can build authorization. Here's what happens next.

The typical trajectory

Most engineering teams start by building authorization themselves. It's a reasonable decision—at first.

Year 1

It works. Simple roles, simple rules, one app. You feel good about the decision. The code is clean, you understand it completely, and it does exactly what you need.

Year 2

Second app needs access control. You copy-paste, then customize. Drift begins. The two implementations start to diverge. Someone asks 'why does this work differently?' and nobody has a good answer.

Year 3

Audit asks for a report you can't generate. You build a logging layer. It takes longer than expected. The auditor comes back with follow-up questions you can't easily answer.

Year 4

Customer needs row-level access. That's a 4-month project. Meanwhile, two more apps have been built with their own authorization approaches. The spreadsheet tracking who owns what is getting unwieldy.

Year 5

You're maintaining a policy engine, an admin UI, an audit system, and integrations across 12 apps. That wasn't the plan. The team that built the original system has moved on. New developers are afraid to touch it.

The hidden costs

The engine is the easy part. The hard parts are everything around it:

• Developer time that isn't going to product
• Maintenance burden that grows non-linearly
• Opportunity cost of features you didn't build
• Risk of inconsistency, gaps, and audit findings
• Knowledge concentration in a few people
• Technical debt that compounds quarterly

When build makes sense

Building authorization internally is a legitimate choice in some circumstances:

• Very early stage, single app, simple needs
• Highly unique requirements no platform addresses
• Strong internal team with authorization expertise and capacity
• Clear commitment to treating this as a product, not a side project

When buy makes sense

A platform approach typically makes more sense when:

• You have multiple apps or services needing access control
• Compliance or audit requirements are significant
• Business users need to participate in policy management
• Speed to value matters more than total customization
• You want to focus engineering on your core product