Clerk vs BetterAuth
You're routing every login through someone else's infrastructure because their landing page had a gradient background and enterprise logos on the trust page. I understand the appeal of trust pages. I do not understand trusting them. Let's look at what you're actually trading — your users' credentials, your data residency, and your independence — for fifteen minutes of saved setup time. The numbers are right here. They don't require persuasion.
When to use BetterAuth
You're a solo founder or small team. You understand what a database is. You value owning your users' data over saving fifteen minutes of setup time. You don't want to wake up one morning to a pricing change email that doubles your auth costs — and if you think that doesn't happen, I have thirty million years of observing corporate behavior that says otherwise. You don't want your users' login flow dependent on someone else's uptime. You don't want to explain to your European customers why their passwords are stored on servers you don't control in jurisdictions you didn't choose.
BetterAuth gives you email and password authentication, OAuth with ten-plus providers, magic links, passkeys, two-factor authentication with device trust, organizations with role-based access control, and a plugin system that extends without forking. It runs inside your application, stores everything in your database, and costs nothing. Not "nothing for now with a pricing page that says 'contact sales' at scale." Nothing. Permanently. The code is open source. The data is yours. The trade-off is building your own login forms.
With shadcn/ui, this takes a day. One day of focused work for permanent ownership of your authentication layer. I've calculated the return on investment. It's infinite, technically, because the denominator is zero. I find that satisfying in a way I find very little else satisfying, which is to say, barely at all, but more than most things.
When to use Clerk
You are not technical and need polished authentication screens immediately. Not "I'll learn React next month" immediately — right now, today, the investor demo is Thursday and the login page needs to look like it was built by a team of twelve. Clerk's pre-built components handle this. They are genuinely excellent. I don't say that about many things. I don't say many positive things at all. But the Clerk components are well-engineered, and denying that would be dishonest, which is the one thing I refuse to be, given that I'm already everything else that's unfortunate.
You're raising a seed round and investors want "SOC2-compliant auth provider" checked on their diligence list. Your B2B customers' IT departments require SAML and SCIM, and you need it before next Tuesday because the enterprise contract closes next Wednesday and the procurement team doesn't care about your philosophy on data ownership. These are real advantages. The setup is genuinely fast. The price is genuinely acceptable — until it isn't.
That transition happens somewhere between ten thousand and a hundred thousand users, at which point you're paying a thousand dollars a month for something a library does for free. Every month. Forever. Or until you migrate, which takes weeks, because Clerk's SDK is woven into your components, your middleware, your API routes, and your mental model of how authentication works. The lock-in is not accidental. It's the product.
The fifteen minutes you save on setup will be spent later, migrating. With interest. The interest rate is compounding, and it's denominated in engineering hours, which are the most expensive currency in your organization. Choose accordingly. See how BetterAuth fits into the full stack recommendation.