There is a moment in the life of a product where the conversation changes. You have been selling to teams who put in a card, and one day the person on the call says they will need to talk to their security group. What follows is not a discussion about your product. It is a checklist.
Single sign-on. Automated provisioning. Role separation. An audit trail their compliance team can read. None of it appears in your roadmap, none of it is why anyone chose you, and all of it stands between you and the contract.
The checklist is not arbitrary
It is tempting to read the list as bureaucracy. It is not. Every item maps to a failure that organisation has already lived through. Single sign-on exists because someone left and kept access for eleven months. Provisioning exists because a contractor's account outlived their contract. The audit trail exists because an incident review asked who did what and nobody could say.
Once you read the list that way, the requirements stop being obstacles and start being specifications. They are not asking you to be enterprise software. They are asking you not to be the weakest link in an environment they are accountable for.
They are not asking you to be enterprise software. They are asking you not to be the weakest link.
Why building it yourself is slower than it looks
The first SAML integration takes about a week if you are focused. The second takes three days. The problem is not the first ten; it is the long tail. Providers disagree about attribute names, about how groups are represented, about whether a logout request is even meaningful. None of that difficulty is visible while you are estimating.
Then the integration becomes something you own forever. Certificates expire. A customer changes tenant. A provider ships a change and one of your connections quietly stops passing group membership, and you find out from a support ticket six weeks later.
- The unit of work is not the protocol, it is the provider — and there are dozens
- The failure mode is silent: a connection that half works looks fine until it does not
- Your support team inherits the maintenance, permanently
What to do instead
Treat enterprise features as infrastructure rather than product. You would not write your own payment processor to close a deal, and the reasoning here is identical: the work is unbounded, it never differentiates you, and getting it subtly wrong is expensive in a way that is hard to see from the inside.
The point is not to avoid the work. It is to spend the week you have on the thing your customers actually bought, and to be able to answer the security questionnaire on the same call rather than a quarter later.
Everything here, already built
Sign-in, enterprise SSO, directory provisioning, roles and an audit trail behind one API. Start with the quickstart and have a working sign-in this afternoon.