Customize Your Product

Set the starter's identity, languages, visual preset, theme, legal details, and optional systems before you build product-specific features.

By the end of this page, the starter will look and route like your product, and you will have an explicit keep, configure, or remove decision for every optional system. Do this before changing individual screens: identity and product boundaries affect URLs, emails, legal copy, analytics, billing, and the admin console.

What ships and what you decide

Area	Shipped behavior	Your decision
Product identity	`saas.config.json` tracks the neutral name, slug, support, and docs URL	Run the customizer and review the tracked diff
Support	Support email is an explicit tracked product value	Set it before launch, or deliberately leave the public support promise elsewhere
Languages	English, Chinese, Spanish, French, and Japanese are available; URL prefixes are `as-needed`	Choose the default, enabled set, and browser-locale detection
Visual language	`studio` is the build-time preset shared by the web and admin apps	Keep it or choose `glass`, `soft`, `editorial`, or `brutalist` in code
Color mode	The customer app defaults to `system` through an environment variable	Choose `system`, `light`, or `dark`; the admin app does not yet have a theme-mode switch
Legal pages	A visible draft skeleton describes the starter's default data flows	Fill every identity and policy decision, then obtain legal review
Optional systems	Billing, storage, email, Slack, analytics, referrals, tasks, and reservations have code or adapters	Keep and configure each one, or remove its UI, validation, routes, and documentation together

Recommended starting point

Use a real product name, keep system color mode and the studio preset until the product's information architecture settles, and enable only languages your team can maintain. Keep analytics, advertising, referrals, and demo features off until you have a reason, user-facing copy, and an operating process for them.

The alternatives are valid, but they create work. More locales widen your audience and your translation obligation. A stronger visual preset creates differentiation but needs a complete light/dark and admin review. Enabling an integration is faster than building one, but it also adds credentials, failure modes, privacy disclosures, and support work.

Set identity and locale behavior

Run the tracked customizer before editing individual screens:

pnpm customize

pnpm customize -- \
  --name "Acme Cloud" \
  --slug acme-cloud \
  --preset glass \
  --locales en,fr \
  --default-locale en \
  --support-email support@example.com \
  --docs-url https://docs.example.com \
  --yes

The command validates and atomically writes saas.config.json, then synchronizes matching public values into existing ignored environment profiles without touching secrets. --dry-run prints the candidate; --no-env leaves profiles unchanged. Deployment variables may override public values, but the production config gate rejects an override that contradicts the tracked product identity.

Choose one visual preset

Choose the preset through pnpm customize or edit the tracked value:

{ "appearance": { "preset": "glass" } }

src/config/style.ts derives its typed value from this file. The same preset is rendered by web and admin; it is a build-time product choice, not a per-user picker.

Finish the legal identity

Fill LegalData in src/config/legal.ts: registered entity name and address, privacy and legal contacts, governing law, effective date, and the actual sub-processors you use. Work through every bracketed policy placeholder. Until all required identity fields exist, LegalConfig.isConfigured remains false and the privacy and terms pages show an unreviewed-draft notice.

The included text is a drafting skeleton, not legal advice or a finished policy. Remove providers you do not use, add providers that receive personal data, reconcile retention promises with account erasure, and have qualified counsel review the result.

Decide the product boundary

For every optional system, record one of three decisions:

Keep: configure credentials, user copy, monitoring, failure handling, and an owner.
Adapt: change the policy or provider behind the existing service boundary, then update tests and public guidance.
Remove: remove routes, UI, production validation, jobs, and documentation in the same change. An empty credential is not a product decision.

Continue with Plans and Entitlements, Stripe Billing, Storage Uploads, Analytics and Consent, and Deployment and Security for systems you keep.

Verify before feature work

pnpm config:check
pnpm config:check:prod
pnpm lint
pnpm test:run
pnpm build:web
pnpm build:admin

Then verify the default locale is unprefixed, each enabled non-default locale resolves, the language selector cannot choose a disabled locale, the docs and support links go where promised, both apps use the selected preset, and the customer app behaves in light and dark mode. Open privacy and terms: a public launch is not ready while the draft warning or policy placeholders remain.

What is not finished for you

The starter does not include a brand configurator, runtime preset picker, admin dark-mode provider, environment-driven support address, reviewed legal policy, or a decision about which optional systems belong in your product. Those are adopter decisions by design.

Source snapshot

Verified against starter commit 2a1a04a:

Customize Your Product

On this page