We shipped enterprise SSO in two days because we never had to build it

Our first enterprise customer made two demands that were not negotiable: single sign-on against their identity provider, and automated user provisioning. We had shipped for two years without either, on purpose, because no small business had ever asked. We delivered both in two days - not by building them, but because the authentication platform we chose in year one already carried them, switched off. Full production took a week.

Voksha is an AI receptionist. It answers the phone for businesses that cannot afford to miss a call and cannot afford a full-time person to catch them - clinics, salons, trades, small practices. Our customers are small. That fact shaped every decision we made about authentication, including the ones we deliberately did not make. This post is a first-hand account of one deal and one week of engineering; the standards involved are SAML 2.0 and SCIM 2.0.

Key Takeaways

• We shipped without enterprise single sign-on for two years on purpose. In two years of selling to independent clinics and local service businesses, not one customer asked about identity federation.
• The requirement arrived the way it always does - mid-deal, inside a security questionnaire, with two line items that were not negotiable.
• Both obvious responses were bad: building SAML and SCIM properly is a month or more, and migrating our authentication mid-deal is the riskiest change a small team can make.
• We avoided both because enterprise SSO and directory sync were already features of the platform holding our users. Enabling them was configuration - two days, with zero accounts moved and no change for existing customers.
• A week to production once SCIM webhook handling was written and tested. That part is application logic no vendor can write for you.
• The lesson is about when the enterprise requirement gets priced: a sprint if you checked at platform choice, a quarter if you meet it during a live deal.

We shipped without SSO on purpose

When you sell to small businesses, nobody asks you for SAML. In two years of selling to independent clinics and local service businesses, not one customer asked how we handled identity federation. They asked whether the AI picked up on the second ring.

So we did not build enterprise single sign-on. We did not build directory sync. Building either one properly is weeks of work - SAML has a specification with genuine sharp edges, SCIM has its own, and both have a long tail of per-provider quirks that only show up against a real identity provider in a real customer's tenant. Spending a month of a small team's time on a feature zero customers had requested would have been indefensible.

The risk in that decision is obvious in hindsight, and it was obvious at the time too. At some point a bigger customer arrives, and everything you skipped becomes a blocker on a deal that is already in motion.

Then the first enterprise customer arrived

The requirements came in the shape they always do: a security review, a questionnaire, and two line items that were not negotiable. Single sign-on against their identity provider. Automated user provisioning and deprovisioning, so that when someone leaves the company that person loses access to our product without anyone filing a ticket.

If those terms are not ones you deal with daily, this is what the enterprise was actually asking for:

Both are reasonable asks. An enterprise with hundreds of staff cannot manage accounts in your product by hand, and their security team is not going to accept "we will delete the account when you email us" as a deprovisioning story. If we could not answer, we did not have the deal.

The two obvious paths were both bad. We could build SAML and SCIM ourselves and ask the customer to wait a month or more, on a deal with its own timeline. Or we could migrate our authentication to a platform that had these features built in - which means moving every existing user, every session, every password hash, and accepting that a migration touching every account we have is the single riskiest change a small team can make while also trying to close a deal.

What actually happened

Neither, as it turned out, because of a decision we had made much earlier for unrelated reasons.

We had been running SSOJet as our authentication layer since day one. We picked it early, when the requirement was ordinary - we wanted login, sessions and user management we did not have to maintain ourselves. Enterprise SSO and directory sync were features it had. We had simply never switched them on, because nobody had asked.

So the enterprise requirement did not turn into a build. It turned into configuration. The SAML connection and the directory sync connection were features already in the platform holding our users. Enabling them did not touch our existing authentication, did not require moving a single account, and did not put our current customers at any risk at all - the small businesses using Voksha that week did not experience a change.

We delivered SSO and directory sync in two days.

The part that was actually our work

I want to be precise about this, because "two days" is the kind of number that makes engineers suspicious, and they are right to be.

Two days was the time to stand up SSO and directory sync. The real engineering on our side was SCIM webhook handling - and that part is genuinely our problem, not something a vendor can do for us. SCIM tells you that a user was created, updated, or deactivated in the customer's directory. What that means inside Voksha is application logic that only we can write. When a receptionist is deprovisioned in the customer's identity provider, what happens to the call routing they owned? To the extensions assigned to them? To their in-flight conversations?

Those questions have answers specific to our product. Writing that handler, and testing it properly against real provisioning events rather than against our own assumptions about what the events would look like, is where the time went.

Including that work and the testing around it, we were in production a week after we started.

Both numbers are true, and quoting only the first would be the dishonest version of this post. The gap between them is the work no vendor absorbs for you.

What I would tell another small team

The lesson is not "use SSOJet", although we do and it has worked. The lesson is about when the enterprise requirement gets priced.

Enterprise SSO is never urgent until it is blocking, and by the time it is blocking it sits on the critical path of a deal that is already moving. At that moment you have no good options - building takes too long, migrating is too risky, and the customer's timeline is not yours to set.

We did not avoid that trap through foresight. We avoided it because the boring infrastructure decision we made in year one happened to carry the features we needed in year two. If you are early and choosing an authentication layer today, that is the thing worth checking: not whether it does what you need this quarter, but whether the enterprise features are sitting there switched off, waiting, when the questionnaire finally lands.

The difference between those two situations is an enterprise requirement costing you a sprint instead of costing you a quarter.

One more thing, which is not about features. When we did hit questions during the SCIM work, we got answers quickly and from people who understood the protocol rather than from a ticket queue. SSOJet's support is the best support amongst all the SaaS solutions we use, and for a small team that is not a minor line item - it is the difference between a blocked afternoon and a blocked week.

How this guide was sourced

This post was written by Amit Kapoor, Co-Founder and Engineering Lead at Voksha, and reviewed by the Voksha engineering team.

It is a first-hand account, not a survey. Every figure in it - two days to enable single sign-on and directory sync, one week to production - is our own elapsed time on one project, measured from the day we started to the day the customer's staff were signing in through their own identity provider in production. There is no external benchmark here and none is claimed. Your numbers will differ with your platform, your identity provider and what a deprovisioning event has to unwind inside your product.

The customer is not named, and no figure belonging to them appears here. The security questionnaire and its requirements are described in general terms for that reason.

Disclosure: Voksha sells a 24/7 AI receptionist and answering service for small and mid-sized businesses. SSOJet is the authentication platform we pay for and run in production; this post is our account of using it, and they published their side of the same project. We were not paid to write this.

The standards referenced are SAML 2.0 and SCIM 2.0, both published specifications. Where this post describes their behaviour, it describes our experience of implementing against them rather than quoting the documents.

Frequently asked questions

What are SSO and SCIM, in plain terms?

Single sign-on lets a company's staff sign in to your product using the account their employer already controls, rather than a separate password you hold. SCIM, or directory sync, keeps the list of accounts in your product matched to that employer's staff list - a new hire gets access automatically, and a leaver loses it automatically. Enterprises ask for both because they answer two different questions: who is this person, and should they still have access at all.

Why not just build SAML and SCIM yourselves?

Reading the specifications is not where the time goes. Both are published and any competent engineer can implement the straightforward path. The cost is the gap between something that works against your own test setup and something that survives a real customer's tenant - assertions signed differently than you expected, attributes mapped in ways the spec allows but you did not anticipate, group membership arriving in a shape you reverse-engineer on a call. Then multiply that by every identity provider your customers use.

Is two days a realistic timeline for enterprise SSO?

Two days is realistic for switching on single sign-on and directory sync when your authentication platform already implements them and your users already live there. It is not realistic for building them, and it is not realistic if you have to migrate accounts first. Our honest end-to-end figure is one week, because the SCIM webhook handling on our side was real engineering.

What actually breaks when a user is deprovisioned?

Whatever that user owned. For us that meant call routing they were the destination for, extensions assigned to them, and conversations in flight at the moment the event arrived. None of that is in the SCIM specification, because it depends entirely on what your product does. Write down everything a user can own in your data model before you write the handler - that list is your specification.

Did any of this affect your existing small-business customers?

No. Because we switched on features inside the platform already holding our users, no account moved and no session was invalidated. Customers using Voksha that week experienced no change at all. That was the property that made this option viable - a migration to a different platform would not have had it, and that risk would have fallen on customers who had nothing to gain from the change.

We sell to small businesses. Do we need any of this yet?

Not today, and building it today would be a poor use of a small team's capacity - that was our position for two years and I would take it again. What is worth doing today is confirming that your authentication layer can do it later without an account migration. That is a question you can answer in an afternoon, not a project.

Conclusion

We shipped without enterprise single sign-on for two years and it was the right call. When it finally mattered, it cost us two days instead of a quarter - and that was mostly luck dressed up as a decision, because the platform we chose for ordinary reasons in year one happened to carry the features we needed in year two.

The part that was not luck is the week of SCIM webhook handling. A vendor can hand you a verified identity and a stream of provisioning events. Deciding what those events mean inside your product - what happens to the calls, the extensions and the conversations belonging to someone who no longer works there - is yours to write, and it is the more interesting problem.

If you take one thing from this: before your next infrastructure choice, ask what is sitting in it switched off. The answer costs you a sentence now and can be worth a quarter later.

We run SSOJet for authentication at Voksha. They wrote up their side of this story here.