Skip to main content
Developer docs

For engineers maintaining Launchpad V2.

Everything you need to build, ship, operate, and debug the platform. Read Architecture once and keep it as a reference; live in Runbooks when things break; use Reference to look up connectors, environment variables, and schemas.
Repo ScaledByDesign/launchpad-v2
Stack Next.js · Inngest · ClickHouse · Supabase · Vercel

Start here​

01 · Set up
Day 1 setup
Zero to a running local dev environment. Prerequisites, keys, and the commands that get the app booting.
02 · Learn the system
Architecture
Data model, ingestion, reporting, auth and tenancy. The "why" behind the code.
03 · Operate it
Runbooks
Symptom → diagnosis → fix → prevent. Sync failures, ClickHouse rollups, Inngest steps, incident response.
04 · Look things up
Reference
Connectors, environment variables, ClickHouse and Supabase schemas, credentials inventory.

Repo layout​

src/app/
Next.js app router — portal, admin, and marketing surfaces
src/app/api/
Server routes — reporting endpoints, ingestion webhooks, MCP, auth
src/inngest/
Durable ingestion and rollup functions
src/lib/
Domain logic — marketing, attribution, tenancy, RBAC, connectors
src/components/
React UI components (admin panels, marketing reports)
clickhouse/migrations/
ClickHouse fact tables, rollups, and views
supabase/migrations/
Postgres schema — clients, users, config, RLS
scripts/
Audit gates, backfills, and one-off maintenance scripts
docs/
This documentation site (Docusaurus)

Folder guides​

Load-bearing folders may provide a folder guide (AGENTS.md) next to the code. Treat it as scoped engineering guidance and verify behavior in the current source and runtime; many folders do not have a local guide.

What's where​

  • Architecture — read once, keep as a reference. The "why."
  • Runbooks — opinionated procedures for when things break or run on a schedule.
  • Reference — machine-readable side: connectors, env vars, schemas, credentials.
  • Onboarding — zero to first PR for a new engineer.
  • Specifications & audits — one maintained master per subsystem, with historical evidence recorded in provenance rather than duplicate pages.

Edit any page by clicking the pencil icon at the top — it opens the source .md file on GitHub. Docs and code ship in the same PR.