Auth + billing for SaaS MVPs: Clerk vs Auth.js + Stripe in 2026

For a six-week B2B SaaS MVP in 2026, the right auth stack is Clerk and the right billing stack is Stripe Checkout + Stripe Billing. Provided you have the budget for Clerk's pricing curve. The right Auth.js + Stripe build saves the vendor cost and gives you full control, but adds 1–2 weeks of build time and a non-trivial maintenance tail. At MVP scale, this isn't a close call; at larger scale, the trade-offs can invert.

#What Clerk gives you

Clerk's pitch is “auth as a finished product.” You drop their <SignIn /> and <SignUp /> components into your app and you're done with the user-visible part. Behind those components: hosted password storage, magic links, social OAuth (Google, Microsoft, Apple, GitHub, Slack, etc), MFA, organization/team management, role-based access, an admin dashboard you can give to non-engineers.

For an MVP timeline this is decisive. The work that takes a developer 60–80 hours to build on Auth.js (password reset emails, session management, OAuth wiring per provider, organization invites, role enforcement, an admin UI) takes a fraction of that on Clerk. You install the SDK, add the middleware, wrap a layout, ship.

Pricing, approximately, at the time of writing (plans change, so check Clerk's current pricing):

• Free up to 10,000 MAUs
• $25/month base + per-user fees above that
• Organizations and roles beyond the basics on a higher-priced plan or add-on
• Enterprise pricing at larger scale

For an MVP launch, you're on the free tier or the $25 plan. The cost ramp matters at scale, but usually not in the first 12 months.

#What Auth.js gives you

Auth.js (the rebrand of NextAuth, now framework-agnostic) is a widely used open-source option for self-hosted auth. It runs in your codebase, stores sessions and credentials in your database, and has providers for every OAuth source you'd expect.

One change to know about: since September 2025, Auth.js has been maintained by the team behind Better Auth. It still receives security fixes, and new projects are pointed to Better Auth. If you want an open-source option for a new build, look at both. Better Auth includes more out of the box, so some of the gaps listed below are smaller there.

The pitch is “auth without vendor lock-in.” Your user data stays in your Postgres. Your session strategy is your call (database sessions vs JWT). Your password hashing, your migration path, your privacy posture. All yours.

The catch is what's missing out of the box: no UI components (you build signup/login/forgot-password/reset/verify flows yourself), no password-reset email pipeline (you wire your own SMTP + token logic), no admin tooling (you build it), no organizations/teams (you build it), no MFA (third-party plugin or you build it).

For a tightly-scoped MVP with no team accounts and no MFA requirement, Auth.js v5 ships in ~3 days of focused work. For a typical B2B SaaS MVP with team accounts, MFA, and admin tooling, Auth.js takes 8–12 days.

#The straight comparison

The times are rough planning estimates and the costs are approximate, at the time of writing; check current pricing.

For a six-week MVP where the goal is to ship fast and validate the product, Clerk is the call. For a build where year-2 cost discipline is more important than week-2 velocity, Auth.js is the call.

#What Stripe gives you (and where it stops)

Stripe is the default for B2B SaaS billing in 2026. The interesting question is which Stripe you're using, because Stripe ships about a dozen overlapping products under the same brand.

For a SaaS MVP: Stripe Checkout + Stripe Billing. Checkout handles the purchase UX (cards, Apple Pay, Google Pay, currency, tax). Billing handles subscriptions (recurring charges, plan switches, cancellation, dunning).

Avoid these for v1:

• Stripe Customer Portal as your primary surface. It's functional but feels off-brand. Build a thin custom UI that calls Stripe's APIs for upgrade/cancel; defer Portal to v1.1 if at all.
• Stripe Connect unless you're a marketplace.
• Stripe Tax advanced features beyond basic auto-tax. The basics are great; the advanced tax-jurisdiction work is v1.5 territory.
• Stripe Atlas for incorporation. Not relevant to billing; mentioned only because founders sometimes confuse the two.

What Stripe doesn't give you:

• An invoice your enterprise customers can run through procurement (Stripe invoices are functional but rough; if you're doing $20k+ contracts, you'll customize)
• Usage-based billing without nontrivial implementation work (Stripe Meters helps but isn't zero-effort)
• Revenue recognition for accounting (separate workstream)
• Tax compliance beyond what Stripe Tax automates

#The webhook problem nobody talks about

Stripe webhooks are where MVP billing implementations quietly break.

Stripe sends webhooks for: customer created, subscription created/updated/deleted, invoice created/paid/failed, payment intent succeeded/failed, charge disputed, refund created, etc. Your handler must:

1. Verify the signature (every event)
2. Be idempotent (Stripe will retry; you'll get duplicates)
3. Handle out-of-order events (cancellation event might arrive before the corresponding payment-failed event)
4. Have a dead-letter queue for unprocessable events
5. Have an audit log of every event received and what your system did with it
6. Have monitoring on webhook failure rates

Many first MVPs ship with a webhook handler that does (1) and partially (2). The rest is ignored until production breaks. A hardened handler covers all six.

Concretely: budget 2–3 days of v1 build just for the webhook handler. If your build plan doesn't include this, your billing implementation is incomplete.

#Free trial vs money-back guarantee

We've covered this in the “What to cut from v1” post but it intersects with auth + billing implementation: free trials add a good deal to the billing implementation work because they require trial-end logic, dunning, downgrade-to-free flow, win-back emails, and trial-in-progress UI states.

Money-back guarantee replaces all of it with one operational rule: refund if asked. Stripe makes refunds a one-click action. Your billing code stays simpler. Ship the money-back guarantee in v1; defer free trials to v1.1 once you've validated the product.

#Edge cases to plan for

A non-exhaustive list of billing edge cases that catch first-time MVP builders:

• Customer's card expires mid-subscription. Stripe sends invoice.payment_failed; you need a flow to email them, retry, eventually downgrade or cancel.
• Customer disputes a charge. Stripe sends charge.disputed; you need to decide if you want to gather evidence (and how), and update the customer's account state if you lose the dispute.
• Customer wants to switch plans mid-cycle. Stripe handles proration but you need UI for it and handling for "they downgraded but want the higher plan's features through the end of the cycle."
• Customer wants to cancel and re-subscribe later. You need to handle stale customer records and the question of whether you preserve their data during the gap (privacy / GDPR question).
• Customer signs up, never confirms email, comes back 6 months later. Your auth + billing flow needs to handle the "incomplete signup" state.

None of these is hard individually. The discipline is identifying them in scoping and budgeting time for them.

#A sensible default for v1

For a typical SaaS MVP, the auth + billing setup we'd recommend in 2026:

• Auth: Clerk (free or $25/mo tier). Email + Google OAuth + magic links. MFA optional. Team accounts on a paid plan if scope requires.
• Billing: Stripe Checkout for the purchase UX, Stripe Billing for subscriptions. Custom thin UI for upgrade/cancel calling Stripe's APIs. Stripe Tax for basic tax handling. Hardened webhook handler with idempotency, dead-letter queue, audit log.
• Edge cases handled: card-expired flow, disputed-charge flow, plan-switch flow, cancellation flow, signup-not-completed flow.

As a rough estimate, that's 3–4 days of week-1 build (Clerk wiring + Stripe scaffold) and 2–3 days of week-5 build (Stripe live mode + edge cases). About 6–7 days total. The Auth.js + Stripe equivalent is 12–15 days.

For a 6-week timeline, that 5–8 day delta is the difference between shipping on time and slipping by a week. For a 12-week timeline with cost discipline as the primary constraint, the math flips. Pick based on your constraint.

Our own MVP development is fixed-price, from $9,800, and takes four to eight weeks. To talk through auth and billing for your product, book a free 20-minute call.

Common questions.

• Should I use Clerk or Auth.js for a SaaS MVP?

  Clerk if you want to ship faster, can accept that the cost rises as your user count grows, and don't have unusual auth requirements. Auth.js if you want zero vendor cost, control the database, and have engineering capacity for the maintenance work. For a 6-week MVP build, Clerk saves you 1–2 weeks of work.

• Is Clerk worth the price?

  For an MVP shipping under a deadline, yes. Clerk gives you signup, login, password reset, magic links, OAuth, MFA, organizations, role-based access, and admin tooling out of the box. Building all of that on Auth.js can take 60–80 hours. At MVP scale, Clerk's fees are usually small next to that engineering time.

• Can I migrate off Clerk later?

  Yes, but plan for 1–2 sprints of migration work. Clerk supports user-data export. The friction is rebuilding sessions, handling password hashes (check what Clerk's export includes; you may need to force a password reset on migration), and re-implementing whatever auth UX you'd come to depend on.

• Should I use Stripe Checkout or Stripe Billing?

  For an MVP: Stripe Checkout for the actual purchase flow, Stripe Billing's subscriptions API for plan management. Avoid Stripe Customer Portal as a primary surface. It's functional but feels off-brand. Build a thin custom UI that calls Stripe's APIs for upgrade/cancel/swap actions.

• What's the most underestimated part of billing?

  Webhook handling. Stripe sends webhooks for subscription updates, invoice events, payment failures, refunds, disputes. You need an idempotent handler with retry logic, dead-letter handling, and audit logging. It is easy to ship a handler that verifies signatures and little else, and loses events; a hardened one is worth the extra days.