yes, definitely make a clerk production instance asap. it's a bit of pain to migrate development users to production users
54 karma · joined May 1, 2020
All of user management, not just authentication https://clerk.dev
braden@clerk.dev
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.
CIAM usually means external facing authN/authZ.. (customer identity and access mgmt)
There's so many terms in this space that are already confusing.
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!
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.
--
Roles:
Senior Frontend Engineer
Senior Backend Engineer
Content Marketing
Marketing Design / Brand Manager
UI/UX Designer
--
Email me directly at: braden@clerk.dev
(despite the snark, I'm also curious how the situation is different)
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.
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.
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.
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.
Congrats on the launch!!
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.
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”
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.
Happy to answer any questions.