Starter kit or from scratch? Decide what you want to own

Separate product work from repeated infrastructure

List the features that make your product useful, then list the infrastructure it needs to operate. A research workflow may be distinctive; session handling, customer-owned records, and subscription access usually are not. This inventory gives you a better evaluation tool than counting the number of features on a starter's homepage.

The second list is longer than it looks. Most SaaS products re-implement the same dozen pieces, and each one has to integrate correctly with the others before the product can do anything at all.

Building from scratch gives you direct control over those choices, but also responsibility for integrating and maintaining them. A starter changes the starting point. You still need to understand its code and verify the assumptions it makes about your product, team, and deployment.

• Identity: sign-in methods, sessions, account recovery.
• Workspaces: record ownership, invitations, member roles.
• Billing: checkout, webhooks, entitlements, cancellation.
• Background work: queues, retries, schedules, status tracking.
• Delivery: transactional email, file storage, deployment.

Compare total cost, not the sticker price

A starter's price is visible; the from-scratch cost is distributed across months. Tally it honestly: the weeks spent assembling auth, billing, jobs, and deployment; the integration bugs those assemblies ship with; and the maintenance each provider update triggers afterward.

The starter's cost is learning and adapting code you did not write: reading its conventions, replacing sample content, occasionally bending a boundary it drew. When the inspection below goes well, that trade is usually cheaper than rebuilding the same plumbing. When it goes badly, it is a warning you should not ignore — an unreadable boundary today is a production incident next year.

Evaluate the code you will inherit

Run the setup instructions and follow one record from the interface to persistence. Check whether authorization lives at the server boundary, whether configuration is validated, and whether provider credentials stay outside client bundles. Read a negative test, not just the demo screen.

Look for places where the example product has become inseparable from the infrastructure. If removing a demo feature requires changing authentication or billing behavior, future product work may be harder than the initial setup suggests. In supastack, consuming products keep their domain logic outside Starter Core and connect through configuration and contracts — the project structure guide shows where that line sits.

• Every undocumented setup step you had to figure out yourself.
• Where authorization is enforced, and whether it is per-route or systematic.
• Whether a negative test exists — a cross-workspace read, a replayed webhook — and what it proves.
• Where secrets live, and whether any reach a client bundle.
• What happens to the infrastructure when you try to delete a demo feature.

Run it before you decide

Spend a day inside the repository before committing. In supastack that means corepack pnpm install, a configured apps/web/.env.local, and the local reference flow: sign in, inspect access, submit a task, read its result. Then pnpm verify:local runs the golden path against fake providers with no credentials required — the local setup guide walks through the sequence.

Then break something on purpose. Submit the same task twice. Call an API route with the wrong workspace. Replay a webhook. A starter that handles ordinary failure gracefully is worth more than one with a longer feature list, because what you cannot make fail cleanly on your machine you will eventually debug in production.

Make the tradeoff explicit

Choose a starter when its existing boundaries match your needs and you can explain the flow you will depend on. Choose a custom foundation when the product's constraints would force repeated changes to the starter's assumptions. Either choice can be reasonable; the important question is which maintenance burden your team can carry.

Reserve time to replace sample content, configure integrations, review data ownership, and test deployment. A repository that compiles is a starting point for production acceptance. Before launching, verify the real sign-in path, billing lifecycle, and recovery behavior in the environment your customers will use — the launch checklist enumerates it. And if the underlying stack is also undecided, choosing a SaaS stack covers the layer-by-layer evaluation; the two decisions inform each other.

Common questions about starter kits

The buy-versus-build debate generates strong opinions. These are the questions that actually move the decision.

• Is using a starter kit risky for a serious product? — Plenty of production SaaS runs on bought foundations. The risk is not the starter; it is inheriting code you have not inspected. Read the boundaries before you depend on them.
• How do I tell if a boilerplate is maintained? — Look for recent commits, a documented update path, tests that exercise failure cases, and issues answered with specifics rather than roadmap promises.
• What if the starter's choices don't match mine? — Distinguish preferences from constraints. Re-skinning a UI is cheap; fighting a session model or a tenant boundary is not. A structural mismatch is a reason to build your own.
• Can I move off a starter later? — You own the code, so there is nothing to migrate away from — the real question is whether its plumbing stays an asset as you modify it, which is why separable product and infrastructure code matters.
• How much time does a starter actually save? — Roughly the weeks that auth, billing, jobs, and deployment would have taken, minus the days needed to learn and adapt what you inherited.