Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Clerk – all of user management as-a-service, not just authentication

clerk.dev

Post reply on HN
Print view View original

81–90 of 234 posts

Re: Show HN: Clerk – all of user management as-a-service, not just authentication

#81

Post by wasd »

rexreed wrote: post #66

The pricing model has me confused: 1) Pricing is free up to 5,000 MAU 2) But the next pricing grade starts at 1,000 MAU for $49/mo + $0.05/MAU additional so if you have 5,001 MAU you take a big leap from $0 to $249/mo Is there a reason for that huge bump? Why doesn't the first pay tier start at 5,000 MAU? And how is MAU even calculated? Like, aren't all users in the system active users? Or are you able to have a bunc…

mau usually means logs in once during the month, if you have 20% mau that's 25k registered users. $250 / mo to manage a site with 25k users doesn't seem that bad.

Re: Show HN: Clerk – all of user management as-a-service, not just authentication

#82

Post by xyst »

faeyanpiraat wrote: post #8

I'm even hesitant to trust Auth0 for this, why would I trust a new company?

It's shiny and new, but the privacy policy stinks. It reminds me of Google's shady practices.

"8. Disclosure of Data

We may disclose personal information that we collect, or you provide:

...

Other cases. We may disclose your information also:

to our subsidiaries and affiliates; to contractors, service providers, and other third parties we use to support our business; for any other purpose disclosed by us when you provide the information;"

--https://clerk.dev/privacy

Who are these "subsidiaries" or "affiliate" companies? Data brokers?

From a company perspective it might be worth it to shave the 2-3 months to develop and perfect your own system. But from a user perspective, you are selling them out. Most people may not notice, but do you really want to risk the legal exposure or PR nightmare if their affiliate companies abuse this user data, or perhaps a subsidiary company leaves the data unencrypted in some db instance.

Re: Show HN: Clerk – all of user management as-a-service, not just authentication

#83

Post by grinich »

purplerabbit wrote: post #72
nautilus12 wrote: post #40

I'm waiting for SaaSaaS. SaaS as a service.

I would unironically buy this... probably 20% of my job is wrangling SaaS boilerplate. Am I alone on this? Let's be honest, how much of the SaaS code you write could be applicable in any SaaS application?

What's your job?

Re: Show HN: Clerk – all of user management as-a-service, not just authentication

#84

Post by bluefirebrand »

xwdv wrote: post #78

What startup is moving so fast they don’t even have time to write their own user management features and instead outsource it to a third party SaaS in perpetuity?

Basically all of them these days.

Somewhere someone convinced us all that "Authentication/Authorization" are hard problems that we should leave to third parties.

Re: Show HN: Clerk – all of user management as-a-service, not just authentication

#85

Post by colinmorelli »

polote wrote: post #77

Few things I dont get: - Who is your customer type ? Individual developers ? IT of companies ? - What do you bring in addition to Google G Suite ? - Why is that important to have beautiful UI ? - Why would I use your service to power auth of my service, as it would probably take more time to integrate your apis, and configure your frontend to my branding than do it from scratch ?

Not OP, but:

- Presumably, engineers building customer-facing applications

- Google G Suite can be a fine SSO solution for internal apps, but isn't the thing you're going to use for your customers

- I'm not sure how to answer this one. Surely it's quite obvious how a beautiful user experience is valuable? Your customers aren't comparing your experience against your competitors, they're comparing you to the best experience they have seen to date in any space. Companies who don't invest in their experience (and by extension, their visual design) will fall behind.

- At a surface level this may appear true, but in practice people often significantly underestimate the time involved in building a high quality and secure authentication system. If all you do is throw an email address and password in a table, then sure. But you're going to have sign up, log in, forgot password workflows (and emails) at the very least. Then, if you're actually trying to protect something, you're going to have password complexity requirements, brute force protection, 2FA (authenticator, sms, etc), security notifications, browser fingerprinting, etc - to name a few.

I'm still not sure how I feel on the outsourced authentication concept, but certainly not because building your own auth is free or cheap. Just because it's such a critical part of data that it might be worth eating the cost for (but I'm not sold necessarily).

Re: Show HN: Clerk – all of user management as-a-service, not just authentication

#86

Post by mynameisvlad »

yannoninator wrote: post #76
chickenpotpie wrote: post #51

Earlier quoted context omitted.

> I really can't think of any good reason to hand crucial control of a site over to any third party, much less user authentication where one breach will potentially cost you millions and land you in jail. Because Auth0 and other providers have security experts specializing in prevent hacking attempts and there is no way you can do a better job than them unless you make it your full time job.

or, you could just do passwordless email auth and not have any security issues whatsoever.

Sure, because “do passwordless emails” is just a snap of the finger away, right?

The point is that doing auth properly is hard. Sending an email might be easy, but creating and managing the session in a secure fashion is hard, even if you’re “just doing passwordless email auth”.

Re: Show HN: Clerk – all of user management as-a-service, not just authentication

#87

Post by asimjalis »

colinclerk wrote: post #32
asimjalis wrote: post #4

Nice. If you could also add the ability to charge subscriptions from users and manage their subscription plans this would become a no-brainer. Also your pricing model could become very lucrative—you could charge a percentage of the revenue.

Definitely! We've found that developers want to apply subscriptions against either Users or Organizations, so first we're planning to build out Organization management first (create an org, invite members, setup SAML auth, etc). Subscription management will follow sometime after, and will probably look like a Stripe integration that automatically creates Stripe Customer objects for your Users and Organizations. Is th…

In my case I don’t care about organizations. I am an individual dev who would love to use something like this to easily build apps that I could monetize. I am thinking of a web equivalent of the Apple iOS app store. Some place where you write an app and let the app store take care of billing and payments. I have published several iOS apps and zero web apps mostly because there is no frictionless way of monetizing web apps. Feel free to send me email if you want to talk more about the use cases.

Re: Show HN: Clerk – all of user management as-a-service, not just authentication

#88

Post by type_Ben_struct »

Looks great and I can see a lot of value in this having been disappointed myself with how much is left to the developer with services like Auth0 and Okta.

Could you expand some more on the team behind this? As this service would be a critical part of any application relying on it for authentication I’m keen to know about the size of the team supporting it.

Do you offer an SLA and 24/7 support?

Re: Show HN: Clerk – all of user management as-a-service, not just authentication

#89

Post by rexreed »

kilburn wrote: post #79
rexreed wrote: post #66

The pricing model has me confused: 1) Pricing is free up to 5,000 MAU 2) But the next pricing grade starts at 1,000 MAU for $49/mo + $0.05/MAU additional so if you have 5,001 MAU you take a big leap from $0 to $249/mo Is there a reason for that huge bump? Why doesn't the first pay tier start at 5,000 MAU? And how is MAU even calculated? Like, aren't all users in the system active users? Or are you able to have a bunc…

Typically MAU means "users that logged at some point during that billing month". That is, when you are billed based on MAU you don't pay for the number of users in your database, only for the ones that actually use your app/service/whatever.

Typically, that makes sense. Specifically, there's nothing on the website to indicate that is how they calculate MAU. The website is missing this critical bit of detail to inform would-be buyers.

Re: Show HN: Clerk – all of user management as-a-service, not just authentication

#90

Post by colinmorelli »

colinclerk wrote: post #53
colinmorelli wrote: post #38

What's the story around extensibility? I feel like it starts to get murky when the boundaries of data ownership are unclear. What if I have some bespoke user-level data that doesn't make sense for your system to store, but is massively important to my business (this feels to be the case for most products I build). Can customers extend your UI components? Do they store that data with you? One of the nice parts about a…

Hi Colin! On your backend, Clerk gives you a stable User ID for each user. You're free to use it as a foreign key in your database as you normally would. (clerk.dev runs on clerk, and that's how we do it internally) We only have a Node SDK so far - here's a guide on retrieving the User ID from your backend: https://backend-docs.clerk.dev/quick-starts/next.js-api-rout... Soon we will launch a way to add custom attribu…

Thanks for the reply! I think your last point is what worries me the most. I feel like it makes sense to tackle custom attributes, because you own the user management pages. But, I also feel like you're almost never going to be able to support the kind of flexibility customers will need if those fields are anything more than simply metadata.

It's nothing about Clerk specifically, it's just a problem with these kinds of products. I just worry that as your customers grow and scale, they naturally need to leave your platform (or downgrade to an auth-only solution). I'll definitely be curious to see how the product grows, though!

Post reply on HN