Hacker News Reader

Comment by fakedang | Hacker News Reader

> We will follow the Buyer based model where features for developers / startups are free and those required by enterprises are paid. We have a section on pricing philosophy on our pricing page that explains this in a little more detail.

Just curious about this model, but if you keep only the essential features on the developer plan (good for startups but not much above that), while the enterprise plan requires more complicated features and SDKs that you may not be able to provide just yet because it would be expensive at this stage, wouldn't it be a catch-22 situation of sorts?

View on HN

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?

What Aeolun said. Basically if you don't provide those features that enterprise wants from the get-go, and count on the enterprise plan to fund the development of those features, doesn't that land you in a catch 22?

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.

FusionAuth (the company for which I work) have a similar model with a free (though, in our case, not open source) community edition for developer reach and to lower the barrier to entry.

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.

As a (potential) consumer of this type of service I can attest that this is fine with me.

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.

If I need to pay to access the enterprise features (just like with Auth0 or Cognito), why wouldn’t I just use those?

More customizability, benefit from the open core model, an easier on-ramp to try out and get used to the product.

Reply on news.ycombinator.com