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. Below the bucket sizes, this isn't a close call; above them, the trade-offs 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) is essentially zero hours on Clerk. You install the SDK, add the middleware, wrap a layout, ship.

Pricing in 2026:

• Free up to 10,000 MAUs
• $25/month base + per-user fees above that
• $99/month for the “Pro” tier with organizations + roles
• Enterprise pricing above ~50k MAU

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

#What Auth.js gives you

Auth.js (the rebrand of NextAuth, now framework-agnostic) is the OSS standard 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.

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

For a productized 6-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

Most freelance MVPs ship with a webhook handler that does (1) and partially (2). The rest is ignored until production breaks. Productized agencies ship hardened webhook handlers because they've debugged the same five edge cases 50 times.

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 30–50% 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.

#What we ship for v1

For a productized SaaS MVP build, our default auth + billing setup in 2026:

• Auth: Clerk (free or $25/mo tier). Email + Google OAuth + magic links. MFA optional. Team accounts on the Pro tier 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.

That's roughly 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.