Clerk Alternatives for Indie Founders Who Want Auth Without the Per-MAU Tax

Why founders look for Clerk alternatives

Clerk nailed the developer experience. You install the package, wrap your app in <ClerkProvider>, drop in <SignIn /> and <UserButton />, and you have auth. Social login, email/password, MFA, organization management — it works out of the box with Next.js, React, and other frameworks. For getting an MVP shipped fast, Clerk is hard to beat.

The friction starts when the numbers grow.

Per-MAU pricing scales against you. Clerk charges $0.02 per monthly active user beyond 10,000 on the Pro plan. That sounds tiny until you do the math. At 25,000 MAU, your auth bill is $325/month. At 50,000 MAU, it is $825/month. At 100,000 MAU, you are paying $1,825/month just for authentication. For a bootstrapped SaaS where many of those MAU might be on a free tier and not paying you anything, this is a real problem for your unit economics.

Compare this to Supabase Auth (free for 50,000 MAU), Firebase Auth (free for unlimited email/password auth), or Lucia (free forever because it is an open-source library). The pricing gap is enormous at scale.

Component-heavy approach creates coupling. Clerk's <SignIn />, <SignUp />, <UserProfile />, and <UserButton /> components are convenient, but they embed Clerk's UI into your app. Want to customize the login flow beyond what Clerk's appearance API allows? You are fighting the abstraction. Want to move to a different auth provider later? You are ripping out UI components, not just swapping an API client.

Vendor lock-in is real. Your user data — profiles, password hashes, OAuth connections, organization memberships — lives on Clerk's infrastructure. Password hashes cannot be exported. If you decide to leave, your users need to reset their passwords. That is not a smooth migration.

These trade-offs are acceptable for many projects. But if you are building a product you plan to run for years and scale to tens of thousands of users, it is worth understanding what else exists.

How we evaluated these alternatives

We looked at each option through the lens of a solo developer or small team building a SaaS:

• Integration effort: How long from zero to working auth in a Next.js app?
• Pricing at scale: What does auth cost at 1,000, 10,000, and 50,000 MAU?
• Customization: Can you fully control the login UI and auth flows?
• Data portability: If you leave, how painful is the migration?
• Production readiness: Is this battle-tested or still rough around the edges?

Auth is the kind of thing you do not want to rebuild. Picking the right solution early saves weeks of migration pain later.

Deep dive: what each alternative does best

Auth0 — the enterprise auth workhorse

Auth0 (now owned by Okta) is the most established identity platform on this list. It supports every auth flow you can think of — email/password, social login, passwordless magic links, SAML SSO for enterprise customers, machine-to-machine tokens for APIs, and multi-factor authentication with multiple methods.

The breadth of features is Auth0's strength and its curse. The dashboard is massive. The documentation covers every edge case but is overwhelming when you just want to add Google login to your Next.js app. The SDK ecosystem is comprehensive, but the configuration surface area is large. For a solo developer, Auth0 feels like bringing a freight train to a go-kart track.

The free tier is deceptively generous — 25,000 MAU with no charge. But it caps you at 2 social connections (for example, Google and GitHub — want Apple too? Pay up), no custom domains, limited action triggers, and no organization support. The moment you need features beyond basic social login, you jump to the Essentials plan at $35/month or Professional at $240/month.

Where Auth0 genuinely shines is enterprise selling. If your SaaS needs to offer SAML SSO so corporate customers can use their Okta or Azure AD identity providers, Auth0 handles this natively. Clerk also supports this on their Enterprise plan, but Auth0 has a decade of enterprise identity experience.

The developer experience for simple use cases has improved but still lags behind Clerk. Auth0's Universal Login (hosted login page) works well but is less customizable than Clerk's embeddable components. The React SDK is functional but not as elegant. Setup takes longer, configuration has more moving parts.

When to pick Auth0: Your SaaS sells to enterprises that require SAML SSO, SOC2 compliance, or advanced identity features. For most indie projects, Auth0 is more than you need.

Supabase Auth — auth that comes free with your database

If you are already using Supabase for your database, their auth module is the obvious choice. It is included in every Supabase plan at no additional cost, supports 50,000 MAU on the free tier, and integrates deeply with Postgres Row Level Security for data access control.

Supabase Auth supports email/password, magic links, phone OTP, and over 20 OAuth providers. The auth state ties directly to your database through RLS policies — you can write SQL like auth.uid() = user_id to restrict row access. No separate authorization layer needed. For data-heavy apps where auth and data access are tightly connected, this integration is genuinely powerful.

The trade-off compared to Clerk is the UI. Supabase provides @supabase/auth-ui-react with pre-built login components, but they are basic. They get the job done but they do not look as polished as Clerk's components. You will likely build custom login forms, which means more code but also more control over the experience.

The pricing story is where Supabase Auth really wins for indie founders. On the free tier, you get 50,000 MAU. On the $25/month Pro plan, there are still no per-MAU charges for auth — you are paying for database and storage, and auth comes included. Compare that to Clerk's $825/month at 50,000 MAU. That $800/month difference goes straight to your runway.

The downside is that Supabase Auth is tightly coupled to the Supabase ecosystem. Using it standalone without the Supabase database is technically possible but awkward. If you want just auth and nothing else, Supabase Auth is not the right fit.

When to pick Supabase Auth: You are already on Supabase or plan to use it for your database. The auth is essentially free and the Postgres integration is excellent.

Firebase Auth — unlimited free auth that actually scales

Firebase Auth is the sleeper pick on this list for one simple reason: email/password and phone authentication are free at any scale. Not "free up to 10,000 users." Free. Period. Google handles the infrastructure, the scaling, and the security, and you do not pay per user.

The catch is that "free Firebase Auth" covers the basics — email/password, phone, anonymous auth, and a handful of social providers. If you need MFA, blocking functions (custom logic during auth), SAML SSO, or more than the basic set of social providers, you upgrade to Firebase Authentication with Identity Platform. That adds $0.0055 per MAU beyond 50,000 — still dramatically cheaper than Clerk's $0.02 per MAU.

For mobile developers, Firebase Auth is arguably the best option on this list. The Flutter, iOS, and Android SDKs are mature, handle offline scenarios gracefully, and integrate seamlessly with the rest of Firebase. The web SDK is functional but less ergonomic than Clerk's React components or Auth.js in a Next.js project.

The developer experience for Next.js is the weak point. Firebase Auth was designed mobile-first, and it shows. Server-side auth in Next.js requires the Firebase Admin SDK and manual session cookie management. There are no pre-built React components comparable to Clerk's <SignIn />. You write your own forms and handle the auth state yourself.

Vendor lock-in applies here too. Firebase Auth tokens are Firebase-specific. Migrating away means re-implementing auth entirely. But at least Firebase is backed by Google — the risk of the service disappearing is low.

When to pick Firebase Auth: You are building a mobile app, need cheap auth at scale, or want unlimited free email/password auth without thinking about MAU limits.

Lucia Auth — own your auth entirely

Lucia takes a fundamentally different approach. It is not a service. It is not a platform. It is a TypeScript library that implements session-based authentication. You install it, configure your database adapter, and build the auth flows yourself.

This means you write the login form, the registration form, the email verification flow, the password reset flow, and the OAuth callback handler. Lucia provides the session management, cookie handling, and database abstraction. The auth logic lives in your codebase, your sessions are stored in your database, and no third-party service is involved.

For developers who understand web security fundamentals — password hashing, CSRF protection, rate limiting, secure session storage — Lucia is liberating. You control every aspect of the auth experience. The login UI matches your design system perfectly because you built it. There are no SDK updates that break your auth flow. There is no vendor to worry about.

The cost is zero. Not "free tier" zero where you eventually pay. Actually zero. Lucia is open source. Your auth costs are whatever your database costs, which for most indie projects is effectively nothing.

The real cost is time. Building email verification, password reset, OAuth integration, and MFA from scratch takes days or weeks depending on your requirements. Clerk gives you all of this in an afternoon. That time trade-off matters when you are trying to ship fast and validate an idea.

Lucia is also a library maintained by a small number of developers. The community is active, but it is not backed by a company with a support team. If you hit an edge case, you are reading source code and GitHub issues, not filing a support ticket.

When to pick Lucia: You want zero vendor dependency, zero ongoing cost, and full control over your auth implementation. Best for developers comfortable with web security.

Auth.js (NextAuth.js) — the community standard for Next.js

Auth.js — still widely known as NextAuth.js — is the most popular open-source auth solution in the Next.js ecosystem. It focuses on OAuth and session-based authentication, making it trivial to add "Sign in with Google" or "Sign in with GitHub" to your app.

The setup for OAuth is remarkably simple. Configure your providers, add the API route, wrap your app, and you have social login. Auth.js comes with 80+ built-in providers, so whether your users sign in with Google, GitHub, Discord, Slack, or dozens of others, there is a provider ready to go.

Auth.js integrates well with the Next.js App Router, middleware, and server components. You can protect routes, access session data on the server, and check auth state in middleware. The mental model is straightforward — sessions are stored server-side (in a database via adapters or as JWTs), and you access them through the framework.

The rough edges are in the configuration. Auth.js has a lot of options, and the interactions between them are not always obvious. JWT vs. database sessions, callback functions, adapter configuration, and provider-specific quirks can eat up time. The transition from NextAuth.js v4 to v5 (Auth.js) introduced breaking changes that frustrated the community. Documentation is improving but still has gaps for advanced use cases.

Like Lucia, Auth.js provides no pre-built UI. You build the login forms yourself. This gives you design control but means more code compared to Clerk's drop-in components.

For the common use case of "I need social login in my Next.js app and don't want to pay for it," Auth.js is the default choice. It is free, open source, and has the largest community in the Next.js auth space.

When to pick Auth.js: You need OAuth social login in a Next.js app and want a free, well-supported community solution.

Kinde — the direct Clerk competitor with friendlier pricing

Kinde is the most direct Clerk alternative on this list. Similar developer experience: pre-built components, hosted login pages, user management dashboard, and good Next.js integration. But with a pricing model that is more forgiving at scale.

The free tier covers 10,500 MAU — slightly more than Clerk's 10,000. The Pro plan is $25/month. Kinde also includes feature flags in every plan, which is a nice bonus — you do not need a separate service like LaunchDarkly or PostHog for basic feature gating.

The auth flows support email/password, social login, passwordless, MFA, and organization management for B2B SaaS. The developer experience is polished — not quite Clerk-level yet, but close and improving quickly.

Where Kinde differs is in its approach to B2B features. Organization management, role-based access control, and multi-tenant auth are available earlier in the pricing tiers compared to Clerk, where some of these features are gated behind higher plans.

The downside is ecosystem maturity. Kinde is newer than Clerk, which means fewer community tutorials, fewer integration examples, and a smaller pool of developers who have encountered and solved specific issues. The documentation is decent but not as comprehensive. If you hit an unusual edge case, there may not be a Stack Overflow answer waiting for you.

Kinde is also still evolving its product. Features ship fast, which is good, but it also means occasional breaking changes and migration steps. For a production app, this is a trade-off worth considering.

When to pick Kinde: You want a managed auth experience similar to Clerk but with better pricing, included feature flags, and early access to B2B features.

Cost comparison: auth at scale

Here is what authentication costs at different scales, focusing on the numbers that matter for a bootstrapped SaaS:

At 1,000 MAU (early-stage SaaS):

Every option on this list is free at this scale. Clerk Free, Auth0 Free, Supabase Free, Firebase Free, Kinde Free, Lucia, Auth.js — all zero dollars. Pick based on developer experience, not price.

At 10,000 MAU (gaining traction):

Still free on most platforms. Clerk Free covers up to 10,000. Auth0 Free covers 25,000. Supabase covers 50,000. Firebase is unlimited. Kinde covers 10,500. Lucia and Auth.js are always free. The only cost trigger at this scale is if you need Clerk Pro features (custom domains, allowlists), which starts at $25/month.

At 50,000 MAU (real business):

This is where pricing diverges dramatically. Clerk Pro: roughly $825/month. Auth0: depends on plan, but likely $240-500+/month. Supabase: $25/month (auth included). Firebase Auth: free for basic, ~$220/month on Identity Platform. Kinde Pro: $25/month + overage. Lucia and Auth.js: $0.

That $800/month difference between Clerk and Supabase Auth pays for a lot of infrastructure — or goes directly toward your break-even point.

The build-vs-buy spectrum for auth

Auth is not a binary choice between "use a service" and "build from scratch." It is a spectrum:

1. Full managed service (Clerk, Kinde, Auth0): Drop-in auth with pre-built UI, user management, and hosted infrastructure. Fastest to implement, most expensive at scale, most vendor lock-in.

2. Backend-included auth (Supabase Auth, Firebase Auth): Auth bundled with your backend platform. Good value if you are already using the platform. Less standalone flexibility.

3. Framework-integrated library (Auth.js): Open-source library designed for your framework. Free, community-supported, handles OAuth well. You build the UI, they handle the logic.

4. Low-level auth library (Lucia): Minimal abstraction over sessions and databases. Maximum control, maximum responsibility. You build everything, you own everything.

Where you land depends on your priorities. If time to value matters most and you need to validate fast, the managed services win. If long-term cost and portability matter more, the open-source libraries are better bets.

For most indie founders, the sweet spot is somewhere in the middle. Auth.js or Lucia for projects where you have time. Supabase Auth or Kinde for projects where you want managed auth without Clerk's pricing. Clerk itself for projects where the polished DX justifies the per-MAU cost.

When to stick with Clerk

Clerk is still the right choice in specific situations:

• You are pre-revenue and under 10,000 users. The free tier covers you completely, and the DX is the best on the market.
• B2B SaaS with organization management. Clerk's multi-tenant org features are mature and well-documented.
• You value shipping speed above all else. The pre-built components genuinely save days of development time compared to rolling auth yourself.
• Your product's revenue per user is high enough. If each user pays you $50+/month, Clerk's $0.02 per MAU is rounding error.
• Next.js is your framework and you want the smoothest integration. Clerk's Next.js SDK is the most polished auth integration for that framework.

The per-MAU pricing is only a problem when your MAU significantly outpaces your paying users. If you have a tight conversion rate and most active users are paying customers, Clerk's cost is proportional to your revenue. If you have a large free tier with thousands of non-paying users, Clerk's pricing works against you.

Migration tips for leaving Clerk

Moving away from Clerk is doable but requires planning. Here is the practical path:

1. Export your user data first. Use the Clerk Backend API to export user profiles, email addresses, metadata, and organization memberships. Do this before you change anything. Password hashes cannot be exported — plan for password resets.

2. Set up the new auth system in parallel. Deploy your new auth provider alongside Clerk. Route new signups to the new system while existing users continue using Clerk.

3. Handle the password reset problem. Since you cannot export password hashes, users with email/password logins will need to set a new password. Send a "we upgraded our login system" email with a password reset link. Frame it as a security improvement, not a disruption. Users who signed in with social login (Google, GitHub) can re-authenticate seamlessly since the identity lives with the OAuth provider.

4. Migrate OAuth connections. Social login users do not need to reset anything, but you need to store the new session and profile data from the OAuth provider in your new auth system. Test each provider individually.

5. Update your UI. Replace Clerk's <SignIn />, <UserButton />, and <UserProfile /> components with your own forms or the new provider's components. This is the most tedious part — search your codebase for all Clerk component and hook usage.

6. Run both systems for two weeks minimum. Keep Clerk active while you transition. Monitor error rates, failed logins, and user complaints. Only decommission Clerk after you are confident the new system handles every edge case.

7. Update your webhooks. If you use Clerk webhooks for user events (created, updated, deleted), reconfigure those events from your new auth provider. The payload format will be different.

Budget 2-4 weeks for a medium-sized project. The biggest risk is user churn during the password reset wave, so communicate clearly and make the process as smooth as possible.