Before You Customize

Rewrite the starter identity in files and folders

Choose the product name, short name, domain, support address, sender identity, audience, and one-sentence promise. Search tracked files and folders for old names, then update shared defaults before editing individual screens. Rename only customer-facing paths and copy; keep stable database, event, role, and provider identifiers unless a migration is planned.

• Product name and short name in files and folders
• Public and canonical URLs
• Support and sender addresses
• Logo, favicon, and social metadata
• Legal, SEO, billing, and email copy

git grep -n -i -E "shipflash|acme"

Create your repository before disconnecting the old one

Create an empty private repository in the customer organization first. Keep the local history by default, remove only the old remote, add the new remote, and push the first product-owned baseline.

• Create the remote first
• Verify the old remote before removing it
• Use a private repository
• Do not delete .git unless you intentionally want to discard history and have a backup

git status
git remote -v
git remote remove origin
git remote add origin <your-repository-url>
git branch -M main
git add .
git commit -m "chore: initialize customer repository"
git push -u origin main

Pause GitHub Actions during foundation work

The application CI workflow runs quality, database, build, and browser gates. Disable Actions from repository settings or add a temporary explicit job condition such as if: false; comments alone do not stop a workflow from running.

• Keep .github/workflows/ci.yml and codeql.yml
• Record who will re-enable CI
• Do not delete checks to hide failures
• Re-enable CI before staging or production

Establish a verified local baseline

Install the pinned toolchain, copy the environment template, use an isolated development Supabase project, and run the repository checks before adding product-specific behavior.

• No production secrets locally
• No shared production database
• Record the baseline commit and known warnings
• Use migrations and generated types as the database contract

pnpm install --frozen-lockfile
cp .env.example .env.local
pnpm run doctor
pnpm run quality

Write the product brief before adding features

Define the target customer, painful job, core workflow, paid outcome, roles, tenancy model, sensitive data, revenue model, support promise, and success metric.

• Customer and primary job
• Free, recurring, one-time, metered, or credit revenue
• Roles, ownership, and authorization
• Source-of-truth data and retention
• First measurable success signal

Choose modules deliberately

For every shipped domain, record keep, adapt, disable, or remove. Hide optional navigation before permanent removal, and trace routes, data, storage, jobs, webhooks, tests, and documentation first.

Build one vertical slice

Implement the smallest workflow that proves the product promise through a thin route, domain UI, validation, authorization, service, persistence, observability, and focused tests.

• Schema and constraints
• Persistence and source of truth
• Business rules and provider boundary
• Loading, empty, error, pending, and success states
• Retry, duplicate, and permission behavior

Re-enable gates and release gradually

Turn CI back on, run the full quality and build gates, deploy staging, verify provider test modes and production-like journeys, then release to a small cohort before widening access.

pnpm run quality:full
pnpm run build