A mid-level engineer can build a basic auth system in 2-3 weeks. That’s the visible cost. The invisible cost — the one that doesn’t show up in any planning document — is maintenance over the next five years.
What “done” actually looks like
When you ship auth, the first release handles:
- Sign-up, sign-in, sign-out
- Password reset
- OAuth via Google and GitHub
- Session cookies
- Basic RBAC
Total code: maybe 2,000 lines. Maybe 2-3 dependencies. Ship it, move on.
Six months later:
- A new OAuth provider customer request (another 2 days of integration)
- GitHub rotates their API and breaks your flow (1 day to fix, 1 day to regression-test)
- A credential stuffing attack hits you, you need account rate-limiting (3 days)
- A customer asks for SSO via SAML (2 weeks)
- Chrome changes its cookie defaults and your cross-domain flow breaks (1 week to debug, 3 days to fix)
Eighteen months later:
- SOC 2 auditor wants audit logs on all auth events (1 week)
- Customer asks for SCIM (4 weeks)
- Your password hashing is behind current best practice, need to migrate (2 weeks)
- A vulnerability in a dependency surfaces, needs urgent update (2 days plus PagerDuty)
The math
A typical maintenance trajectory looks like 15-25% of one engineer’s time, forever. At $120K/year fully loaded for a senior engineer, that’s $18-30K per year of ongoing work on the auth system. Across five years: $90-150K.
Plus, opportunity cost. Every hour your engineer spends on auth is an hour not spent on your actual product. In early-stage companies, that tradeoff is lethal.
What managed auth costs
A managed auth provider at the scale of a typical SaaS (say 5,000-20,000 managed users) costs $2-10K per year. In exchange:
- They handle provider API changes
- They handle security patches
- They keep up with OAuth/OIDC standard updates
- They offer SAML and SCIM when you need them
- They pass your SOC 2 and ISO 27001 audits as a subprocessor
The math favors buying, past MVP, in almost every case.
When to build anyway
Build your own if:
- Auth is literally your product (you’re selling an identity product)
- You have an unusual regulatory requirement no vendor supports
- You have the engineering capacity and believe the cost math works for your specific case
Build your own sometimes:
- Early MVPs, to avoid vendor lock-in risk
- Internal tools where simplicity trumps everything
Don’t build your own because:
- “It’s just authentication, how hard can it be?” — this is the trap
- You read a blog post about a vendor’s pricing
- You want to learn. Learn on a side project, not production auth.