The Hidden Cost of Building Auth From Scratch
Every SaaS team convinces themselves auth is a one-weekend job. Build a login form, hash passwords with bcrypt, slap on a JWT, ship it. Two years later, the same team is deep in a security incident postmortem, trying to explain to customers why session tokens weren’t rotated after a credential leak.
Auth is not a weekend job. It never was. Here’s what it actually costs.
The obvious costs
The MVP is real but small. Login, signup, password reset, basic session management. A solid engineer can do this in 3–5 days.
Then come the real requirements:
- Multi-tenancy — account isolation, workspace switching, member roles
- OAuth — GitHub, Google, Discord. Each provider has its own edge cases
- Magic links — Turns out users hate passwords more than you expected
- MFA — TOTP, backup codes, recovery flows
- Session management — concurrent sessions, forced logout, device tracking
- Rate limiting — Brute-force protection that doesn’t lock out legitimate users
- Audit logs — Who logged in from where, when. Required for any enterprise deal
That’s not a weekend. That’s a quarter, for one experienced engineer working full-time on auth alone.
The invisible costs
Time isn’t even the biggest problem. The bigger problem is maintenance debt.
Auth code has the highest cost-of-wrong in the entire codebase. A bug in your billing code loses you money. A bug in your auth code loses you customers, trust, and potentially your company. The security surface is large and constantly expanding — new attack vectors, new OAuth deprecations, new compliance requirements.
Most teams assign auth to whoever is available, not whoever is most qualified. Then that person leaves. The code stays, but the understanding of why each decision was made disappears with them.
What “good enough” actually requires
If you want auth that won’t embarrass you in a security audit or enterprise procurement process, you need:
- Password hashing with Argon2 or bcrypt with work factor tuning
- Constant-time comparison for sensitive values
- CSRF protection for cookie-based sessions
- Secure cookie attributes (
HttpOnly,Secure,SameSite=Lax) - Token rotation on privilege escalation
- Rate limiting that is IP-aware but not trivially bypassable
- Refresh token families to detect theft
- Webhook/event system so downstream services stay in sync
Most teams don’t ship all of this. They ship half of it, call it done, and discover the gaps the hard way.
The actual alternative
This isn’t an argument for any particular auth provider. It’s an argument for honest accounting. When you decide to build auth yourself, you’re not just spending two days on a login form — you’re committing to owning security infrastructure indefinitely, with all the ongoing costs that implies.
The teams that move fastest are the ones that are honest about where they have leverage and where they don’t. Auth is rarely a competitive differentiator. The thing your users care about is what happens after they log in.