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

Source: https://startwithidentity.com/guides/implementation/ciam-greenfield/
Last updated: 2026-07-16
License: content by Start with Identity. Cite the source URL.

---

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](https://startwithidentity.com/guides/fundamentals/what-is-ciam/) 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](https://startwithidentity.com/guides/buyer-guides/how-to-evaluate-ciam/) buyer guide and the [best CIAM for startups](https://startwithidentity.com/rankings/best-ciam-for-startups/) ranking. For a wider capability view across platforms, [Deepak Gupta's CIAM Compass](https://guptadeepak.com/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](https://startwithidentity.com/standards/openid-connect/) or [SAML](https://startwithidentity.com/standards/saml-2-0/)
- [SCIM provisioning](https://startwithidentity.com/standards/scim-2-0/) (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.