What a SaaS boilerplate gives you, and what you still have to build

A SaaS boilerplate gives you the parts that are identical in every SaaS, such as authentication, billing, an admin panel, internationalization and CI/CD, and none of the parts that make your product worth paying for. That trade is usually worth it, but only if you know exactly where the line falls before you buy. CastorStack is the reference implementation used below.

What is actually already built

A production-grade foundation ships the plumbing that has one correct answer and no product differentiation:

  • Authentication: sign-up, sign-in, password reset, session handling and protected routes across every frontend. In CastorStack this is Supabase-backed, with the session validated server-side by the API rather than trusted from the client.
  • Billing wired end to end. Not a Stripe key field, but an actual checkout endpoint, signed webhook handlers, and the entitlement records those webhooks write. CastorStack ships both Stripe and Paddle, with a per-country routing rule that decides which one a given buyer goes through.
  • A product and pricing model: products, plans, features, and plan-feature bindings, editable from an admin panel instead of hard-coded constants scattered across the codebase.
  • An admin panel with user lookup, subscription state, payment-provider configuration, feature flags and audit logs.
  • Internationalization: locale routing, translation files and a language selector in each app. Retrofitting i18n after launch is one of the more miserable refactors in web development.
  • Test and deployment structure: unit tests on the frontends, API tests on the backend, end-to-end tests across both, and a pipeline that runs them.

The common thread: every item is something you would have built the same way, and every item is something you would have gotten subtly wrong the first time. Webhook idempotency, session refresh races, and the difference between "payment succeeded" and "access granted" are the kinds of bugs that surface in production, at a customer's expense.

What you still have to build

Everything that is the product.

No boilerplate knows what your application does. The dashboard is a shell, the example feature is an example. This is where all of your remaining time goes, and that is the point.

Pricing decisions stay with you. The model supports plans and feature gates; deciding that the Pro tier gets 10,000 API calls and the Free tier gets 100 is a business decision the code cannot make for you.

Transactional mail, meaning receipts, trial expiry and dunning, depends on a provider you choose and copy you write.

Your compliance posture is also yours: GDPR data-export and deletion requests, a data-processing agreement, a cookie policy that matches what you actually load. A template can leave hooks; it cannot be compliant on your behalf.

So are the operational answers. What happens when a payment fails three times? When a customer downgrades mid-cycle? When someone requests a refund after using the product for 29 days? The webhook that carries the event exists. The policy is yours.

Design too. A foundation ships a coherent, neutral design language. Making it look like your product is work.

The honest failure mode

The failure mode of buying a boilerplate is not that the code is bad. It is buying one whose architecture you do not want to live inside.

You are inheriting someone else's decisions about framework, database, auth provider, folder structure and deployment target. If those decisions match what you would have chosen, you save weeks. If they do not, you will spend those same weeks fighting the template, and you would have been better off starting empty.

So the buying question is not "does it have feature X?" It is whether you would have built it this way. Read the repository structure and one or two real modules before you pay. If the code makes sense to you in ten minutes, it will keep making sense in month six.

The second failure mode is staleness. A foundation is a snapshot of dependency versions on the day it shipped. Check when it was last updated and whether updates are included, because a boilerplate you cannot upgrade becomes technical debt with a purchase receipt.

How to decide

A boilerplate is worth it when:

  • You have built this layer before and know precisely how long it takes you.
  • The stack matches what you already work in.
  • Your product's value is in the domain, not in the infrastructure.

It is not worth it when:

  • Your product is infrastructure, and the boilerplate's choices conflict with it.
  • You are learning the stack. You will learn more, faster, from an empty project.
  • Your requirements are unusual enough that the generic layer is wrong anyway (multi-tenant with per-tenant databases, on-premise deployment, regulated data residency).

The realistic number

Building the layer described above properly, not as a demo but with webhook retries, tax handling, refunds, an admin panel and tests, takes an experienced developer somewhere between four and eight weeks. Calling it "a weekend with an AI agent" is marketing; the demo takes a weekend, the production-ready version does not.

That range is the actual value of a boilerplate. Everything after it is your job.