What we run, where

The system splits into always-on per customer (Maestro is awake, listening, ready to act) and on-demand (every specialist spins up a fresh Sapiom µVM when called, tears down after). Five external platforms carry the load. This page is what lives where, why, and how the pieces connect on signup and during the first build.

scope  The build target is Implementation 2 — Stripe Projects (summary above). The detailed walkthrough below still describes the Implementation 1 hand-wired topology; each Stripe Projects service maps onto the hand-wired one it replaces per the table above. The full side-by-side component map lives on the build page.

1 · At a glance

Five platforms carry the work. Each column shows what runs there.

2 · Always-on (per customer)

Four things run continuously for every signed-up customer. They are not "spun up on demand" — they're awake all the time, even when the customer is asleep.

3 · On-demand (the workforce)

Every specialist (Max, Vic, Sac, Jon, Tom, Roy, Moz, Sid, Sal, Ray, Lou, Nic) is dormant by default. When Maestro decides to call one, a fresh Sapiom µVM boots, the tool runs, the µVM tears down. Nothing about the specialist persists between jobs except the artifacts it commits.

Node-only ⇒ service  The base image is deliberately Node-only (decision S13). The rule that keeps it that way: anything non-Node is a service behind an HTTP boundary, never a package in the image — scraping (Scrapling), and likewise browser screenshots, headless PDF rendering, or any future binary dependency. The µVM stays small and fast; the heavy runtime lives in its own service the tool calls.

4 · Three data stores, one purpose each

Nothing lives in two stores. Each piece of data has exactly one home.

5 · The signup sequence

What happens when a brand-new customer hits tenwhy.com and signs up.

1. Visitor lands at tenwhy.com Marketing site (static-ish). Submits email to start. Render web service · cached at Cloudflare edge
2. Magic-link email Custom auth: signed token → store in Postgres with 15-min TTL → send link via Cloudflare Email Service. Postgres (token) · Cloudflare Email (delivery)
3. Customer clicks link Token verified, session cookie set (HTTP-only). Customer record + slug provisioned. Subdomain claimed: <slug>.tenwhy.com. Postgres (account) · Cloudflare DNS (wildcard cert)
4. Brain repo created A private repo at tenwhy-brains/<slug> is created via the GitHub API. The customer's GitHub identity is not used; the platform PAT does it. GitHub API
5. Maestro session opens Customer lands on their dashboard. Maestro greets them, starts the interview. Chat goes to the multi-tenant Maestro service; replies stream back via the OpenRouter gateway. Render (Maestro · dashboard) · OpenRouter (LLM)
6. Brain begins to fill As the conversation produces facts, Maestro commits HTML documents to /maestro/ in the brain repo: business.html, customer.html, etc. The dashboard's right pane re-renders live. GitHub (commits) · Postgres (dashboard.json) · json-render.dev
7. Interview ends · workforce is empty No specialists exist yet. Maestro proposes hires based on what the customer needs. Maestro (decision) · Postgres (proposed-hires table)

6 · The first build — todo app, end to end

Customer says "I want a todo app." What happens next, from Maestro's first move to a live URL.

1. Maestro proposes hiring Nic Posts an Approve card to the dashboard. Customer clicks Approve. Dashboard · Postgres (hire approval)
2. Maestro fires a µVM POST to Sapiom API: { tool: "tenwhy-tools/nic", spec: {…}, webhook: "https://maestro.tenwhy.com/v1/jobs/<id>" }. Sapiom returns a job ID immediately. Maestro is free to handle other customers. Maestro → Sapiom (async)
3. µVM boots and prepares Node base image. Bootstrap token → Infisical → fetches GitHub installation token + Render API key (both scoped, short-lived). Clones tenwhy-tools/nic. Sapiom (µVM) · Infisical (secrets) · GitHub (clone)
4. Nic builds the app Reads the brain (business.html, audience.html, etc.) for context. Generates a Next.js app via the LLM (OpenRouter). Writes the code to a fresh repo: tenwhy-builds/<cust>-todo-<short>. OpenRouter (LLM) · GitHub (new build repo)
5. Deploy to Render Nic calls Render's API: create web service from the new repo, set env vars (data API key, slug, etc.), trigger deploy. Render builds + deploys. URL: <cust>-todo-<short>.onrender.com. Render API (create service) · Render (build + deploy)
6. Nic commits to the brain Updates /nic/builds.html in the brain repo: lists this build, URL, repo, status, timestamp. Updates dashboard.json in Postgres so the dashboard shows a "Your todo app" widget. GitHub (brain) · Postgres (dashboard.json)
7. Nic webhooks Maestro POSTs { status: "ok", artifact: { type: "render-service", url: "…" }, log: "…" } to Maestro's webhook. HMAC-signed for verification. µVM exits. Maestro webhook · µVM teardown
8. Maestro tells the customer Next chat turn: "Your todo app is live at cust-todo-x12.onrender.com." Dashboard widget appears. Done. Maestro reply · dashboard re-render

7 · Auth and secrets — the security model

Two layers: customer-facing auth (humans into the dashboard) and service-to-service auth (Maestro → Sapiom, µVM → vault, µVM → GitHub/Render).

runtime ≠ CI  This is the runtime security boundary — and it, not agent-cli-kit verify, is what stops a misbehaving tool. verify checks a CLI's shape in CI; the boundary is enforced here: per-job scoped credentials with a read/write split (read for plan, write for apply), network-enforced egress allow-listing (open verification on the build page), a brain-path allowlist on commits, and signed tool releases. Conformance is quality; the sandbox is security (design #32).

8 · Stack decisions locked in this session

Ten decisions made today — each one a constraint on everything downstream.

9 · Still open — for a later session

Each now has a decided approach (below). None block starting v0.1.