Growing in a community - with Colin Sidoti, founder of Clerk.dev
Clerk's actual competitor was never Auth0 — Auth0 only ever captured the top 10% of the market. Colin Sidoti built Clerk to beat the free, open-source auth libraries everyone else was already using, which meant winning on speed of setup, not feature checklists.
Colin Sidoti is co-founder and CEO of Clerk, a user management and authentication provider offering pre-built React components for sign-up, sign-in, user profile, and account management.
We get into why Auth0's own numbers show it only ever won the top of the market, why Clerk deliberately built its API to face the front end instead of the back end, and the year Clerk spent quietly bulletproofing security and reliability before ever launching publicly.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
Auth feels like a solved problem at this point. What led you and your brother to start Clerk anyway?
If you talk to developers, most are genuinely frustrated with their auth experience, and that frustration is exactly what led us to start Clerk. My brother and I were perpetual side-project people, and every time we built something and got to the auth step, whatever we pulled off the shelf was never quite right — only email and password, no email verification, missing OAuth, no two-factor. It was always a blight on the rest of the app, unprofessional compared to something like Stripe Checkout, which provides a genuinely complete end-user experience. Our thinking was: if Google can offer a great sign-up, sign-in, and profile experience, why can't there be a service that does that for everyone building a product?
Auth0 is the obvious established incumbent. How do you actually compete in a category with that kind of entrenched player?
The biggest challenge is genuinely getting developers to try something new when they already have something familiar. What surprises people is that Auth0 itself will tell you they only have about 10% of the market — and that held true in our own interviews. Most developers are actually using some open-source library. So we didn't set out to beat Auth0, we set out to beat those free, open-source tools — which is a much harder competitive position, competing against free. Our answer was to lean hard into UI components: beautiful, ready-made sign-up, sign-in, and user profile interfaces that are also faster to set up than the open-source alternative. Developers would love two-factor auth or a polished profile page, but won't add either if it delays their launch — so our React components mount directly on the page and give you far more, out of the box, than a typical launch-day auth setup would have.
A lot of developers would rather build this themselves than adopt a third-party service. How do you make the case against that instinct?
The single biggest thing that's worked for us is focusing on React and the Jamstack ecosystem specifically — for whatever reason, React developers tend to be genuinely happy just dropping in a component and getting a working solution, and objections about building it in-house tend to melt away once they see that. When people do raise the concern, since it's a completely reasonable one given how core auth is to an app, I point out that Auth0's own customer base skews toward the top end of the market — the bigger you get, the more likely you are to end up using something like Auth0, because it's easy to convince yourself early on that auth is a small problem, until your customers demand more depth than you want to build and maintain in-house. There's a genuinely dense compliance document, NIST 800-63B, covering exactly how passwords and verification codes should be handled for every auth factor — nobody asks a small startup if it's NIST-compliant, but eventually someone will, and it becomes a much thornier audit problem the longer you've owned it yourself. Our pitch is that it makes more sense to outsource that depth earlier, since we can provide far more of it, faster, than most teams could build themselves.
You've clearly found real traction in the React and Jamstack community. What got you there?
Fundamentally, developer experience. We're genuinely one of the only auth providers where you drop in a provider component and a sign-in component and get a fully working sign-in screen with zero backend setup required — which is unusual, because we built our API to face the front end directly instead of requiring your backend to talk to our API first. Every other tool needs your backend developer in the loop; our React components talk straight to our front-end-facing API. That single technical decision is what makes the developer experience feel almost magical — mount the provider, mount sign-in, mount sign-up, mount the user profile, and you're done.
How much faster is that in practice compared to implementing something like Auth0?
It's hours versus minutes. I think part of why Auth0 has struggled with the lower 90% of the market is that the actual time to set up Auth0 isn't meaningfully faster than setting up an open-source solution yourself — so you're not winning on time, and you're paying more on top of that. They also don't ship a user profile component at all, and neither do the open-source options. We've invested heavily in ours — users can update their name and password, see and remotely sign out of other active devices, upload an avatar. It's a genuinely complete account management experience most tools simply don't offer.
How many components does Clerk actually ship, and how far does that user management scope extend?
Four core components: sign-up, sign-in, user profile, and the user button — that little account menu in the top corner with 'manage account' and 'sign out.' We're still expanding what's covered under user profile too — things like mailing and shipping addresses to support more use cases, and eventually things like background checks at sign-up. A lot of tools in this space scope themselves narrowly to the login box itself, rather than the much broader problem of managing a user's entire lifecycle, and we think that broader scope is a genuinely important, underserved part of the problem.
How did you actually land in the Jamstack community, given you're not a typical React influencer?
Netlify noticed us and included us in their Jamstack Innovation Fund, and Guillermo Rauch has tweeted about us occasionally — small things like that helped elevate us in that community. But we didn't arrive as influencers at all. Clerk actually started as a Ruby on Rails app in its first year, which never saw the light of day. When we joined South Park Commons as our pre-seed, the demo we actually pitched with was that Rails app. What really connected us with our earliest supporter there, who'd been early at Facebook, was bonding over the shared frustration of building account and profile pages — he specifically hated working on Facebook's early accounts.php — more than any particular technology choice. It took a lot of subsequent customer research to actually land on the Jamstack segment as the right one to build for.
Why does that segment respond so well to what you're offering?
Even early Facebook, chasing 100 million users, didn't really want to spend time on the account profile page — that instinct to focus on your own core product rather than infrastructure like auth is universal, and it's exactly what we let developers do.
What's it actually like building something as mission-critical as authentication?
We identified that the Jamstack segment made sense as early as 2020, but didn't launch until early 2021 — that entire intervening year went into taking our proof-of-concept code and bulletproofing it from both a security and reliability standpoint, partly just for our own internal team's comfort. From a sales perspective, it's actually somewhat helpful that Auth0 exists and serves the top of the market well — it's established, industry-wide, that outsourcing auth isn't an inherently bad idea. But it means security and reliability, in that order, have to be genuinely immovable priorities for our team culturally — we can't compromise on either just to ship a better developer experience faster.