Timonier vs Clerk

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.

The default path is a port, not a config change

Clerk's own documentation frames its prebuilt components as the fast default path, and the Next.js quickstart's core step is dropping its <SignIn /> and <SignUp /> components into your app. Those components render a complete UI controlled from the Clerk Dashboard, themeable through an appearance prop.

If that's how you integrated, switching identity providers means replacing the rendered sign-in and sign-up surface, not repointing a config value. That's a real cost, and it's specific to this integration pattern, not to Clerk as a company or to any legal question about where Clerk is based.

Two things keep that claim honest rather than one-sided:

• It doesn't apply if you built on Clerk's headless hooks. Clerk documents useSignIn() and useSignUp() as a real, supported path to a fully custom UI. Clerk's own docs simply 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. Nobody publishes numbers on how that split falls across real Clerk integrations, so treat "most integrations use the default components" as Clerk steering its own documentation toward that path, not a measured fact.
• We're not the alternative to that cost. We're an instance of it. We ship our own prebuilt components too: SignIn, SignUp, SignedIn, SignedOut, AuthProvider, and TotpEnrollment. They're deliberately unstyled, 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.

Your backend and session model, and anything equivalent to a multi-tenant organizations UI, are out of scope here: neither is a like-for-like fit in a comparison about component coupling.

Where we're genuinely behind

Our browser SDK, the one a framework-agnostic single-page app would reach for instead of a full component set, is still early: token management, PKCE, and session APIs are landing incrementally. If your evaluation is "can I ship a polished sign-in screen with zero custom UI today," that incompleteness is exactly what you'd be integrating against on our side. That's not a small thing to concede, and we'd rather say it than have you find out mid-integration.