We actually have a huge initiative at Clerk with what we're calling "Elements" which gives a you "radix-like" way to build up the UIs, for significantly easier customization - especially when you're trying to go completely custom. The default modals will always be easier to use, and we're simultaneously working on getting better customization there.
Here's an example building a "Sign up" modal in the shadcn style.
Yeah coming up with our pricing model was and still is challenging. We're due for a revamp. As with most things in tech, all of these features require a ton of time to build / maintain / etc. so while the marginal cost isn't that high, the development time for all of them is very meaty and still ongoing.
If you were comparing something like build vs. buy where you had to build every feature clerk has from scratch, just paying for clerk would be soo much cheaper. But not every app needs every feature, and there's also a lot of open source options out there that make the build out a lot easier, so that comparison isn't completely fair.
But the main idea is that we wanted most apps to cost ~$25/mo - $100/mo, and, if you're building a B2B SaaS, you're going to have far fewer MAUs, and so we wanted the base cost to be higher at ~200/mo.
If you, or anyone reading this, ever feel like they're paying "too much" for Clerk - reach out to us and we'll work out a custom deal or even help you off-board to something else.
Banning users is still currently on the $25/mo tier which feels wrong, it should be in the free tier. We're due for a pricing revamp again quite frankly to make these pricing options more attractive. The tricky thing with the MAU costs is that a lot of folks seems to think they have a monster on their hands and forecast for like 1M MAUs or something, which is so far from reality.
It's tough to balance all of these competing priorities -- and if we don't have enough revenue, we can't keep building and investing in the platform for which we have pretty big ambitions. I will say that over a long period of time we want auth to be free and we want build applications to be 100x easier than they are today. I'm kind of getting ramble-y, but we also recognize that clerk's not for everyone and your use case might not make sense!
Hey, (clerk founder) why do you think Clerk's pricing is predatory? Our goal is to continually lower prices and be as affordable as possible. Outside the free plan, it starts at $25 for the first 10k MAUs. Eventually we want auth to be as close to free as possible, while selling addt. services built on top of auth/users.
Also, the clerk service has layered integrations, powered by an http layer. We have customers using each part of the layer for varied integration types. That being said, the SDKs for the spa frameworks are the easiest to use.
Clerk is building developer tools for the next generation of applications. We're looking for engineers and builders who enjoy having a lot of ownership and autonomy and strive for DX perfection and pixel perfection in everything they do. Attention to detail is paramount.
Well funded and backed by a16z, s28 capital, south park commons, and many others.
Why is this different than the massive sports-merchandising part of a teams business, where they sell more stuff depending on whether they win or lose? I imagine they'd want to bet.. err i mean hedge to provide real value to their business.
(despite the snark, I'm also curious how the situation is different)
We're working on the UIs portion over at Clerk (https://www.clerk.dev), however, we're not going all in on permission-ing and just giving folks enough "ABAC" so that we can actually power the UIs. I hope in the future we integrate with more powerful tools, such as warrant, to make this all more seamless :)
At Clerk, (https://clerk.dev, auth SaaS) we did a ton of work to get magic links to play nice with multiple devices, it's certainly a pain, and there's tradeoffs.
The crux of it is, do you sign in the "originating" device (where the magic link was sent from), or the "consuming" device (where it was clicked).
Because it's veryyy common for people to be on a website on their computer, then click the link on their phone, but still want to be logged into their computer. We opted for the "originating" device. But this has security concerns.
(you also need to worry about multiple tabs on the same browser, but cookies make this easy to deal with)
But, what if an attacker just sends a link to loads of email addresses, and one of the receivers clicks on it by accident? Their account now has been taken-over.
So, this needs to be combined with the notion of "trusted devices", and of course, not breaking what the user expects. All in all, a TON of work to get some marginal gains in some sectors, mainly B2C. IMO, B2B should always have passwords as an option. 1Pass is too widely used to ignore.
didn't mean to talk bad... nothing but respect for everyone involved in this project. my comment was very hasty -- and you're right I should have disclosed up front that I'm working on a product in a similar space.
Ory has been around for awhile, they're quite the gorilla in the identity space - It's a set of very large, and very impressive products that work well together. It is extremely powerful, flexible, and can handle almost any use case. I'd define "lighter" as being more opinionated in it's approach with fewer options - as a result it's less powerful and flexible. Also, w/ open source, comes setting up your own infra (even if that's now just throwing it in a cloud), which I'd consider "heavier". Imo, these terms don't mean something is worse than something else, just a fit for a different use case.
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!
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.
checkout - https://clerk.dev/solutions/nextjs-authentication, the middleware works like you're talking about. It's lighter weight than ory, i think. I've struggled to figure out how all of ory's pieces fit together, however their upcoming cloud offering may resolve some of those challenges!