Next.js SaaS boilerplate or an AWS one?

· Tejo

Search for a SaaS boilerplate and most results are Next.js SaaS templates. They share a stack: Next.js on Vercel, Postgres behind an ORM, and Stripe. I sell a boilerplate that does not use that stack, so take this with that in mind. But for a lot of people, a Next.js boilerplate is the right answer, and I want to say when.

When a Next.js SaaS boilerplate is the right call

Pick one if most of these are true:

  • You want to ship in days, not weeks.
  • You run 1 product, and you expect modest traffic for a while.
  • You or your team already know Next.js and Postgres well.
  • You want preview deploys and a hosted dashboard with no setup.
  • The Vercel bill at your expected traffic is fine with you.

That covers a lot of products. The Next.js ecosystem is large, the docs are good, and a relational database is the safe default for most data. Nothing here is a mistake.

When an AWS boilerplate fits better

The picture changes if:

  • You already run AWS. Your day job, your other products, or your client work is already there. A second platform is a second set of bills, limits, and failure modes.
  • You run more than one product. On AWS, each product is a stack in your own account. Idle stacks of Lambda and on-demand DynamoDB cost very little.
  • You want infrastructure as code you can read. With SST, the infrastructure lives in your repo as TypeScript. In ShipPad, infra/ is one file per concern, so you can read the whole surface in an afternoon.
  • You do not want to manage database connections. DynamoDB is HTTP-based. There is no connection pool to size and no pooler to add when Lambda concurrency goes up.

What AWS costs you

Say the unglamorous part out loud: AWS is more setup than Vercel.

  • You need an AWS account, a domain, and some IAM basics.
  • SES starts in sandbox mode. You request production access before you can email real users.
  • Single-table DynamoDB has a learning curve. You design keys around access patterns up front. You do not add a query later the way you add a SQL WHERE clause.
  • You own alarms, logs, and backups. Nobody else watches them.

If none of the reasons in the last section apply to you, this cost is not worth paying.

Can you run Next.js on AWS?

Yes. SST has an sst.aws.Nextjs component that deploys a Next.js app to your AWS account. So “Next.js or AWS” is partly a false choice. The bigger decisions are the hosting account and the database.

ShipPad does not use Next.js. The app is React Router 7, the marketing site and blog are Astro, and both deploy with SST. The API is tRPC on a Lambda function, and the data lives in one DynamoDB table.

How to decide

Ask 3 questions:

  1. Which platform would you run this on in production if you had no boilerplate at all?
  2. How many products will you run in the next 2 years?
  3. Do your access patterns fit a key-value model, or do you need ad hoc queries?

If the answers are Vercel, 1, and ad hoc queries, use a Next.js SaaS boilerplate. If the answers are AWS, several, and known access patterns, look at an AWS one.

For a more general checklist, see How to choose a SaaS boilerplate. For the cost side, see Vercel vs AWS cost for a small SaaS.

Where ShipPad fits

ShipPad is the AWS case: SST v3, single-table DynamoDB with ElectroDB, tRPC, OpenAuth, SES email, org-scoped billing, and a superadmin app, all in your own AWS account. The architecture doc is public. Read it, and if the stack is not one you would defend in a production incident, pick something else.