Heads up, I don't quite get this from your pricing page at all right now.. It says "First 900 free" and "First 100 free" without any indication of what those numbers mean.
> It says "First 900 free" and "First 100 free" without any indication of what those numbers mean.
Thank you, we'll clarify that! It means that we're giving the first 900 "start up" and 100 "growth" plans away for free for a year
Yes, I am the CTO @ Clerk, and we do have per-user pricing right now, however, that doesn't mean we like it. It's something we've struggled with - how do you make pricing scale in some way, while still being clear, while also being predictable. There's also value in being in-line with the status quo - when your numbers are priced competitively using the "industry standard (auth0)" scale.
Every method, I think, has it's issues, and it's something we would like to make as frictionless as possible in the decision making process. I imagine with a "per CPU/mem usage model", you will run into a lot of questions.. (how am i supposed to know how much CPU/mem you, as a cloud provider, uses?). I also don't necessarily think gcloud/aws/etc. are the bastion of clear pricing.
Per API call seems more predictable, but still not as clear as the "at a glance, MAU number" Do product managers know how many API calls your average user would use? Yes, auth is most often implemented by devs, but are they always the buyer?
I do think there's something better, and I like thinking about new options :) We don't have a clear plan to change from MAU right now, but I hope we get there. Love ory btw, been following it for quite some time!
I’ve done some research into Hydra: https://gruchalski.com/posts/2021-05-23-do-you-really-need-a....
I think you might want to try the API calls pricing model (a la S3) because as a dev I usually don't know how much resources I need. But I can estimate that if I have X user that login each day that makes Y API calls which translate to Z$ (with proper spamming protection of course).
It’s hard to use the correct terms when you have users signing up to user management as a service xD
If you are an app for schools and students, you might have 300k users in Sep-May, but 10k users in Jun-Aug.
Would you feel comfortable if the cost went down during the low traffic months to a lower band, based on the 10k users?
Or is that still a non-starter?
Because the vast majority do 1-2 API calls to login once, are considered active and then never login again during the month. But you still have to pay as if it was active for the whole month.
That is why per API call pricing (a la AWS S3) or resources based pricing (1 CPU) is the best.