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.

I don't think the 4-hour SLA customers subsidize the 72-hour ones. It's more about managing the volume of support. If know you won't get an until 3 days after, you will google obvious things yourself, and only contact support if you can't get the answer otherwise. But shorter SLAs, let alone phone support, encourages a particular kind of customers to just copy-paste any error message they encounter (that may not necessarily come from your product) and expect support to untangle it. Been there, seen that.

> The people that want those product features subsidize the people who don't

Surely any company doing that would be spending profits on less profitable customers which is not economically sensible. See the box on page 2 of https://regulationbodyofknowledge.org/wp-content/uploads/201...

Cross-subsidisation can occur due to regulations or a company trying to monopolise a market.

Pricing a product depends on how much you can charge and variable costs, not so much on how much it cost to develop - which as you point out leads to price discrimination - where it looks like one group is subsidising the other but maybe not in reality.

I would like to see a model of the marginal costs and ideal decisions.

Deciding to build features for higher paying clients only makes profits if those features are paid for by those clients. Other clients might get those features but it isn't "subsidisation" - however I'm not sure what a better word is! It isn't free-riding or consumer surplus.

It's called market segmentation. The classic analogy is airline seats.

Ultimately the job of the airline is to get me from A to B. They do just that for First Class and sub-economy. But for more money you can have snacks etc.

Airlines offer add-ons that cost them real money (checked bags) and things that don't (seat selection.) They allow the customer to decide which features they want and which they don't.

Not all seats generate the same profit, but all seats generate some profit above marginal cost. (Usually some number of seats needs to be filled before the flight makes a profit, but that's a different equation.)

With software there's naturally some segmentation, and so the smart company tries to capture that value. Equally some segments want different (expensive) things like Support (and can afford it) so that needs to be on the table to win that customer in the first place.

A segmented offering is inevitable, at which point you then have to decide who does the segmenting. The client? Or do you have a salesperson to help them?

There's no right answer, but usually it depends on the product price. If I'm buying an airline seat I can figure it out [1]. If I'm buying an airplane probably not.

[1] I'm old enough to have lived in a time when there were specialists necessary to buy an airline seat.

Support is one thing. There is absolutely no excuse for upcharging for SSO. None whatsoever. Any company that does this is a shitty company who deserves to go out of business for abusing their customers.

So most companies are shitty companies that deserve to go out of business. Got it!

You get that you're arguing that companies shouldn't get a price break for not wanting SSO, right?

That sounds fine to me. What makes you think that's self-evidently wrong?

In any product there's a thousand different features where offering a price break for not using that particular feature would be silly.

If anything, just considering the customer side of things, give a disincentive for not using something like SSO to reduce careless password use.