Every developer has thought about building their own auth. It’s tractable — every blog post, every standard library, every tutorial makes it look approachable. And it is approachable. The trap isn’t the initial build. It’s the next five years.
The initial build is the easy part
Shipping v1 of a home-grown auth:
- Sign up, sign in, sign out: 1 week
- Password reset, email verification: 1 week
- One OAuth provider: 1 week
- Session management, rate limiting: 1 week
- Basic tests: 1 week
That’s 5 weeks of engineering time, maybe 3 if the team is senior. The code is public — every pattern is documented. You can do it.
This is why “build our own auth” keeps coming up in planning meetings. One engineer can carry it to launch.
The build cost is 10% of the five-year cost
Here’s what most build-vs-buy analyses miss. Over five years:
Year 1: ongoing maintenance (~5 weeks)
- Provider API changes (Google rotates something, GitHub ships a breaking change): 2 weeks across the year
- Bug fixes and edge cases customers report: 1-2 weeks
- Feature additions (new provider, MFA, magic links): 1-2 weeks
Year 2: compliance (~4-6 weeks)
- SOC 2 audit preparation and remediation: 2-4 weeks
- Audit log completeness, session termination rules, key rotation: 1-2 weeks
Year 3: enterprise features (~8-12 weeks)
- First SAML integration: 3-4 weeks
- First SCIM integration: 4-6 weeks
- Enterprise-specific compliance (HIPAA, PCI): variable, usually 1-2 weeks
Year 4-5: scale issues and standards drift (~6-10 weeks/year)
- Standards updates (OAuth 2.1, WebAuthn, FIDO2): 2-4 weeks
- Scale-related refactors (session store migration, rate limiting tuning): 2-3 weeks
- New compliance frameworks: 2-3 weeks
Total over five years: 5 + 5 + 6 + 12 + 8 + 8 = ~44 engineer-weeks of ongoing auth work. At a fully-loaded senior engineer cost of $2,500/week, that’s ~$110,000 over five years — not counting the initial $12-15K build.
The opportunity cost is larger
Engineering time is zero-sum. Every hour on auth is an hour not on your product. For an early-stage startup, this is the bigger number. What would your product look like if you’d shipped 1-2 more features per year instead of maintaining auth?
For a seed-stage company, that could be the difference between closing Series A and missing it.
The security risk isn’t theoretical
Home-grown auth systems have vulnerabilities that managed providers patch centrally:
- Session fixation (20-year-old bug, still in new code)
- Weak password hashes (MD5, SHA-1, or bcrypt with low work factor)
- JWT implementation bugs (alg=none, unverified signatures)
- Timing attacks on token comparison
- Missing revocation on privilege changes
A managed provider has one team of specialists fixing these centrally. Your team fixes them one at a time, as incidents happen.
When building makes sense
There are real cases for building your own:
- Authentication is your product. You’re building Auth0, Clerk, or Ory. Yes, build.
- Regulatory constraints no vendor can meet. Air-gapped deployments, specific data residency requirements.
- Compliance cost of a vendor exceeds a full-time engineer. Rare.
- You’re a massive platform with unusual scale requirements. Google, Apple, etc. build their own. You probably aren’t Google.
For essentially every other team, buying is the right answer past MVP. The math isn’t subjective.
The MVP exception
At MVP stage, “rolling our own auth” is often fine:
- You’re pre-revenue
- You have one developer
- You want to defer any recurring cost
- Your auth needs are just “users have emails and passwords”
Build the simplest possible thing for MVP. Plan to migrate to a managed provider around the time you hit product-market fit — the migration is easier when you have 100 users than when you have 10,000.
The five-year decision
For a product with a five-year horizon: buying managed auth costs you $10-30K total and zero engineering weeks past the initial integration. Building costs you $110K and consumes 44 engineer-weeks you can’t get back.
The decision isn’t close.