bsid

yes, definitely make a clerk production instance asap. it's a bit of pain to migrate development users to production users

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.

https://clerk.com/docs/elements/examples/shadcn-ui

We've only tackled a few of the UIs, but UserProfile, OrgProfile, etc. are coming soon.

Also, IAM usually means SSO solutions for employees i.e. things like Okta/OneLogin..

CIAM usually means external facing authN/authZ.. (customer identity and access mgmt)

There's so many terms in this space that are already confusing.

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.

update: user error on my part, thanks for the help!

Connected my database and it's not showing anything, also no error messages in the UI, some 406s in the dev console. would be interested to try it out

yup, I'm in the process of updating this :)

Clerk | Many Roles (see below) | Remote US, Remote EU, SF, Denver | Full-time

--

https://clerk.dev

--

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.

--

Roles:

Senior Frontend Engineer

Senior Backend Engineer

Content Marketing

Marketing Design / Brand Manager

UI/UX Designer

--

Email me directly at: braden@clerk.dev

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.

$150+ to own one for a year?

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.

Ahh, that makes sense, cool!

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!

MAU pricing is terrible! love this idea.

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!

you really need a way for people to get in if they forgot their password...

Yup. So many people mess this up, it's infuriating. U.S. banks are the worst.

Question: What happens when you're reading?

For me, my inner voice kind of repeats it, if that make sense. Can't wrap my head around what "understanding" would be without that lol.

Clerk.dev is a seed stage company, looking for some key hires to help build the “Stripe for Auth”. Founded by MIT/WashU grads. Backed by by Top Tier VCs (S28, Fathom, SPC) and DX experts, including Ex-CTOs of Dropbox, Segment, Pagerduty, to name a few.

We’re not working on your typical SaaS app, this product has quite a number of twists and turns. We’re constantly pushing on DX, which sometimes calls for some tricky work. Auth is particularly challenging because of how core it is to someones application. Auth0 and co are stodgy, and hard to use - hence most people use open source still. Huge market when we crack it.

To apply shoot me an email at braden@clerk.dev

Perks for all jobs Remote US - Equity — Unlimited vacation — People-centric — 100% health/dental/vision insurance — Team retreats to Greek islands

Roles: - Senior Frontend Engineer (React / Typescript) --- Help with our core JS SDKs, everything from performance to DX to making the TS types perfect. --- Keeping up to date with the JS ecosystem. Next.js is hot, and we're focused on a smooth integration.

- Documentation Engineer / Technical writer --- Docs are REALLY hard but REALLY important for good DX. --- Should be strongly opinionated about docs, be able to write well, and be able to spin up simple projects to understand the DX when needed. --- Stripe set the bar here, so we can pull a lot from them.

- Senior UI Designer --- Branding/Marketing overhaul --- Onboarding --- Dashboard UX/Customer facing UIs - Lead DevRel --- Define your own role, tell me whats best. The goal is to teach as many developers about Clerk as possible.

If you'd rather use a service to help identify user's location && advanced proxy detection (plus more advanced user management stuff, I'd love to chat about it with you, let me know (email in profile!) This painful stuff is what we specialize in at https://clerk.dev .

Congrats on the launch!!

It's hard to build alll those things you mentioned in a deep enough fashion to make it something people would use (Which is where I think this template lands). Entire companies are dedicated to each vertical.

These all things we wanted to tackle at Clerk (https://www.clerk.dev) as a SaaS. The first thing we hit down that path is user authentication -- and that opened up an entire can of worms we're still working through. User authentication alone has been tough enough because you can't just build yet another Auth0 clone and brand it "passwordless"... you'll have a tough time competing against the incumbents. This has led us to session management, which proved tricky to get right across local development and production environments, and has led is to the disparate ways people authenticate, which is a massive API design challenge. However, we think it could be a game changer, especially with all the Next.js / React advancements as of late. Especially the component-ization of the frontend in conjunction managed backends, session management feels like something that ties it all together.

I'm certainly excited for the next decade of developer tools :). Things will get dramatically easier with all these commoditized verticals.

I'm working on a product in the auth space, would love to know a bit more about your use case... also, why would you want ephemeral auth?

This is what we're trying to solve at Clerk, (https://www.clerk.dev) and it's been harder than we've expected, especially in regards to local development environments. Although we think we’ve made it seamless! Would love your opinion.

However, we're definitely not aiming it at non-programmers. I don't think completely general low/no-code solutions will ever take off. Everyone wants things far too custom, and at some point you won’t be able to beat the programming language of the time. Companies like retool are doing a great job in specific verticals — and I think it will always stay that way.

I think the next generation of dev-tools are going to be pretty impressive, especially with how easy and modular React components are — I’m bullish that React will become “low-code”

love your product :)

Are you using https://replicache.dev/ ? It looks very cool.

Just want to preface by saying - this is not a comment on you but rather YC. You're trying to improve the VC process for consumer brands, and I'll take you at your word for that.

I'm surpised, and a bit saddened, to see YC investing in a PE rollup kind of play. I’m probably reading too much into it, and maybe I had a misconception about YC was supposed to be, but to me, the brand was about innovation and scrappiness. YC founders use technology to move the world forward, usually through a better product. This brand conglomerate is way more blatantly of the form of “lets try to take a pile of money, and turn it into a bigger pile of money”.. of course they need $160M in funding, it is a fund. That money will go chiefly to buy companies, not into massive scale.

Not many entrepreneurs start out hoping to engage in raw capitalism, guided purely by returns. YC seemed like a place that catered to that dream of building something for yourself. Maybe that was never true, and I just had stars in my eyes. Maybe there’s no longer those low hanging fruits and everything’s become harder. But this seems almost of a betrayal of that original dream, only showing that YC is the same as everyone else in our capitalistic society.

Can promise good support over at Clerk ;) We are new, and are trying to provide an easier, more comprehensive authN/authZ/user management solution. We're also taking requests for individual use cases as we're ramping up!

Happy to answer any questions.

that would be a veryy incorrect implementation of 2FA. Wouldn't be surprised if some service works that way, but would def. be unfortunate