This. And to expand on the above: few people consider how much it actually costs to provide 12- or 4- hour support with a strict SLA. This pretty much means that the business needs to bear the full loaded cost of at least one additional employee. Now go divide that fully loaded cost (take the salary and multiply it by 2x, roughly, and I'm not quoting any numbers here to avoid stupid discussions about "but it costs less to hire a person in my area") by the number of customers that require these SLAs and see how much this needs to cost.
Support is an example of an "enterprise" feature with a high cost basis. SSO is an example of an "enterprise" feature with almost zero cost basis. But in both cases, the cost is a sideshow. The real driver for the pricing of these features is market segmentation: the customers with high expectations of support, or a requirement to have SSO, strongly tend to be less price sensitive than the rest of customers. The fundamental goal of product pricing is to find ways to charge price-insensitive customers more than price-sensitive customers.
Like, yes, you'd lose money offering 4-hour-SLA support to customers paying the entry-level price. But you could make that decision, and have part of your business model be subsidizing those customers. It depends on everything else in your model; how you acquire customers, what their lifetime value is, &c.
Making SSO a premium feature isn't any different from the paid SSL of the 2000s. You'll reduce security and safety just to segment the market.
And in my experience, SSO doesn't need to be expensive. SAML and Kerberos should be expensive, sure. But OIDC with standard seevices such as Google, GitHub, Okta or Keycloak should absolutely be part of the base package.
Personally, I'll just build the open core version from source and add all the "enterprise" features like SSO, S3 and Prometheus metrics myself.
"Need" has nothing to do with why SSO is expensive. There is no meaningful difference, from a business model perspective, between SAML and OIDC (though: don't do SAML). SSO is expensive because customers that require it are less price sensitive than customers that don't.
By all means: build your own SSO on the open core of products that charge for SSO. I promise: the companies don't really care that you're doing this. You're profoundly segmenting yourself out by doing that.
> There is no meaningful difference, from a business model perspective, between SAML and OIDC (though: don't do SAML).
Oh there absolutely is. The customers that use OIDC use a relatively light stack and are generally okay with relatively simple setups. They're usually startups and are also the ones that can feasibly add SSO into your app themselves.
The customers that need SAML are older, larger companies often with a custom mix of multiple hybrid AD and AzureAD directories for each department that need special handling with custom properties and realtime sync. You'll be spending at least a few engineer-months on support for them.
I've been on both sides previously, I've seen it all.
That's all fascinating, and I've done security assessments of about a dozen SAML implementations (don't do SAML) and have built several OIDC SSO implementations (whatever I'm fine with OIDC), but none of this has anything to do with product pricing.
Well you focused pretty hard on the word need, but do you disagree with "Making SSO a premium feature isn't any different from the paid SSL of the 2000s. You'll reduce security and safety just to segment the market."?
The problem with 4 hour SLA (I'm assuming in non-business hours?) Is that it's eye-watering expensive to scale.
If I have 100 cheap customers I need to scale it for 100. If I have 3 I can get by with putting staff "on call". (Pay the existing staff a bonus for out of hours etc.)
You can't pay $20 a month for something, and expect a high SLA
. That's not reasonable (and certainly not sustainable. ) a business that offered that would be on my "don't touch, will be out of business soon" category.
It's certainly possible to have a "free tier" - there are hood reasons for that. But the free tier had better not be costing you money. If they do, you don't have a business you have a hobby.
> I can get by with putting staff "on call". (Pay the existing staff a bonus for out of hours etc.)
There is a big difference between just winging something (and then hearing people complain on HN about how they have to work crazy hours and be on call) and doing things the right way, in a long-term sustainable business, with good work practices that also respect the employees.
Also, if you're running a solo-founder business, you can't "pay the existing staff a bonus for out of hours etc". You simply can't be on call for 24h/day, which means you need to hire an additional person -> see my comment above about the costs.
> SSO is an example of an "enterprise" feature with almost zero cost basis
Certainly not. Having looked at SSO recently in my SaaS, both implementation and maintenance costs were very significant.
The usual answer is "just outsource it to [whatever external service]", which apart from implementation and maintenance costs also introduces complex external technical and business dependencies.
Sorry — I know this is not the main topic of this discussion.
