BoilerplateHub

Next.js + Neon + Better Auth + Lemon Squeezy

Next.js with Neon, Better Auth and Lemon Squeezy is a deliberately small stack: one Postgres, one auth library, one hosted checkout. Neon's branching gives you somewhere to change what a plan means without touching live data. It suits an early product still working out the shape of its pricing.

Next.js NeonBetter AuthLemon Squeezy

Database

Neon

The schema here is small on purpose: Better Auth's tables, a variant to plan mapping, and one entitlement row per user. Neon's branching earns its place during the awkward period when the definition of a plan is still moving, since the mapping can be migrated on a branch and pointed at by a staging build. Store the Lemon Squeezy subscription identifier as the natural key so a re-import from their API reconciles without guesswork.

Authentication

Better Auth

Better Auth handles the account, and the account needs to exist before checkout for this to stay clean. Require sign-in, generate the checkout URL server-side with the user ID embedded as custom data, and the webhook has an unambiguous target. Because the auth tables are ordinary Postgres, a support query joining user, entitlement and order is plain SQL rather than three dashboards open in adjacent tabs.

Payments

Lemon Squeezy

Lemon Squeezy removes the two jobs a small team least wants: tax registration and a checkout page that must behave on every browser and card type. Your app creates a link, verifies a signature and updates one row. The ceiling is real though. Anything resembling per-seat pricing, usage metering, or a mid-cycle plan change modelled in your own code is going to fight the variant catalogue rather than fit it.

What to watch out for

Signature verification needs the raw request body, and the reflex in a route handler is to parse JSON first, which yields a handler that rejects every event it receives and logs a mismatch you will misread as a wrong secret. Read the body as text, verify, then parse. The other pressure is connection count: webhook bursts, cron work and page traffic all opening Neon connections at once, so go through the pooled endpoint.

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 Lemon Squeezy.

## Stack

- Framework: Next.js
- Database: Neon
- Auth: Better Auth
- Payments: Lemon Squeezy

## Boundaries

- Never edit a migration that has already run. Write a new one.
- Never hardcode Lemon Squeezy 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

- Lemon Squeezy 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