DREAMTEAM — Build Order v3 (post-scaffold)

What this is

V3 of the Build Order. Reconciles v2 (the 1A/1B grind sessions) with the actual implemented stack and Alex’s wave-level execution plan. v2 captured the product framing from the grind sessions; v3 updates the stack to match what was actually built and aligns phase structure with the engineering execution plan.

The headline thesis is unchanged: build the hub first.

Stack — locked (updated to match implementation)

Layer	Pick
Frontend	Next.js 15 (App Router) on Vercel
Backend API	Fastify (TypeScript) on Railway
DB	Supabase (Postgres + pgvector + Realtime + Auth + Storage)
Jobs	BullMQ + Redis
Repo shape	Monorepo — pnpm workspaces: `apps/web/`, `apps/api/`, `packages/shared/`
Memory layer	Postgres (codenamed Brain² / “Brain Two”)
AI SDK	Vercel AI SDK (BYOK — orgs bring their own LLM keys)
Shared types	`packages/shared/` → `@dreamteam/shared`

Why a separate Fastify backend: Agent runs are long-lived (minutes), voice needs persistent WebSockets, and background jobs need a persistent process. These don’t fit Next.js’s request/response model. Deploys to Railway with Redis addon for BullMQ.

Why BYOK: Every org provides their own LLM provider API keys (Anthropic, OpenAI, etc.). DREAMTEAM charges for the platform, not for inference. The AI gateway in apps/api/ resolves org credentials, routes through Vercel AI SDK, and logs usage.

Delta from v2: The grind session discussed “Anthropic API keys + Claude Agent SDK” and listed “Backend: Supabase.” The final architecture uses Fastify as a dedicated backend service (Supabase is the DB layer, not the backend) and the Vercel AI SDK as a provider-agnostic wrapper — orgs can still use Anthropic keys, but routing goes through Vercel AI SDK rather than the Claude Agent SDK directly.

Phase 1A — Brain + Project Management

The foundation. Nothing else ships until 1A is solid — every other surface reads/writes through Brain.

Ships in 1A:

Brain² (Postgres) — tiered memory spine (hot / warm / cold, smart cycling, critical-flag protection, sublinear retrieval). Karpathy-style architecture. Reference implementation: BRAIN2 (Nate’s vault) — shared with Alex as the canonical second-brain shape. Auto-save all chats; kill the manual /save step.
Document intelligence protocol — long docs → atomized bullet summary in the brain + index pointing back to the full doc. Per-folder intelligence: parent markdown auto-updates when children arrive, summarizing what each new doc is and how to navigate it.
Multi-Agent Orchestrator + Task Board — kanban-style task table; agents run on it and populate it. Basic dispatcher first (“single agent, shot completion”), then progressive escalation to swarm shapes. Board population: human + auto-extracted + agent-proposed. Status streams live (model, tokens, ETA). Per-orchestration knowledge pools scoped to project.
Overlap detection — when a teammate kicks off a new orchestration, the deployer agent surfaces what’s already been done: “hey, in this project you’ve already got like four of the things you want to do checked off by the work Alex did. So instead you’re going to start here.” (1A grind, verbatim).
Swarm visibility — when one teammate launches a 15-agent swarm, others see it as a single composite run with each agent expandable.
Reimagined Terminal (wrapped web app) — the whole hub operates like a terminal: conversational power, file/computer control via Claude Agent SDK, but with a UI non-technical users can navigate. “Same power as Claude CLI.”
File upload + PDF→markdown converter — pandoc-style ingest so all docs land as markdown for agents (agent-navigable) but render not-as-markdown for humans (“nobody reads markdown” — 1A grind, verbatim).
Custom link sharing — same shape as PARZVL/path proposals (parzvl.com/some-proposal-name). Replaces PDF-as-deliverable.

References for Phase 1A: Merydian, Macro. Plus a touch of Monday.com’s structural feel. UI lives somewhere between those three. Notion is anti-reference (see below).

Surface: web app first (the wrapped-terminal web app).

In Between — Shared Team Chat

Slotted between Phase 1A and Phase 1B because the orchestrator needs a chat layer to operate against, and because Alex has “built 600 of them” (1B grind) — low-risk delivery.

Ships:

Claude-style sidebar of every past conversation, fully navigable.
Context-drift detection (Wispr-style) — when a conversation shifts topic, spin up a new thread that stays aware of the prior one.
No-manual-save running doc auto-populated as the conversation unfolds.
Auto-route on close — archive triggers an instant save and routes the doc to the right destination. Direct Brain² intake — the auto-routed docs are the warm/cold feed for Brain².

Phase 1B — Multi-Agent Orchestration (deeper)

Sits on top of 1A. Conceptually 1B because the foundation is the brain + board; multi-agent dispatch is layered on top — but technically they ship in tandem because the orchestrator IS the board’s interaction model.

Adds beyond the basic orchestrator in 1A:

Swarm-sizing recommendation — given a brief, the orchestrator proposes a swarm shape (e.g., “5-agent mini + 1 reviewer” vs. “15-agent full swarm with mesh coordination”) based on brief complexity, deadline, team capacity, and prior swarm performance.
Auto-recognition of completion + board dedupe — agents emit task-delta events; DREAMTEAM marks progress and flags candidate completions against the existing board. “You already finished this last week, don’t redo it.”
Conversational Agent Interface (two-way voice) — voice in is solved (Whisper / WhisperFlow); add voice out + turn-taking for hands-free operation of the orchestrator.
Efficiency lens — per-teammate view of how AI is actually being used.
Privacy gate — solo / scratch sessions stay private; only runs attached to a task surface to the team.
Meeting Capture — Granola hook or native fallback; feeds Brain² and (later) pitch briefings.

Migration & Onboarding

One-click import from the tool the team already lives in — Notion first, then Google Drive, Linear, Asana, Coda.

Timing: v2 deferred this to post-first-clients. The wave-level execution plan (see Technical Architecture) sequences migration as Wave 7 — the final wave within Phase 1. Important for adoption but not on the critical path for core product experience. Teams can use DREAMTEAM without importing from Notion day one.

Open question: live two-way sync vs. one-time cutover.

Phase 2 — Pitch Intelligence + Presentation Deck

Once the hub exists, build the pitch layer on top of it. Deck + pitch intelligence ship as one coordinated slice.

Ships:

Presentation Deck — already mostly built (parzvl.com/dual-template, adaptive viewer, brand preset system, template marketplace). Phase 2 work: adapt to team-edible (multi-tenant brand presets, shared delivery, team ownership).
Pitch Intelligence — live editing engine + the three layers riding on it: pre-pitch adaptation (before), voice-reactive extension (during), follow-up deck (after).
Invisible Group Chat — moved here from Bucket 3 mid-1A. The team back-channel during a pitch.
Live Performance Dashboard — moved here from Bucket 3 mid-1A, reframed as pitch intelligence. Live pitch-coach signal rendered into the invisible chat surface.

Both relocated features are pitch-room tools — they only matter when a pitch is happening, so they belong with the pitch slice, not the always-on hub.

Cut — Creative Intelligence (Bucket 4)

Love-the-Work-More AI — out of this plan. Parked, not sequenced. Proprietary creative-data moat is a separate, far-future bet that depends on DREAMTEAM being a working product first.

Architectural primitives (from v2)

All surfaced by Alex during the 1A grind.

Hooks — every chat close / compact / clear fires a hook that writes to Brain². Hooks can attach to skills. Alex calls this “the missing piece” — without it, Brain² doesn’t actually get written to consistently. Reference: Alex’s own code-base-snapshot wiki built on hooks + MCP.
MCP-as-shared-context-broker — DREAMTEAM exposes an MCP that user agents (Claude, Cursor, Codex, etc.) consult. This is how multiple engineers stay on shared context across IDEs — they all hit the same DREAMTEAM MCP. Alex caveat: “Claude’s a little weird, you have to babysit it because it may not run the skills or even check the MCP” — harness work required.
Document-intelligence protocol — see Phase 1A. Atomized summaries + indexes is the pattern.
Custom-link sharing — see Phase 1A. PARZVL-style path links replace PDFs everywhere.

Wave-level execution plan

The phases above describe what ships. The Technical Architecture doc contains Alex’s wave-by-wave execution plan (Waves 1–7) that breaks Phase 1 into concrete backend deliverables, each unblocking specific frontend work:

Wave 1 — Foundation & Shared Contract (types, auth, org endpoints)
Wave 2 — Brain² (CRUD, search, tier cycling)
Wave 3 — Conversational Chat Layer
Wave 4 — Agent Runtime & In-App Task Board
Wave 5 — Voice Pipeline
Wave 6 — Meeting Capture
Wave 7 — Migration & Onboarding

Each wave ships backend work that unblocks Nate’s frontend work. See the architecture doc for the full item-by-item breakdown.

Anti-Notion (brand axiom)

Notion is explicitly disqualified as a model AND as a deployment target:

Agents struggle with Notion — calling the Notion MCP is “fucking atrocious” (1A grind). Markdown-native is a hard requirement for agent-navigability.
Visually we lean toward Merydian / Macro / Monday — explicitly NOT Notion’s feel.
Positioning — “we don’t even have to fucking say AI too much, just understand that it’s like a notion smacker” (1B grind).

Surface order

Web app — first. The wrapped-terminal web app is the primary surface.
Mobile companion — demand-gated. Ship web app, then figure out if teams actually want mobile.
Desktop app — after mobile.

(Spec said desktop-first; v1 inverted to web-first; v2/v3 keep that inversion.)

Roles & resourcing

Nate — hub UX/design, “lowest common denominator” first, collaborative iteration after. Frontend.
Alex — backend, infrastructure. Has built systems like this before (“I’ve built all these type of things in different projects” — 1A grind).
Joint — architecture decisions, GTM strategy, ICP refinement.

GTM

Demo motion — front-end mockup + scripted backend demo of multi-agent orchestration. Show first, then sell.
4-week post-sale build SLA — when a prospect says “we’re in,” the conversion is: “perfect, let’s figure out how to build that over the next four weeks.” Custom integration per landed client over a 4-week sprint.
Distribution channel — Thursday AI group as launch funnel (Nate’s invite, Alex on the first call).
Positioning aspiration — “the Palantir of biz dev."

"Flag shop” model (Nate’s coined term)

Flagship product (DREAMTEAM standard) + bespoke dev-shop work for enterprises requiring polymorphism and hyper-personalization. Hybrid: not pure SaaS, not pure consulting.

ICP

Primary

Any team doing shared projects
Solo founders / operators
Small teams / startups

Secondary

Sales teams
Tech teams (engineering hubs)
Creative teams
“Anybody who pitches anything or proposes anything” (1A grind, verbatim)

Enterprise

NOT first. Enterprises have security concerns and slow procurement.
Wedge via small teams inside large orgs — “Mr. Beast model.” Land in a 4-person team at a Fortune 500, expand from there.

Long-game / 2030 thesis

“In 2030 there’s going to be 100 billion agents. We want to be the preferred platform for agents to use to store their own memory.” — 1B grind, verbatim.
Agents-as-customers — second-order TAM is AI agents that need persistent memory across runs.

Recording protocol (team operating rule)

All calls between Nate and Alex (and future team members) recorded going forward:

Granola when on Google Meet / Zoom
Manual capture when on phone

Rationale from 1A grind: “I completely forgot like half the shit that I said” on a prior unrecorded call. Recording is mandatory, not optional.

Brand

Name: DREAMTEAMS (plural; singular .dev was taken — see project_dreamteam_oasis_rebrand_2026_05_14).
Domain: dreamteams.dev.
Slogan: “Build DREAMTEAMS”.
Logo: wordmark only for now, no emblem. Optional D-as-moon mark later, but “don’t lean too far into the sleepiness of dreams — it’s more about the team side, like making a sick roster” (1A grind).
Design ideation explicitly deprioritized: “don’t want to waste time on design, let’s make the important part happen first” (1A grind).

Delta from v2

What v3 changes vs. v2:

Stack updated to match implementation — Fastify backend on Railway (not “Backend: Supabase”), Vercel AI SDK BYOK (not “Anthropic API keys + Claude Agent SDK”), pnpm workspaces with apps/web/, apps/api/, packages/shared/ (not DREAMTEAMS-DEV/DREAMTEAMS-MAIN, web/).
Migration timing reconciled — moved from “deferred post-first-clients” to Wave 7 within Phase 1 (last wave, not critical path, but included in Phase 1).
Wave-level execution plan section added — cross-references the Technical Architecture doc’s Waves 1–7 breakdown.
All other content (phases, GTM, ICP, brand, anti-Notion) carried forward unchanged from v2.

Delta from the spec (DREAMTEAM-Spec)

Unchanged from v1/v2:

Build order inverts the spec — hub (Bucket 3) before deck (Bucket 1).
Bucket 4 Creative Intelligence → cut. Parked as future bet.
Invisible Group Chat + Live Performance Dashboard → relocated Bucket 3 → Bucket 2.
Reimagined Terminal added to Phase 1A.
Surface priority: Web → Mobile (if demanded) → Desktop.

Open inputs / next moves

Phase 1A schema design (pending — Alex’s local scaffold to define).
4-week post-sale build SLA mechanics — what’s the canonical 4-week template look like?
“Palantir of biz dev” positioning — how loud do we go with it?
Mr. Beast wedge tactics — how do we find the right 4-person team inside the right enterprise?

Created 2026-05-29. Supersedes DREAMTEAM-Build-Order-v2 (2026-05-28).