Provisioning a platform

The steps

1. Create the platform — superadmin only; there is no self-serve path, by design. Name, slug, description. New platforms start in test mode.
2. Grant modules — toggle the catalog for this platform. Dependencies apply (forms needs records; websites and invoices need customers). Unknown keys can't be stored.
3. Issue keys — a secret key for the platform front end's server, a public key (with origins) if the browser needs direct reads. Values shown once; put them in the front end's env (DASH_PLATFORM_KEY, never NEXT_PUBLIC_* for the secret).
4. Declare record types — the platform's schema: its entities, fields, flags. This is where the vertical becomes real.
5. Stand up the front end — the dashboard/portal app on the platform SDK; nav and routes derived from whoami().platform.modules.

Seeds make it repeatable

Provisioning that lives in a runbook decays; provisioning that lives in seed scripts survives. The working pattern: idempotent per-concern scripts (record types, app settings, categories, demo content) that update_or_create by key, so re-running refreshes rather than duplicates — the same discipline these docs are published with.

Provisioning a client site (agency-style platforms)

1. Create the customer; send the portal invite when they should have access.
2. Create the project, then its website record (1 project = 1 website).
3. Issue the site's dfd-site-* keys from the site's panel.
4. Scaffold the site from the platform's reference site on the paired site SDK.
5. Deploy through the managed flow — keys are injected into the app's env automatically.