For developers who'd rather not rebuild auth for the fourth time
Ship the SaaS, not the scaffolding.
An SST boilerplate that runs in your AWS account. Auth, billing, a single-table DynamoDB layer that doesn't fall over at scale, an admin app, and a CLAUDE.md that actually teaches your agent the codebase. Not another Next.js-on-Vercel starter.
One-time payment. Your AWS account. No subscription on the boilerplate itself.
infra/ ├─ table.ts ├─ auth.ts ├─ api.ts ├─ web.ts ├─ admin.ts ├─ site.ts ├─ payments.ts ├─ email.ts ├─ queue.ts ├─ cron.ts ├─ storage.ts ├─ secrets.ts └─ domain.ts
The part every other boilerplate skips
You don't need another Next.js starter. You need somewhere to put the app you're actually going to run for years.
Every boilerplate in this category assumes the same stack: Next.js, Vercel, Postgres, an ORM. That is a fine stack. It is also not the one you run in production at your day job, and not the one that scales the way you actually scale, which is bursty, cheap at idle, and occasionally on fire at 2am because someone posted your product on Hacker News.
Most boilerplates
Vercel, Postgres, an ORM. Fine for a weekend MVP. You'll be migrating off it the moment your traffic stops looking like a weekend MVP, or the moment you want to run more than one product without paying for compute you're not using.
The free, open-source option
Real code, zero cost, and you're on your own for the architecture decisions that actually matter. Single-table DynamoDB, an agent harness, a working payments webhook: you'll build all of it yourself, slower than you think.
Shippad is the AWS-native one
SST, single-table DynamoDB done right (with the collection-index pattern that avoids a full table scan), and a CLAUDE.md detailed enough that your coding agent stops guessing at your architecture. It runs in your AWS account, on a stack you can defend in a production incident.
I kept hitting the same wall building SaaS products on AWS: every boilerplate on the market assumes Vercel and an ORM, and the one architecture decision that actually matters at scale, single-table DynamoDB, isn't something you can buy. You either learn it the hard way over a few painful months, or you skip it and pay for it later when a full table scan takes your API down.
I'd already made those mistakes once. I built Shippad so the next person building on AWS doesn't have to.
From clone to first paid user
Five phases, one repo
- 01
Stamp it.
./scripts/init.sh my-app mydomain.comrewrites the name, the domain, and the package scope across the repo. Five minutes. - 02
Wire the required secrets.
Google OAuth, Dodo, a session secret.
SETUP.mdwalks through exactly which five have no fallback default. - 03
First deploy.
npx sst deployships auth, a dashboard, and a test-mode upgrade flow to a real AWS account. The webhook URL prints in the deploy output. - 04
Turn on what you need.
Referral program, teams, web push, inbound email, analytics, captcha: all opt-in, all gated behind one flag or secret each. Nothing you don't enable ships active.
- 05
Go to production.
RUNBOOK.mdcovers the one-time, per-account steps: SES out of the sandbox, DMARC, live payments, the alarm subscription. None of it is hidden behind a support ticket.
What's inside
Built for the SaaS you're still running in a year.
Single-table DynamoDB, done the way it's supposed to be done
Every entity lives in one table with a real key strategy, not seven tables stitched together with foreign keys. Collection indexes mean "list all users" is a query, not a full-table scan that pages by items examined instead of matches.
- One table, documented key patterns for every entity
- A collection index on every list-able entity, so you never accidentally scan
- entity.ts → schema.ts → index.ts, the same pattern for every domain you add
Payments that don't lock you to one provider
Dodo is implemented today. Stripe and Paddle are stubbed behind the same interface, so switching providers later is a swap, not a rewrite.
- Org-scoped billing, so team plans aren't a bolt-on
- A webhook that's the actual source of truth for subscription state
- Plan entitlements in one file, not scattered through the codebase
An admin app you'll actually need by month two
Stats, users, campaigns, affiliates, and a support inbox, all in a separate app at admin.<domain> with its own session and its own role check on every procedure.
- Cached stats snapshot, so the dashboard doesn't re-scan your whole user table on load
- API keys scoped read-only by default, mintable only from a session, never from a key
- The same PWA machinery as your main app, push notifications included
A CLAUDE.md that is an actual agent harness
Most boilerplates that claim "AI-ready" mean a CLAUDE.md that lists the tech stack. This one documents the DynamoDB key patterns, the domain implementation order, and every non-obvious constraint your agent would otherwise rediscover by trial and error.
- 32 documented patterns, not a paragraph of marketing copy
- The actual key templates for every entity, so your agent never guesses at a GSI
- Written by someone who runs multiple products on this exact repo
Vercel vs. your own AWS account
Modeled on published Vercel Pro and AWS Lambda / DynamoDB on-demand rates, mid-2026. Not a guarantee: your actual bill depends on item sizes, caching, and access patterns. This compares hosting cost only, not the engineering time to set either one up.
At low traffic this gap is small, a few dollars either way, and not worth migrating for on its own. It widens with scale, and more sharply if you run more than one product, since the marginal AWS cost of product two is close to zero while a second Vercel project means a second set of usage meters running against the same seat.
From "is this for me?" to deployed
How it works
Check the architecture, not the feature list.
Read CLAUDE.md before you buy. If single-table DynamoDB and SST aren't a fit for what you're building, this isn't the right boilerplate, and you should know that in five minutes, not after checkout.
Stamp it and deploy it.
init.sh, the required secrets, one sst deploy. You're looking at a real, working sign-in flow and dashboard in your own AWS account the same day.
Turn on what you need, when you need it.
Teams, referrals, inbound email, web push. Every optional feature is a flag or a secret, never a forked code path you have to merge back.
Pricing
One-time. Yours. Runs in your AWS account, not ours.
License
One-time payment, lifetime updates, unlimited projects.
$199one-time
- Full source, every package
- init.sh to stamp unlimited products from it
- Lifetime updates via git
- Read CLAUDE.md's architecture before you buy, it's public
Recommended
License + support
Everything above, plus direct access.
$399one-time
- Everything in the base license
- A shared community channel
- Priority answers on architecture questions
No subscription on the boilerplate. The only recurring costs are the ones you'd have anyway: AWS, your domain, your payment provider.
Questions
The honest answers.
Is this just another Next.js + Stripe boilerplate?
No. It's SST v3 on AWS, not Next.js on Vercel, and single-table DynamoDB instead of an ORM over Postgres. If you want the Vercel stack, there are good options for that already; this one is for people who want to run on AWS and mean it.
Why DynamoDB instead of Postgres? Isn't that harder?
Yes, there is a real learning curve, and CLAUDE.md is written to flatten it as much as honestly possible. The payoff is a database that needs no connection pooling, scales to zero, and the cost calculator on this page shows you the actual dollar difference at a few traffic levels.
Do I need to use AWS specifically, or can I run this elsewhere?
SST targets AWS. The payments layer, the captcha layer, and the error-monitoring layer are all provider-agnostic by design (swap Dodo for Stripe, Turnstile for nothing, console logging for Sentry), but the infrastructure layer itself is AWS.
What's actually implemented versus stubbed?
Dodo payments, Google and email-code auth, the referral program, and inbound email are fully implemented. Stripe and Paddle are interface-complete stubs that throw a clear error until you fill them in. The README and CLAUDE.md are explicit about which is which. Nothing is silently fake.
Is the multi-tenancy real, or bolted on later?
Every user gets a personal org on signup. A solo user is just an org of one. Turning on the TEAMS_ENABLED flag only changes the UI (the switcher, invites, the /team page); the data model has always been tenant-scoped, so there is no migration when you flip it on.
What does "lifetime updates" actually mean?
You get every future commit to the template via git. It does not mean anyone maintains your fork forever. You own the code the moment you clone it, and you are responsible for merging the updates you want.
Can I get a refund?
No refunds once repo access is granted, the same policy every boilerplate in this category runs, for the same reason: the product is the source code itself.
Read the architecture. Then decide.
CLAUDE.md is public before you buy. If single-table DynamoDB and AWS aren't the stack you want to run, this isn't the right boilerplate, and I'd rather you know that now.