Should a startup build or buy CIAM?

Buy for almost every greenfield product. Authentication looks simple but carries a long tail of security, compliance, and edge-case work: password hashing, breach monitoring, MFA, account recovery, session management, bot defense, and audit logging. A managed customer identity platform covers all of that on day one, and the free tiers cover early-stage volume. Build only if identity is your actual product.

What does a minimum viable CIAM include?

A first version covers signup, sign-in, password reset, email verification, at least one social login, a basic profile, session management, and an account deletion flow for privacy compliance. Federation with enterprise identity providers, SCIM provisioning, and custom authorization can wait until a customer requires them.

How long does it take to build customer login?

With a managed CIAM platform, a small team can ship a production-ready first version in about eight weeks: two weeks to pick a vendor and wire signup and sign-in, two weeks for verification, reset, and social login, two weeks for profile and MFA, and two weeks for audit logging, deletion, rate limiting, and hardening.

Where should you store session tokens in a web app?

Use an HttpOnly, Secure, SameSite cookie for session tokens rather than browser localStorage. Tokens in localStorage are readable by any script on the page, so a single cross-site scripting flaw exposes every user session. HttpOnly cookies are not reachable from JavaScript, which removes that class of theft.

Greenfield CIAM: how to ship the first version in 8 weeks

A greenfield product is the best time to get customer identity right, because there are no users to migrate and no legacy decisions to unwind. It is also the moment teams most often get it wrong, usually by treating login as a weekend feature. This guide is an 8-week plan to ship a real first version, plus a clear line on what to defer.

Build or buy: decide first

For a new product, buy. Customer identity looks like a login form, but the work that matters is the part you cannot see on the screen: password hashing that survives a database leak, breach and credential-stuffing defense, MFA, account recovery that is not itself phishable, session management, audit logging, and privacy-compliant deletion. A managed platform delivers all of it on day one, and the free tiers cover early volume. Build your own only when identity is the product you sell.

For picking a platform, use the how to evaluate CIAM buyer guide and the best CIAM for startups ranking. For a wider capability view across platforms, Deepak Gupta's CIAM Compass maps 40-plus platforms against a capability matrix.

What "first version" means

A working CIAM for a new product covers: signup, sign-in, password reset, email verification, social login, basic profile, session management, and an account deletion flow. Anything beyond that is phase 2. Scope discipline here is what makes the eight weeks realistic.

Week-by-week

Weeks 1-2: foundation. Pick the vendor. Spin up a free tier. Wire signup and sign-in with the SDK. Decide the session strategy early, because it is hard to change later: prefer a short-lived token in an HttpOnly, Secure, SameSite cookie over a token in localStorage. Configure separate tenants or environments for staging and production so redirect URLs and keys never cross.

Weeks 3-4: trust and reach. Email verification, so fake accounts do not pollute your data. Password reset with expiring single-use links. Social login (Google and Apple at minimum, since Apple is mandatory if you also offer other social logins on iOS). Branded transactional emails from a domain you control with SPF, DKIM, and DMARC set, or deliverability will suffer.

Weeks 5-6: profile and step-up. Profile screens and password change. MFA enrollment: TOTP authenticator apps as the baseline, with passkeys planned for phase 2. Make MFA available to all users and required for any account that touches money or sensitive data.

Weeks 7-8: production hardening. Structured audit logging for every identity event. Account deletion and data export flows for GDPR and CCPA. Rate limiting and lockout on login, reset, and verification endpoints. A load test against your expected launch traffic. A runbook for the two incidents you will eventually have: account takeover reports and a locked-out founder.

What to defer

Federation with enterprise identity providers (only when the first enterprise prospect asks), using OpenID Connect or SAML
SCIM provisioning (only when a first enterprise deal requires directory sync)
Custom auth flows and journey orchestration (default flows handle the large majority of cases)
Migration tooling (you have no users yet)
Fine-grained authorization (role-based access is enough until it is not)

Common pitfalls

Building auth in-house "because it is just a login form," then owning its security forever
Storing passwords with anything other than bcrypt, scrypt, or Argon2
Putting session tokens in localStorage where a single cross-site scripting bug drains every session
Skipping email verification "for conversion" and accepting a wave of fake accounts
Hardcoding redirect URLs so staging cannot work, then loosening them so open redirects can
Treating account recovery as an afterthought, when it is the most-attacked path in the whole system

Ship the eight-week version, watch real usage, and let phase 2 be driven by what your actual users and first enterprise buyers need, not by features you imagined at the start.