Sorry, I am not sure I completely understand. When you say that we may not be able to provide because it would be expensive - do you mean it would be expensive for us to build or for startups to buy? What exactly would the catch 22 situation be?
Not that I'm criticizing your model, but I'm just genuinely curious. I would switch to using this in a heartbeat if it doesn't end up too complicated. And lots of thanks to other HNers for downvoting me when I asked an honest question on SaaS pricing.
Then support and enterprise features are paid for by the enterprise. If you can find the right levers, it works.
This has been a common business model. Redhat did it, Hashicorp does it, Rancher I believe as well. The entire SSO Tax group of companies ( https://sso.tax/ ) have variable pricing because companies will pay for features like SSO that devs won't.
The question, especially with an open core model, is what happens if the cloud providers do to you what they did to mongo or elastic. I found this article interesting: https://joemorrison.medium.com/death-of-an-open-source-busin...
I think the jury isn't out on opencore as a business model and auth is certainly the right kind of horizontal platform play. And there's certainly room for all kinds of business models in auth, as it's a gigantic market.
Disclosure: I work for FusionAuth.
I had a SAAS for a while where <large enterprise customer> insisted on SAML-based authentication for a full roll out. However, they were happy to do a (cheaper) paid trial without it.
A service like SuperTokens works well here because its costs and complexity scale with my requirements. Unlike Congnito it is literally free and completely under my control at the start, but there is a reasonable forward migration path that doesn't involve a complete auth rewrite going forward.