- Capture the app scope15 min
This build runs in eight ordered phases. Each phase ends with a working, checkable state — the next phase does not start until that check passes. Skipping ahead (installing a CLI mid-scaffold, wiring auth before the API contract exists) is the most common source of rework in this kind of build.
Scope & prepare tooling Accounts, local tooling, pnpm workspace and Claude Code conventions ready; usage estimated Web foundation TanStack Start running on the Cloudflare adapter, connected to Supabase API layer A shared, schema-validated oRPC contract wired in and proven with an authenticated call Mobile foundation Expo app running on a simulator, authenticated, calling the local API Core feature List and detail/create screens generated with AI and reviewed against the contract Cloudflare deploy Web app and API live on Workers with D1 bound; mobile app pointed at production Automate & monitor CI/CD on every push to main; errors visible on server and phone Ship & close One full feature shipped end to end; ongoing costs and maintenance on record The phase sequence this playbook follows, in dependency order. To do
Pick a short working name. It will label the repo, the Supabase project and the Cloudflare Workers project created later — changing it after those exist means renaming several dashboards.
Name the single thing a user opens the app to do. Everything built before the core-feature phase — auth, the API layer, the mobile shell — exists only to support this one feature; do not scope a second feature yet.
Each phase below has a concrete, checkable outcome. Nothing after 'Scope the Build and Prepare Tooling' starts until accounts and local tooling are confirmed working — do not skip ahead to scaffolding.
To note down
What is the working name of the app you are building?
Describe in one or two sentences the single core feature this app must deliver first.