BoilerplateHub

Next.js + Neon + Better Auth + Polar

Next.js with Neon, Better Auth and Polar keeps schema control while handing off compliance. Better Auth's tables and a mirror of Polar's grants both live in branchable Postgres, so entitlement logic stays safe to iterate on. It suits a developer tools business selling worldwide from a very small team.

Next.js NeonBetter AuthPolar

Database

Neon

Neon holds application data plus a thin projection of what Polar reports, and branching is what makes that projection safe to reshape. You can rebuild it on a branch, replay stored webhook payloads into it, and compare before promoting the migration. Keep the raw event bodies in a table for exactly that purpose, because with a merchant of record you cannot reconstruct history from your own charges, since there are none to read.

Authentication

Better Auth

Better Auth's tables sit next to the projection in the same Postgres, so resolving a session and a plan is one round trip, which matters when the compute may have only just woken up. Set the Better Auth user ID as Polar's external customer reference at the first checkout. The organization plugin is the natural place to hang a plan when the buyer and the users differ, keeping that decision in your schema rather than in Polar's customer model.

Payments

Polar

Polar covers the tax and invoicing surface while still behaving like an API you can script against, which fits a stack where everything else is already code under review. Products and benefits are defined on their side, so your database records which benefit somebody holds rather than what it cost. Payouts follow a reseller schedule rather than settling per charge, which changes how month-end revenue reconciliation has to be built.

What to watch out for

Compute that scales to zero and inbound webhooks are an awkward pairing. A delivery arriving at an idle project pays the wake-up cost inside the sender's timeout window, and a handler that then writes several tables can overrun it, producing retries your code must be safe to receive twice. Make the handler idempotent on the event ID before you optimise anything else in this stack.

Boilerplates close to this stack

Matched on Next.js plus the parts of this stack our catalog tags. Each card shows which pieces actually line up, so you can see how much you would still wire yourself.

A CLAUDE.md for this stack

The rules that matter for this combination specifically, including who owns entitlement state. Adapt the commands to your repository before committing it.

CLAUDE.md
# CLAUDE.md

This project is a Next.js SaaS on Neon, Better Auth and Polar.

## Stack

- Framework: Next.js
- Database: Neon
- Auth: Better Auth
- Payments: Polar

## Boundaries

- Never edit a migration that has already run. Write a new one.
- Never hardcode Polar price or product identifiers in components. They belong in config.
- Never trust a client-supplied user id. Read the session from Better Auth on the server.
- Treat webhook handlers as idempotent. The same event will arrive twice.

## Entitlements

- Polar is the source of truth for what a customer paid for.
- The database mirrors that state; it never decides it.
- Any check for "can this user do X" reads the mirrored entitlement, not a live API call.

## Before you say a change is done

- The app builds.
- Tests pass.
- No secret, key or webhook signing secret appears in a committed file.

Related stacks