Project tour

A generated app is a single, standalone Next.js project — the monorepo scaffold is gone, collapsed into one package.json. Here's the lay of the land. Exact contents depend on your feature selection; a pruned feature's directory simply isn't there.

Top level

my-app/
├── src/                  # application source
├── prisma/               # Prisma schema + migrations
├── e2e/                  # Playwright end-to-end specs (feature-owned)
├── tests/                # shared test config + helpers
├── public/               # static assets
├── docs/DEPLOY.md        # Vercel-first production guide
├── docker-compose.yml    # Postgres + selected features' services
├── .env.example          # committed template; .env is your local copy
├── .saas-starter.json    # the stamp: features + template version
├── package.json          # one standalone manifest (no workspace)
├── next.config.ts
├── tsconfig.json
└── README.md             # lists the features you selected

Inside src/

src/
├── app/          # Next.js App Router routes
├── components/   # shared UI (ui/ primitives + blocks/ once you add them)
├── config/       # app config (plans, usage limits, …)
├── content/      # content-collections sources (marketing/blog)
├── features/     # one directory per feature — the heart of the app
├── lib/          # framework-agnostic helpers
└── server/       # tRPC server, db client, auth, routers

features/

Each feature lives in its own directory under src/features/<name> and prunes as a unit. A full app has:

features/
├── auth/         orgs/         jobs/         email/
├── billing/      flags/        usage/        api-keys/
├── files/        audit-log/    marketing/    admin/
└── observability/

Your app only contains the features you selected — the rest were deleted during generation. Feature code that touches another feature is wrapped in @feature markers in the reference app; those markers are resolved (kept or removed) at generation and never appear in your generated code.

server/

The tRPC layer: db.ts (the Prisma client), auth.ts, router.ts and routers/ (the API surface), plus core org/service helpers. This is where the app's data access and procedures live.

What's not in a generated app

The generator removes repo-development tooling that only makes sense inside the reference repo:

• features.json — the prune manifest. A generated app is already pruned; its feature set is recorded in .saas-starter.json instead.
• The block registry (src/registry) — ships inside the CLI so add can read it, but a generated app is a consumer of blocks, not a carrier of the catalog.
• The @feature marker lint and the ESLint feature-boundary rule — they read features.json, which no longer exists.

The stamp

.saas-starter.json at the root records which features your app was built with and which CLI version produced it:

{
  "templateVersion": "1.2.3",
  "features": ["auth", "billing", "email", "jobs", "orgs"],
  "generatedAt": "2026-07-18T00:00:00.000Z"
}

The add command reads it to know which blocks your app can accept and which CLI version to install them with. See the stamp and versioning for the full policy.

Next steps

• Browse the Features guides for the features you selected.
• Install a composed block with create-saas-starter add.
• Read the generated docs/DEPLOY.md when you're ready to ship.