Report
Build vs. buy, two years later
We built the auth stack ourselves. Here's the bill — in engineer-months, on-call pages, and opportunity cost.
The decision
Two years ago we picked build over buy for our auth stack. The argument at the time was reasonable: SaaS pricing scaled with seats, our identity model was non-standard (B2B2C with delegated tenancy), and we had a senior engineer who had shipped auth at her last job.
This is the post-mortem, with numbers.
What it cost
| Bucket | Year 1 | Year 2 |
|---|---|---|
| Eng-months (initial build) | 7.5 | 1.0 |
| Eng-months (ongoing) | 2.0 | 3.5 |
| On-call pages (auth-tagged) | 14 | 22 |
| Vendor cost (would-have) | $48k | $96k |
The build cost stayed roughly flat. The maintenance cost did not — it roughly doubled in year two as we layered in SSO, SCIM, audit logs, and break-glass flows the original design didn't account for.
What we'd do differently
- Buy the boring 80%. Username/password, MFA, session management, and password reset are commodity. We rebuilt all of it from scratch and got no advantage from doing so.
- Build the 20% that's actually load-bearing. Tenant scoping, delegated admin, and the policy engine are still custom — and that's fine. They reflect product decisions a vendor can't make for us.
- Decide per layer, not per system. "Build vs buy" framed as a single decision pushed us into all-or-nothing. The right answer was a seam through the middle of the stack.
The real takeaway
The build decision wasn't wrong given what we knew. It was wrong given what we could have known — we under-weighted the maintenance tail and over-weighted the one-time build cost. If we'd amortised maintenance at the same rate as the SaaS line item, the numbers would have flipped a year earlier.
Architecture decisions look like one-time events. They behave like recurring subscriptions.