I'm my own employer, and I'm usually way more passionate about writing features in my problem domain than implementing SSO & other enterprise features, which BTW are not in any way a differentiator or usable as a sales tactic. It's just that without SSO you won't be able to sell any enterprise software anymore, at least if it's a web-based product. SSO isn't something that SaaS startups try to push on enterprises, it's rather the inverse.
Our customers, which are often regular people working for BigCo that try to solve their own work problems aren't overly fond of SSO either, they just need to implement it as a policy since most companies enforce it from the top. You can debate whether that makes sense but if you're running an organization with tens of thousands of employees then not having a unified authorization & access control solution in place is regarded a bad practice, and for very good reasons. SSO solves many real problems that were extremely painful before, where you'd have either no common authorization at all or would need to write LDAP integrations. For all the flak it gets, SSO is orders of magnitude easier to implement and better at enforcing security best practices.
And the reason most SaaS vendors don't put price tags on their website is that it's extremely hard to do pricing as software integration in most enterprise environments still requires a ton of consulting and bespoke development, so if you e.g. put a 10.000 USD price tag on that you're setting yourself up for failure as you typically won't be able to estimate the integration cost until you've talked to the customer and assessed their needs and their IT environment. Deployments have become better as tools like Docker and Kubernetes become more ubiquituous, but it will still take many months to years in most places.
And writing an SSO implementation isn't difficult thanks to many libraries that are available and that do the heavy lifting. In the end SAML-based SSO isn't much more than reading a metadata document, forwarding a user to an external URL, parsing the response document and verifying its signature and generating a local access token for the user. The complexity lies somewhere else, e.g. in the role mapping and in working around the quirks of the specific SSO environment you encounter. Customers e.g. love to use non-standard fields to map organizations, users will often have inconsistent role and organization mappings, the customer wants to add some additional metadata field etc. etc. etc...
Our customers, which are often regular people working for BigCo that try to solve their own work problems aren't overly fond of SSO either, they just need to implement it as a policy since most companies enforce it from the top. You can debate whether that makes sense but if you're running an organization with tens of thousands of employees then not having a unified authorization & access control solution in place is regarded a bad practice, and for very good reasons. SSO solves many real problems that were extremely painful before, where you'd have either no common authorization at all or would need to write LDAP integrations. For all the flak it gets, SSO is orders of magnitude easier to implement and better at enforcing security best practices.
And the reason most SaaS vendors don't put price tags on their website is that it's extremely hard to do pricing as software integration in most enterprise environments still requires a ton of consulting and bespoke development, so if you e.g. put a 10.000 USD price tag on that you're setting yourself up for failure as you typically won't be able to estimate the integration cost until you've talked to the customer and assessed their needs and their IT environment. Deployments have become better as tools like Docker and Kubernetes become more ubiquituous, but it will still take many months to years in most places.
And writing an SSO implementation isn't difficult thanks to many libraries that are available and that do the heavy lifting. In the end SAML-based SSO isn't much more than reading a metadata document, forwarding a user to an external URL, parsing the response document and verifying its signature and generating a local access token for the user. The complexity lies somewhere else, e.g. in the role mapping and in working around the quirks of the specific SSO environment you encounter. Customers e.g. love to use non-standard fields to map organizations, users will often have inconsistent role and organization mappings, the customer wants to add some additional metadata field etc. etc. etc...