Hacker News new | past | comments | ask | show | jobs | submit login

React/Next only



Working on it — vanilla JS support is pretty high up on our list


Yeah, I was going to ask if it’s react only, guess another product I won’t bother with.


My biggest issue with Clerk (aside from the since-validated suspicion their pricing would become downright predatory once they got sufficient adoption) was that if your product wasn't written in one of the SPA frameworks du jour it was basically unusable, unless you wanted your front-end integration driving your user data into your backend, which seemed like a security nightmare.

Why so many products will call themselves enterprise with no .NET, Java, etc. integrations available is part of why the existing products in those ecosystems are so expensive.

I look forward to playing around with Stack on my own and comparing it to Clerk but I couldn't seriously suggest this at work as there's no backend integrations.


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.


Thank you for the question! It's very easy to rocket into $500/mo+ when you start needing your add-on features that I really think should be standard for any paid tier of something like "user management as a service." User impersonation, MFA, custom roles/permissions don't necessarily have scaling costs with them so charging more for these features seems predatory. But I trialed your product prior to these pricing changes so I don't have first-hand experience implementing them, maybe there is some justification for the added cost.

Do you still need to be in a paid tier in order to ban users? It's been a while since I tried your product out and I seem to remember that being the case in the early days.


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!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: