How to choose a SaaS boilerplate

A SaaS boilerplate gives you the parts every SaaS needs and nobody wants to build again: auth, billing, email, an admin view, a landing page. That part is easy to compare. Every feature list looks the same.

The part that is hard to compare is the decisions you inherit. You pick a boilerplate in an afternoon. You run on its database, its hosting, and its data model for years. So I judge a boilerplate by those decisions first and by the feature list last.

These are the questions I ask.

1. Where does it deploy, and who sends the bill?

Most SaaS boilerplates assume the same stack: Next.js on Vercel, Postgres, an ORM, and Stripe. That is a good stack. It is fast to start and has a large ecosystem.

Ask what that stack looks like at 10 times your current traffic, and at 3 products instead of 1. Then ask if it is the stack you would choose for production anyway. If yes, pick a boilerplate built on it. If you already run AWS at your day job, a Vercel-first boilerplate means you learn a second platform to save time on the first month.

2. Is multi-tenancy in the data model, or added later?

If you might sell to teams, check this before anything else. A multi-tenant SaaS boilerplate should key billing and data to an organization from day one, not to a user.

The test is simple. Find where the subscription is stored. If it is keyed by user ID, team support means a data migration later. If it is keyed by org ID, and a solo user is an org of 1, team support is a UI change.

3. What is real, and what is a stub?

A payments integration is not a checkout button. It is a webhook that receives the provider’s events, checks the signature, and updates subscription state in your database. Many boilerplates ship the button and leave the webhook to you.

Read the README for a clear list of what is implemented and what is stubbed. If the README does not say, assume the worst and check the code.

4. Can you read the architecture before you pay?

A good boilerplate shows you how it fits together before you buy it. Look for a public architecture doc, a file tree, or the actual infrastructure code. If the only material is a feature grid and testimonials, you are buying blind.

This matters more now that coding agents write a lot of the code. An agent works much better with an accurate architecture doc in the repo. Without one, it guesses.

5. What do “updates” mean?

“Lifetime updates” almost always means you get future commits via git. It does not mean someone maintains your fork. Once you clone it, the code is yours, and so is the work of merging upstream changes. That is fine, as long as you know it going in.

Free on GitHub or paid?

There are good open source SaaS boilerplates on GitHub. They are real code at zero cost. Before you clone one, check 3 things:

• The last commit date. A boilerplate that has not moved in a year is now your maintenance project.
• The license. Some are MIT. Some do not allow commercial use, or need attribution.
• The open issues. They show what breaks in practice, often better than the docs do.

The cost of a free boilerplate is time. You still make the architecture decisions that matter, alone. A paid one is worth it only if it makes those decisions well and documents why.

So what is the best SaaS boilerplate?

The one whose stack you would run in production anyway, with a data model that matches how you sell. For most people that is a Next.js boilerplate on Vercel, and that is a fine choice. I wrote more about that tradeoff in Next.js SaaS boilerplate or an AWS one?.

Where ShipPad fits

I built ShipPad for the other case: you want to run on AWS and mean it. It is an SST v3 boilerplate. It uses single-table DynamoDB through ElectroDB, tRPC, OpenAuth (Google and email codes), SES email, and a separate superadmin app. Every user gets a personal org on signup, and billing is keyed to the org. Dodo payments are fully implemented. Stripe and Paddle are interface-complete stubs, and the README says so.

It is not for everyone. AWS is more setup than Vercel, and single-table DynamoDB has a real learning curve. The architecture doc is public, so you can decide from the code, not from this post. The license is a one-time payment, and the details are on the pricing section.