SSO (meaning SAML and optionally SCIM) is one of those features that founders ship prematurely and regret, or ship late and stall deals. Here’s how to time it right.
The signs it’s too early
- No customer has actually asked for it
- Your target ACV is below $10K/year
- Your buyers are solopreneurs or small teams
- You’re shipping SSO because “we should look enterprise-ready”
If any of those are true, SSO is a time sink. You’ll spend 4-8 weeks on a feature zero customers use, while your actual roadmap suffers. Don’t.
The signs it’s overdue
- A qualified prospect is on a trial and asks, “do you support SAML?”
- Deal sizes are creeping past $20-30K ARR
- A customer is negotiating and brings up their security questionnaire with SAML/SCIM as requirements
- You’re in security reviews where “SSO support” is a line item
At this point, every week without SSO is delayed revenue.
The sweet spot
Somewhere between “no one’s asked” and “deal on hold.” Specifically:
- You’ve seen the question in 2-3 discovery calls
- Your target ACV is moving into five figures
- You’re starting to talk to IT teams as part of the sales process
This is when you start the work. Not before, not after.
Architect for it, don’t build it
You can be “SSO-ready” without having SSO. Here’s what that means concretely:
1. Tenant-aware user model
Every membership has a tenant_id. Every query filters by tenant. Users can belong to multiple tenants. This is the foundation — you want it regardless of SSO.
2. auth_provider column on memberships
Values: local, google, saml:tenant-123, scim:tenant-123.
A user signed in via email/password has auth_provider=local. A user who was provisioned via SCIM has auth_provider=scim:tenant-123. The column tells you where their identity comes from.
3. Email as metadata, not identifier
The identifier is (tenant_id, auth_provider, subject_id). Email is displayable data. This means a user can have the same email across multiple tenants with different identities.
4. Don’t let SSO users change their own email
If a user’s auth_provider is saml:* or scim:*, the email is read-only in your app — it’s owned by the customer’s IdP.
Doing these four things from day one means when a customer asks for SSO, you build the SAML integration (2-3 weeks with a good library) on top of a model that already fits. If you skipped these, you’re doing a model migration under deal pressure, which is the worst possible time.
The implementation
When the time comes, don’t hand-roll SAML. The XML canonicalization bugs alone will consume weeks, and the second IdP you integrate against (Okta, Entra, whatever) will break your edge cases in ways the first didn’t. Use a library, or better, outsource the whole SAML/SCIM layer to a managed provider that already supports every major IdP.
That’s the layer LoginWith specifically handles. Our Enterprise SSO & Directory Sync add-on plugs SAML and SCIM into your existing LoginWith setup — one integration, every customer IdP, priced per enterprise connection. You ship the deal in days, not months, and only pay when you have an enterprise customer to pay for.
SCIM
SCIM (automatic user provisioning from the IdP) often comes up at the same time as SAML. Frame it as “zero-touch onboarding” when you sell it — customers don’t care about the protocol, they care that their 500 employees don’t need individual invites. Ship it when the second enterprise customer asks; not before.
The bottom line
Be SSO-ready architecturally from day one. Build SSO reactively when the first deal requires it. Price it as a paid add-on — that’s the industry pattern and reflects the real cost of maintaining one integration per customer IdP.
Too early is wasted effort. Too late stalls deals. The signal is the discovery call, not the internal ambition.