In short
Build SSO when a real deal depends on it, not before. It is substantially more work than it appears — provider quirks, testing against systems you do not control, and the adjacent expectations of directory sync, role mapping and audit logging that arrive with it. Until then, the account model should simply be designed so a user can hold multiple authentication methods.
What buyers actually mean
When an enterprise buyer says they need SSO, they usually mean a bundle:
Central authentication, so employees sign in with the company identity provider rather than another password.
Centralised access control, so IT can grant and revoke without contacting you.
Immediate offboarding. When someone leaves, access ends everywhere at once. This is frequently the real driver — it is a security requirement rather than a convenience.
Audit visibility, so they can demonstrate who had access to what.
Notice that only the first is a login feature. The rest are administrative, and they are what makes the work larger than it looks.
Why it is bigger than it appears
Providers behave differently. SAML is a standard that implementations interpret variously. Testing against one provider does not mean the next will work, and you cannot test against a customer's instance before they are a customer.
You cannot control the other side. Configuration lives in the customer's identity provider, administered by their IT team. Debugging a failed assertion with someone who cannot share the configuration is a genuine support burden.
Account linking is subtle. What happens when someone already has a password account and their organisation enables SSO? When they leave and join another customer? When their email changes? These questions have real answers and none are obvious.
The adjacent expectations arrive with it. Directory sync to provision and deprovision automatically. Role mapping from their groups to your permissions. Audit logs. Domain verification so a customer can claim their email domain. Enforcement, so users cannot bypass SSO with a password.
That last one matters: SSO without enforcement provides little of the security benefit, because the old password still works.
The cost of building it early
It is the most commonly over-built feature in early products, and the cost is not only the build.
It is ongoing support for configurations you cannot see. It is a code path used by a small fraction of users that must keep working. It is the identity model becoming more complex for everyone.
And it is opportunity cost — weeks spent on infrastructure for a customer who does not yet exist, while the product problems that would win customers wait.
Build it when a deal depends on it
The rule that saves money: when a real customer with a signed intent requires it.
This is not stalling. It gives you something valuable — a specific provider to build against, a real administrator to test with, and a definition of done that comes from a requirement rather than a guess.
It also lets you charge for it. SSO is conventionally a higher-tier feature, and building it against a paying customer makes that straightforward rather than awkward.
When asked before that point, the honest answer works: we support it on our enterprise plan and implement it during onboarding. Buyers accept this far more often than teams expect.
What to do in the meantime
Design the account model to allow it. A user should be able to hold several authentication methods against one identity, and an organisation should be a real entity in your data model rather than implied by email domain. Retrofitting organisations later is genuinely painful.
Build the adjacent things that are useful anyway. An audit log is valuable to any customer. Role-based permissions are needed regardless. Both are asked about in the same conversations as SSO and are useful immediately.
Offer what you can now. OAuth with Google or Microsoft covers a real portion of what smaller organisations want, and is a fraction of the work — as covered in choosing an authentication method.
Buy rather than build
When the time comes, using an identity provider that handles the protocol work is usually right.
They have tested against the providers you have not, they absorb the differences, and they carry the maintenance. The cost is a dependency in your authentication path and a per-user fee at scale.
Building it yourself makes sense when you have unusual requirements, when the per-user cost becomes significant, or when authentication is genuinely core to your product. For most teams shipping SSO for a first enterprise customer, buying is the right call.
The scoping conversation
When a customer asks, get specific before estimating: which identity provider, do they need automatic provisioning or is just-in-time acceptable, do they need group-to-role mapping, do they require enforcement, and do they need audit export.
Each of those is a different size of project. "We need SSO" spans a week and a quarter, and the difference is entirely in those answers.
If you are being asked for SSO and want to scope it honestly before committing to a date, book a call.
Common questions
When should a product add SSO?
When a real customer with signed intent requires it. Before that you are building identity infrastructure for a customer who does not exist, and you cannot test against their provider anyway. Waiting also gives you a concrete definition of done and makes charging for it straightforward.
What do enterprise buyers mean when they ask for SSO?
Usually a bundle: central authentication, centralised access control so their IT can grant and revoke without contacting you, immediate offboarding when someone leaves, and audit visibility. Only the first is a login feature — the rest are administrative and are what makes the work larger than it appears.
Why is SSO more work than it looks?
Identity providers interpret the standards differently, so testing against one does not mean the next works. The configuration lives in the customer's system where you cannot see it, account linking has subtle edge cases, and adjacent expectations arrive with it — directory sync, role mapping, audit logs and enforcement.
What should I build instead of SSO early on?
Design the account model so a user can hold several authentication methods and an organisation is a real entity rather than implied by email domain, since retrofitting that is painful. Then build the adjacent things useful to everyone — audit logging and role-based permissions — and offer OAuth with Google or Microsoft.
Should I build SSO myself or use an identity provider?
Buy, for most teams shipping it for a first enterprise customer. Identity providers have tested against the systems you have not, absorb the differences between them, and carry the maintenance. Build it yourself only for unusual requirements, at scale where per-user fees matter, or when authentication is core to the product.
