Skip to content

The methodology

  1. Dream at full fidelity. Describe the product you can see in your head — not an MVP, the v5. It’s rendered as marketing pages, doc pages, and screen components. Iterate until the site matches the picture in your head. Copy and HTML/CSS cost pennies; app code is expensive and churns.
  2. File decisions as content. Every decision gets a DEC-nnnn record tiered by when it must be resolved (resolve_by: mvp | v1 | v2 | ...). Unresolved decisions are not failures — they’re filed against future versions.
  3. Roadmap session. Every feature is tagged with the version it first ships in. The roadmap is a generated page, not a document that can drift.
  4. Build per version, in vertical slices. Close every decision tiered to the version, build it, ship it, reconcile, move on.
  5. Trace everything. Permanent IDs link marketing claims ↔ docs ↔ decisions ↔ screens ↔ tests ↔ code ↔ PRs, so drift is reviewable in both directions forever.

The v5 site matches the builder’s mental picture. Buildability is irrelevant here. Decisions only need tiering, not resolving.

Every feature gets a version. MVP is fewer features done completely, never all features done badly. The MVP test: would the builder actually switch to this today?

Enforced mechanically: a version cannot enter build while any decision with a matching resolve_by is unresolved. A feature is not status: built until its ID resolves in code and tests.

After each shipped version, a reconciliation pass patches the vision site with what building taught us — and the drift check runs in both directions: code deviating from spec, and vision pages deviating from learned reality. The v5 site is a living document, not a monument.

The agent knows which gate the project is at and behaves accordingly. During the vision phase it never writes app code, deflects aesthetic tweaks into decision records, and defers architecture notes entirely — during dreaming, architecture pages are the procrastination trap in a new hat.

4 open decisions