Is it a fit?
When to choose Payload Stack.
It makes two strong choices for you — Payload as the backend, Next.js and shadcn/ui in front — and leaves the shape of your product to a config file: teams or single users, billing per organization, per user or not at all. The choices it does make are a head start for some products and dead weight for others. This page is for telling which one yours is.
$ npx create-payload-stack@latest
┌ create-payload-stack
│
◇ Database
│ PostgreSQL
│
◇ Organizations (teams)
│ Yes
│
◇ Billing
│ Stripe subscriptions, per organization
│
│ … project name, sign-in, media storage
│
└ Done. Next steps:
cd ridgeline
pnpm dev
Choose it when.
The stack earns its keep where the hard parts of a SaaS are the parts around the product: tenancy, billing, the admin nobody wants to build.
- The hard part is the wiring, and it is already done.
- Auth, tenancy, subscriptions and access control are each a solved library on their own. What nobody hands you is the seams: a session that knows the active organization, a subscription that gates a route, a collection scoped the same way in your app and in the admin. Those are connected on day one — and whether a subscription attaches to an organization or to a single user is a prompt at scaffold time, not a fork you are committed to.
- You need a back office and would rather not build one.
- Most starters stop at the customer dashboard and leave the internal admin to you. Payload generates it from the same collections: users, organizations, subscriptions, content and support tools, with roles and versions. It cannot drift from your schema because it is your schema.
- You would have picked this frontend anyway.
- Next.js, Tailwind and shadcn/ui. The components are copied into your repository, so you own them and change them, rather than configuring around a component library you cannot open.
- You want to own the code.
- MIT licensed and in your repository from the first commit. No licence fee for the boilerplate, no upgrade path that depends on someone else’s business, and a scaffold you can read end to end before you commit to it.
Look elsewhere when.
Every opinion in the stack is a cost for someone. These are the three that matter.
- You want to write the backend from scratch.
- Payload is opinionated. Data modelling, hooks and access control follow the Payload way, and the payoff comes from staying on it. If you would rather hand-roll routes in Express or Hono and choose every library yourself, the framework will feel like a constraint before it feels like a head start.
- Your product is small and will stay small.
- Turning teams off is one prompt —
organizations.enabled: falseinstack.config.ts, with scoping falling back to per-user ownership — but the scaffold underneath does not shrink. A landing page with a waiting list, or a single-purpose tool with no accounts to speak of, carries a CMS, an admin and a billing layer it never uses. - You want a managed backend.
- Payload Stack runs on a database you own: PostgreSQL, MongoDB or SQLite, chosen at scaffold time. Hosted Postgres from Neon or Vercel makes that a few minutes of work, but it is not the Supabase or Firebase model, and it does not try to be.
The short version.
Choose Payload Stack if
- You are charging for something, and want auth, tenancy and billing already wired to each other.
- You want a shadcn dashboard for customers and a Payload admin for your own staff, without building either.
- You are at home in Next.js and willing to learn Payload’s conventions.
Choose something else if
- You are building a lightweight B2C app or a simple directory.
- You prefer Supabase or Firebase as the backend.
- You want a hand-built API with no framework in the way.
