A foundation you can build on.

The work every product repeats

A new product starts with a particular problem. Its first weeks often look much less particular: sessions, workspace records, subscription state, background work, and email delivery. These pieces need to cooperate before the product can do anything useful — each is a solved problem in the abstract and an integration risk in the specific.

supastack gives that repeated work a home. A Next.js web app and an Expo mobile app share TypeScript packages for the infrastructure underneath. The aim is to make those boundaries understandable enough that a product can configure them without inheriting somebody else’s domain model.

None of the pieces is hard in isolation. The cost lives in their coordination — a payment that must become an entitlement, a session that must become a workspace scope, a task that must survive a closed laptop. Products rarely fail on a missing feature. They fail on a seam.

Why build it once, properly

The argument for shared infrastructure is not that the work is beneath you — it is that the repeated work deserves to be done once, carefully. A workspace boundary implemented well in a shared module protects every product built on it. The same boundary improvised per product becomes a set of near-misses that differ in interesting, dangerous ways.

It also concentrates maintenance. Provider APIs change, auth libraries evolve, billing semantics drift. When those changes land in one place — the kit’s module documentation tracks them — a fix propagates instead of being re-learned per project. And when you are weighing the trade for a single product, starter kit or from scratch applies the same reasoning to the buy-versus-build decision.

Shared infrastructure concentrates review, too. A boundary that lives in one place can be tested hard once — negative cases, replayed events, cross-tenant attempts — instead of hoping five re-implementations each got it right. That is part of why the kit invests in its test suite: maintaining confidence in shared code is cheaper than re-earning it per project.

Give each module one responsibility

Identity establishes who is making a request. Workspaces determine which records that person can access. Billing records payment state, while entitlements answer whether a capability is available. Keeping these concerns distinct prevents a successful payment redirect from becoming an authorization decision.

The same discipline applies to background work. The shared JobRunner contract promises enqueue, status, and cancel. Trigger.dev owns the workflow behavior. A small interface is valuable when its limits are visible; hiding retries or scheduling behind a generic method would make the system harder to reason about.

Better Auth answers identity. Postgres and Drizzle hold the records. Stripe or Lemon Squeezy report payment state. None of them is asked to be clever about another module’s job — the seams stay narrow enough to reason about — and a foundation is only as trustworthy as its seams.

Leave room for the product

A prospecting workflow, a document editor, and a research assistant may use the same identity and billing modules. Their records, language, and workflows are still different. Product-specific logic belongs in the consuming product codebase, with configuration connecting it to the foundation.

This separation is also a practical maintenance decision. A fix to workspace isolation should be reusable. A change to how one product scores a prospect should not become a new requirement for every other product.

That is the difference between a foundation and a theme. A theme gives you a look to keep or replace. A foundation gives you load-bearing decisions — who owns identity, how records are scoped, where a payment becomes access — that a product builds on rather than works around. The project structure guide shows where one ends and the other begins.

Start with one complete flow

Begin with the local reference flow: sign in, inspect access, submit a task, and read its result. Fake and local adapters let deterministic tests exercise the path without paid provider requests — the five-minute quickstart runs it end to end. Then configure the production integrations your product actually needs.

Local acceptance and production acceptance answer different questions. A passing local test establishes application behavior under controlled conditions. Real authentication persistence, provider delivery, deployment, and device behavior still need their own verification. Keep that distinction visible as the product grows.

A foundation earns its name slowly: in the second product that ships faster than the first, and in the maintenance day that fixes one module instead of five codebases. That is the bet behind supastack — and it is the bar each module is held to.

Questions behind the approach

A few questions sit underneath this approach, and they are worth answering plainly.

• Is supastack a template or a framework? — A foundation of modules with contracts between them. Product code lives outside Starter Core and connects through configuration, so the platform can be updated without forking your features.
• Won’t shared infrastructure make products generic? — Only the plumbing is shared. Records, workflows, and language stay in the product codebase — the parts customers can actually see remain yours.
• Where does the product’s own code begin? — With the records and workflows only it has. The foundation authenticates the user and scopes the data; it does not know what a prospect is.
• Why a monorepo? — So the web, mobile, and desktop apps change together with the packages underneath them: one type system, one test gate, no drift between repositories.
• What if I only need the web app? — The foundation is the purchase; mobile and desktop are surfaces to adopt or ignore. Nothing forces you to ship an app you do not need.