Customize the Starter

These are the intended extension points for the starter. Change these first instead of scattering one-off edits across the repo.

Best first changes

Area	What to change first	Verification
Product config	Name, promise, price, brand defaults, and homepage section or CTA defaults in `config/product.ts`	`bun run build`
Module flags	`starterConfig.modules` plus the neutral workspace-home fallback	`bun run build`
Marketing site	Hero copy, proof, FAQ, screenshots, and pricing sections	`bun run build`
Public blog surface	Blog CTA target in `config/product.ts`, editorial copy in `features/blog/content/blog.ts`, and posts in `content/blog/`	`bun run build`
Protected workspace	Mission framing, lesson chrome, artifacts, and settings surfaces	`bun run check`
Theme and styling	Colors, typography, spacing, imagery, and motion defaults	`bun run build`
Optional build helpers	Starter-template CTA and Codex-assisted build helpers	targeted checks

Good first milestone

A strong early milestone is:

the public landing page is rewritten
the protected workspace reflects your product language
the first real protected user flow is visible
the paid-access contract still works

If you are not keeping the guided course, the first real protected user flow should now be the packet-first workspace on /start, not a dead-end disabled shell.

Leave these alone until later

Do not start by rewriting:

checkout creation
webhook handling
access grants
success-page recovery logic

Those are the highest-risk parts of the starter.

Guardrails

keep config/product.ts as the first place to change product identity and route constants
keep homepage shell controls in starterConfig.homePage and let features/marketing/lib/home-page-render-model.ts translate them into rendering decisions
keep the public blog route in app/blog/[[...slug]]/page.tsx, the editorial UI in features/blog/**, and article source files in content/blog/**
use starterConfig.modules before inventing route-level hacks or manual hidden links
keep the landing-page offer work inside features/marketing/** and public/
keep the course runtime and lesson model inside features/course/**
keep starter-mode protected home work inside features/workspace-home/**
keep the access layer as the source of truth for product access
keep the purchase-to-access behavior aligned with the verified checkout and webhook contract

Starter mode

The starter now has a deliberate course = false mode.

When starterConfig.modules.course is false:

/start becomes the first protected workspace surface
/product, /design, /marketing, and /build-plan stay as stable stage-entry routes but redirect into nested packet pages
/mission and /lesson/[lessonKey] become the optional post-review bonus library after unlock, while /artifacts remains a compatibility forward into /review
the paid-access and access-recovery contract stays unchanged

That is the preferred way to move toward a non-course product. Do not start by renaming routes or rewriting the access stack.

What success looks like

You are customizing cleanly when the starter feels like your product before you have touched the fragile auth and billing path.

For the homepage specifically, clean customization now means:

section visibility comes from starterConfig.homePage.sections
hero and pricing CTA behavior comes from starterConfig.homePage.heroPrimaryCta and starterConfig.homePage.pricingPrimaryCta
section copy and assets stay in features/marketing/content/home.ts
features/marketing/lib/home-page-render-model.ts remains the single place that combines config with content

If the homepage is part of the change, use Configure the Homepage as the detailed source of truth instead of prompting from memory.