META-001 — The grid as a working model

How to use the threads × phases × forks to plan your build and cut scope deliberately; the navigational backbone every other topic references.

What it is & why it matters

You are building a consumer app—from idea to shipped, operating product—across an invisible decision grid. Two dimensions: 15 continuous threads (security, privacy, payments, analytics, and 12 others) that each start early and run through every stage at once, and 18 phases across 8 stages of work (from "is this worth building" through "operate and grow it"). A third dimension: the [A]/[B] fork—one backend serving two clients (harder engineering, but unified data) versus two separate products (simpler per-product, but building two systems). Plus the monetization fork: one-time purchase, freemium, subscription, ads, IAP/consumables, B2B/enterprise, marketplace, donations, or open-core—which reshapes decisions across payments, compliance, and growth.

Why this matters: builders who don't see the grid decide twice about the same thing, cut scope by panic instead of principle, and miss dependencies that surface mid-Phase-7 when they cost weeks to fix. Without the grid, you design security in Phase 9 (desktop build) only to discover authentication is already baked wrong in Phase 7 (backend). You pick a database in Phase 5 without reading the sync-strategy thread (ARC-012), then reverse-engineer conflict resolution into a last-write-wins schema. The grid is a lookup map that stops this: "I'm in Phase 8 (mobile build), I need to wire payments. Which thread owns this? What did I already decide? What else touches this?"

The stakes: you avoid re-architecture, you ship on time, and you know what trade you're making when you cut scope.

Recommended default

Sketch the grid as a lookup table, not a checklist. Threads are your spine (pull one thread vertically and every phase it touches lights up); phases are your sequence (left to right, roughly ordered but with overlaps and iterations). [A]/[B] and $model are upstream forks that reshape entire regions of the grid. For execution: mark which threads and phases matter to your product in Stage I (validation, strategy, legal), and update your sketch at every phase gate. When you cut scope, trace the cut on the grid so you know what's deferred and what still needs wiring. Pair the grid with a dependency graph for high-stakes decisions—the connections between topics (in each topic's "Connections" section) show which decisions block which. The grid gets you 80% of the way; the DAG (directed acyclic graph) catches the 20% the grid simplifies over.

Why this default

The threads-as-continuous-discipline pattern prevents the re-decide trap. Security is not one decision you make in Phase 5 (architecture) and then forget. It is a thread that touches Phase 2 (legal scope), Phase 5 (architecture choices like encryption), Phase 7 (backend secrets management), Phase 8 (mobile secure storage), Phase 11 (security testing), Phase 13 (disclosure in marketing), and Phase 15 (incident response). If you decide "end-to-end encryption" in Phase 5 but don't wire it into Phase 7 or Phase 8, you've left the thread with teeth missing. The grid forces you to ask: "where does this thread live? What phases use it? Did I apply it everywhere?" A checklist cannot; it would explode to thousands of items. Threads compress concerns so humans can think about them.

The phases-left-to-right pattern maps to dependency order in most builds: you validate (Phase 0) before you design (Phases 3–4) because you can't design what you haven't validated. You design before you architect (Phase 5), and you architect before you build (Phases 7–10). This is not a law—you'll iterate, and mobile and backend often run parallel—but the default sequence minimizes rework. (Use a DAG or a Gantt to see which phases must serialize [backend before mobile] vs. which can parallelize [mobile + desktop building together on a done backend].)

The [A]/[B] and $model forks prevent the most common miscommunications and late-stage failures. "[A] one product, two clients" vs. "[B] two separate products" is the master topological decision; most builders say "we need mobile and desktop" and assume [A], when they'd be much happier with [B] (or vice versa, but less often). Monetization similarly reshapes huge swaths of the work—one-time purchase has a totally different backend shape than subscription, which differs from ads. The grid shows these forks early so you route to the right topic variants.

No external facts are claimed in this topic; it is a reasoning model, grounded in the reference's catalog structure: 15 threads × 18 phases + [A]/[B] fork + monetization spectrum + pointer-stubs = 389 decision topics total (see reference-map.md). The threads and phases are named and defined in reference-map.md; every topic lives on the grid; connections between topics outline the dependency graph that the grid simplifies over.

What flips the decision

When [A] vs. [B] reshapes the grid. If you are building [A] (one backend, two clients, unified accounts), the threads for sync (ARC-012), entitlement management (PAY-016), and cross-platform integration (XP-001 through XP-006) become load-bearing—you cannot skip them, and they dominate Phases 5–10. If you are building [B] (two products, two backends), those threads are often optional or much simpler. See META-002 for how to tell which you actually have; the default is [A], but the grid's shape changes sharply by fork.

When monetization fork reshapes the grid. If you pick subscription, PAY-005 (subscription state machine) and CMP-008 (recurring-billing compliance) become mandatory; if you pick one-time, you skip both and wire simpler entitlements. If you pick ads, PAY-018 (ad mediation) is a Phase 8 build task; if you pick subscription, it's optional. The $model fork tags 35+ topics that branch by choice. Most builders defer this decision to Phase 7–8 and then discover mid-build that their backend shape is wrong for the model they picked.

Brownfield vs. greenfield. If you are adding a second client to an existing product, or retrofitting onto legacy code, Phases 0–2 (validation / legal) may be done, but Phase 5 (architecture) is constrained by what was already built. You still use the grid; the filled cells are inherited. The grid helps you spot which constraints you own and which you inherited.

Regulated domain (healthcare, fintech, gambling). The compliance and legal threads dominate and constrain early. You may need CMP-001 in Phase 1, not Phase 2. The grid helps you spot this and reorder phases accordingly. Regulators also care about traceability: the grid is your traceability map (every decision, every phase, every thread interaction recorded).

AI-agent-driven development. If you're building with Claude Code or a similar AI agent, META-006 becomes a first-class variable: which cells does the agent fill vs. humans? Does AI speed up the build so much that you compress phases (skip Phase 3 design, iterate from Phase 5)? The AI thread doesn't change which decisions exist; it changes who makes them and the pace.

AI-first product. If your product is an AI feature (a code generator, a write assistant, a data analyst), the AI/ML thread (T13, prefix AI) moves earlier into Phase 1–2 (is ML the right tool for this problem?), and Phase 5 includes model selection and serving architecture. The grid still holds; the phase emphasis shifts.

Strong alternatives

Pure dependency graph (DAG). Build a directed acyclic graph where decisions are nodes and dependencies are edges: "Backend auth choice → mobile auth implementation → cross-device session state → sync engine design." This is more precise than the grid—you can topologically sort it, find the critical path, and spot exactly which decisions block which. But it's harder to reason about by hand; a 30-node graph is easier to navigate than a 200-edge DAG. The grid is a pragmatic simplification: threads and phases group concerns; the Connections sections (and implicit DAG) show the fine-grained cascades. Use both: the grid for orientation and communication, the DAG for verification.

Linear waterfall checklist. "Do Phases 0–18 in order, complete each before the next. Check off items." This is simple and map-like, but tempts you to "close out" phases prematurely and miss overlaps. You design in Phase 3 and commit to features before Phase 5 (architecture) spots that backend scale won't support it. The grid's thread spine prevents this by forcing cross-phase visibility. Checklist works for structured teams with buffer in timeline; scrappy small teams need the grid more.

Gantt chart or timeline. Show each task from start to end, with dependencies and critical path. This is excellent for scheduling a known project, but weak for planning a project you've never built. The grid is better for planning; the Gantt is better for execution. Use both: the grid to decide what to build, the Gantt to schedule when.

How to actually do it

A worked example: You're in Week 1, greenfield, [A] (one backend, two clients), one-time purchase, solo builder.

Phase 0–1 (Idea & Strategy): You sketch the grid on paper or a spreadsheet. You mark which threads and phases matter.

• VAL-001, VAL-004: problem definition and user research. You learn users want offline-first mobile, cloud sync, and a web app "later."
• STR-003: one-time $2 purchase (simpler than subscription, but decide this now).
• STR-005: v1 scope is iOS + cloud sync. Desktop/web is Phase 2 (deferred).

You mark the fork: [A] (one backend, two clients) + one-time-purchase $model. This means: ARC-012 (sync strategy) is mandatory in Phase 5, not optional. PAY-005 (subscription machine) is not needed. PAY-016 (entitlement sync for multi-client) is needed because you sync features across devices.

Phase 2 (Legal). You mark:

• LEG-001, LEG-002: privacy policy, terms.
• PRV-007: data residency. You're EU-first, so data lives in EU.
• CMP-008: subscription compliance is not needed; you are one-time purchase.

Phase 5 (Architecture). You mark:

• ARC-001: system architecture for [A] (one backend, two clients, sync).
• ARC-006: mobile stack. You pick React Native.
• ARC-007: deferred (web version is Phase 2).
• ARC-009: database. PostgreSQL.
• ARC-012: sync strategy. You decide: eventual-consistency with conflict resolution (CRDTs); you pre-wire the backend for it even though mobile v1 won't have offline support.
• PAY-016: entitlements. One purchase unlocks a feature; both mobile and web see the unlock.

You draw a 15-threads × 18-phases grid on paper and shade the cells you've decided and deferred. You see: VAL, STR, LEG, UX, UI are in v1; ARC, ENV are in v1; BE, MOB are in v1; DSK, XP are deferred; TST, SHIP, LAU are later.

Phase 7 (Backend). You mark:

• BE-001: backend tech. Node.js + PostgreSQL.
• All security, privacy, payments threads that touch Phase 7.

You build the backend. The ARC-012 decision (CRDT-ready sync schema) is now an implementation burden; every entity gets version, tombstone, parent-ID fields. This is pre-wiring for a desktop client you'll build in 6 months.

Phase 8 (Mobile). You build the mobile app. You mark:

• MOB-001 through MOB-010 (app architecture, performance, offline storage, etc.).
• PAY-016 (entitlements): you wire the one-time purchase unlock to your backend.

The ARC-006 and ARC-009 decisions from Phase 5 are now binding—you're on React Native, you're hitting PostgreSQL.

Phase 11 (Testing). You test the flow: buy on mobile, check that the feature works. You test on offline-to-online: make a change offline, sync online, check conflict resolution (even though v1 doesn't ship offline, you pre-wired it and test the path).

Phase 12–14 (Ship & Launch). You ship v1 mobile.

Six months later, Phase 9 (Desktop). You add the web app. The grid shows you which cells you pre-wired: ARC-012 (sync strategy is already decided and server-side-implemented), PAY-016 (entitlements sync), UX-* (desktop UX, new Phase 4 work for the second client). Because you traced the grid in Phase 5 and didn't split [A] into two separate backends, the desktop v1 is an add-on, not a rebuild.

Scope cut. By mid-Phase-8 (mobile build), you realize sync is harder than expected, and your runway is tight. You use the grid to cut deliberately:

Option A: Ship v1 mobile without offline support. Mark ARC-012 (sync) as "decided (CRDT-ready schema) but offline UX deferred to Phase-15 (growth)." The backend is still pre-wired; Phase 9 (desktop) will ship with better offline support once learned. Blast radius: medium (you're not removing the architecture; you're phasing the feature).

Option B: Defer desktop to Phase 2 (not v1). Mark DSK-* and XP-* as "Phase 2." The backend is still [A]-shaped; you're just not building the second client immediately. Blast radius: small (the grid shows you that Phase 9 is deferred, not cancelled; it can start whenever runway allows).

Each cut is visible on the grid. Without the grid, you cut at random ("just ship it") and discover in Phase 9 that you have no sync layer and you're now [B] (two backends), not [A]. With the grid, you cut deliberately and stay on your intended fork.

Costs & limits

The grid is a mental model, not a tool. There is no software to run, no cost, no scaling cliff. The cost is learning it (15 minutes of reading this topic) and maintaining it (5 minutes at each phase gate to re-check and update your sketch). Use a spreadsheet or a piece of paper; that's the "tool."

The grid groups decisions by thread and phase, but reality is continuous. Phases do not strictly serialize; mobile and backend overlap, testing runs in parallel with building, marketing prep happens while development is live. The grid assumes dependencies (you design before you build, roughly) but doesn't enforce them. This is a feature (the grid is flexible), but it's also a weakness: the grid can hide fine-grained dependencies if you don't actively trace the DAG. Pair the grid with Connections (implicit DAG) for high-stakes decisions.

The grid doesn't tell you how long each cell takes. It maps what; timelines map when. Confusing "the grid is filled" with "the build is done" is a trap. Every cell can hide weeks of work. Use the grid with a Gantt, a budget spreadsheet, or a project-management tool.

[A] is harder than [B]. The grid highlights this, but doesn't resolve it. One backend + sync + unified accounts is more engineering work than two separate products (each optimized for its surface). Most builders underestimate the [A] complexity in Phase 5 and discover it in Phase 7–8. The grid helps you see the complexity early, but you still have to make the trade-off between correctness and runway.

Threads can be orphaned if not actively threaded. If you decide "end-to-end encryption" in Phase 5 (architecture) and then no phase actually implements it (because you deferred all crypto to "later"), the thread is teeth-less. The grid shows the decision was made; it doesn't check that it was applied. Read each topic's Connections section and trace whether the decision is actually implemented somewhere, or you're building tech debt.

The grid is weaker for discovering missed dependencies than for tracing known ones. If you forget to mark a thread, the grid won't remind you. This is why re-checking at every phase gate matters: you ask "are there other threads that touch this phase that I missed?"

Pitfalls

The "quiet reclassification" trap. You sketch the grid as [A] (one backend, two clients, sync engine). Then in Phase 7 (backend) or Phase 8 (mobile), you realize sync is too hard or runway is too short, so you quietly ship v1 mobile-only with a single-client backend and tell yourself "we can add web later." You've silently shifted from [A] to [B] (or a confusing middle state). Mitigation: at Phase 6 (environment & foundations) and again at Phase 11 (QA), re-read your fork decision. If it has changed, name the change and update the grid. Don't let [A] slide into [B] by accident.

The "pre-wire and regret" trap. You decide to "pre-wire the backend for sync even though v1 mobile won't ship with offline support." You add CRDT fields to every entity, build a conflict-resolution layer, set up a change-log table. Then Phase 9 (desktop) discovers that the desktop UX for offline is totally different from mobile—it needs locking, not eventual consistency—so your pre-wired layer is wrong and needs to be rebuilt. Honesty: pre-wiring for a future client you haven't designed yet often fails. You are guessing about constraints you don't have yet. The safer pattern: ship v1 correctly for mobile, then refactor the backend for desktop if needed. You may pay the refactor cost once, or not at all if your guess was lucky. Compare that to pre-wiring wrong and paying to undo it.

The "deferred and forgotten" trap. You mark ARC-012 (sync strategy) as "decided in Phase 5, implement in Phase 10." You move on. Then Phase 10 arrives and you've forgotten what you decided, or the decision has become stale because the team composition or runway has changed. Mitigation: keep a written log of every thread decision with a date and rationale (this can be CLAUDE.md comments or a simple decision-record doc). Re-read it before you enter the implementation phase.

The "one thread, many phases" mistake. You decide on security in Phase 5 and think you're done. But Phase 7 (backend) needs secrets management, Phase 8 (mobile) needs secure storage, Phase 11 (testing) needs security testing, and Phase 13 (go-to-market) needs to communicate security to users. Not every phase touches every thread—but if a thread is live in Phase 5, scan which later phases touch it and mark them. A quick re-read of the thread's Connections section catches this.

Confusing the grid with a timeline. You sketch Phases 0–18 left to right and think "Phase 0 is done in Week 1, Phase 5 is done in Week 10." But Phase 5 (architecture) may iterate for 4 weeks, and Phase 7 (backend) and Phase 8 (mobile) may overlap significantly. The grid is not a timeline. Use it for scope and dependencies; use a Gantt for schedule.

The "checklist mode" trap. You treat the grid as a 389-item checklist and decide "I'll read and decide on every topic before I build." This over-systematizes small teams and burns runway. The grid is a lookup table: "I'm in Phase X, I need to decide about Y, which thread owns it? What are the topic IDs?" You read the topics when you need them, not upfront.

Connections

• META-002 — [A] vs. [B]: the upstream fork (one product, two clients vs. two separate products)
• META-003 — Platform priority & sequencing (mobile-first vs. desktop-first vs. simultaneous; web vs. native)
• META-004 — The art of cutting: how to use the grid to cut scope deliberately
• META-005 — Verifying dated facts: re-check time-sensitive facts (fees, laws, tool versions) at launch
• META-006 — Building with AI agents as the core process: the AI-agent variable reshapes the grid
• MON-001 — Monetization model selection: the $model fork routes to one-time, subscription, ads, etc.
• ARC-012 — Offline & sync strategy: the load-bearing thread for [A] products
• PAY-016 — Entitlement management & cross-device sync: where payments and [A] sync meet
• Reference-map.md — The canonical catalog of all 389 topics, organized by the grid

Sources & last-verified

This topic makes no external factual claims requiring independent verification. It is a reasoning model grounded in the reference's own catalog structure:

• 15 continuous threads × 18 phases across 8 stages + [A]/[B] fork + monetization spectrum = 380 real decision topics + 9 pointer-stubs = 389 total (enumerated in reference-map.md, verified 2026-06-26).
• Thread nomenclature (T1–T15, prefix conventions) and phase organization (8 stages, 18 phases) follow reference-map.md.
• The warp/weft metaphor (threads as continuous verticals, phases as sequential horizontals) is internal to this topic; the metaphor is structurally sound (threads are continuous, phases are sequenced) and needs no external verification.
• The grid-plus-DAG hybrid model (grid for lookup, dependency graph for cascades) is a reasoning recommendation; it has no external citation but is sound (lookup is faster than DAGs for navigation, DAGs are more precise for dependencies; the hybrid balances both).

Last-verified: 2026-06-26 (initial draft; conceptual reasoning model; no external facts included; structure against reference-map.md).