A Clerk alternative: what a switch involves

You're evaluating us against Clerk, and the honest starting point is how much of your sign-in surface is actually yours once you've integrated.

First, the reasons to stop reading. We don't do SAML. We don't store passwords. We don't offer social login ("Sign in with Google" and the like), and that won't change. We hold no certifications today. If you need any of those from us, the rest of this page won't change the answer.

What a switch involves

Clerk's own documentation frames its prebuilt components as the fast default path. The Next.js quickstart adds Clerk's <SignInButton /> and <SignUpButton />. With no sign-in or sign-up URL set, they link to Clerk's hosted Account Portal sign-in and sign-up pages. Clerk's <SignIn /> component renders a sign-in UI whose functionality is controlled by settings in the Clerk Dashboard, and it's themeable through an appearance prop.

If you integrated with Clerk's prebuilt components, leaving means replacing them in your code, and no config value does that for you. If your users sign in on Clerk's hosted Account Portal pages, those pages go away when you leave. Our equivalent is a hosted sign-in page that our OIDC authorize endpoint shows, with your logo and brand colour, so you'd repoint your app at it. Either way the work comes from the integration pattern. It says nothing about Clerk as a company, and nothing about where Clerk is based.

Two caveats apply, and the second one is about us.

• It doesn't apply if you built your own UI on Clerk's API. Clerk documents custom flows, a user interface built entirely from scratch using the Clerk API (for example with its useSignIn() and useSignUp() hooks). Clerk's own docs characterise it as "generally not recommended for most use cases," which is Clerk's own positioning, not a technical limitation. If your integration was built that way, you already own your UI and this migration is narrower. We found no published figures on how that split falls across real Clerk integrations. Clerk's docs steer toward the prebuilt path, and that isn't a measurement of how real integrations split.
• We're not the alternative to that switching work. We're an instance of it. We ship our own prebuilt components too: SignIn, SignUp, SignedIn, SignedOut, AuthProvider, and TotpEnrollment. They're deliberately minimal, with plain inline styles and no design system, meant to be replaced once you're ready to build your own UI through our own headless surface, which exists today with a working example. But adopt our default prebuilt path the same way Clerk's is adopted, and moving off us later is exactly the same kind of port. That's not an asymmetry in our favour. It's the same mechanism, named honestly on both sides.

We've left your backend and session model off this page, along with anything like a multi-tenant organizations UI. Neither compares like for like when the question is component coupling.

Our price is one flat monthly figure for the whole platform.

Where we're genuinely behind

Our browser SDK is still early. It's the one a framework-agnostic single-page app would reach for instead of a full component set. Today it handles PKCE sign-in, keeps the access token in memory, and reads the profile through getUser(). Its clearSession() drops local state only, and the SDK has no call yet that ends the platform session. If your evaluation is "can I ship a polished sign-in screen with zero custom UI today?", those gaps are what you'd integrate against. We'd rather you read that here than find it mid-integration.