---
title: The Method
route: /method
lang: en
part_of: Onirion
version: "4.0"
date: 2026-09-22
author: Alexis Boyer
license: CC BY 4.0
one_line: "One Product Builder carries one product from a folder of scattered documents to something running in production, front and back; Design, Frontend, Backend and API, Data, access, delivery and review are the shared services that make it possible."
layers:
  summary: /method
  complete_text: /complete.md
  markdown: /method.md
---

# The Method

One Product Builder carries one product from a folder of scattered documents to something running in production, front and back; Design, Frontend, Backend and API, Data, access, delivery and review are the shared services that make it possible.

Owning the outcome does not mean doing every specialist job or managing every contributor. The horizontal services are partners in delivery, not a queue of disconnected tickets.

## The Principle

*Figure — image, 3:2: A capability owner handing over a reviewed pattern between two people — the horizontal serving the vertical, as one exchange.*

### The two dimensions

*Figure — the vertical, one product outcome carried by one Product Builder from a folder of documents through to production, crosses five shared services; each returns something usable, and together they make one product running in production.*

**Vertical · One product outcome.** One Product Builder accountable for one product, front and back: the problem, the decisions, the design that was accepted, the code, the backend and the verification, from the first folder of documents through to production.

| Horizontal · shared service | What it returns, usable |
| --- | --- |
| Design Ops | A design system that both the prototype and the front end draw on: the components and their states, the tokens, the rules for using them, what may be extended, and who maintains it. |
| Frontend Ops | An approved starter repository at a named version, with its architecture, routing and component conventions, the API-client pattern, the checks required on a deployable branch, and a version an agent can re-read before every change. |
| Backend and API Ops | An API catalog with real examples, authentication and permission rules, request, response and error shapes, a test environment with safe identities, and a written way to ask for an API that does not exist yet. |
| Data Ops | Where the reference data lives, the business meaning of key fields and status values, a test dataset that is safe to use, and the rules on what may be exported, by whom and to where. |
| Access, delivery and review | A request route with an approver and a response target, a path from local to the repository to staging to production, a way to see which revision is live, and developers who read the generated code. |

One product running in production.

- *Vertical · Product Builder* — **Own one outcome, front and back.** Carry the problem, the decisions, the design that was accepted, the constraints and the verification, from the discovery through to production. You draw on the shared services and you keep the outcome.
- *Horizontal · Shared services* — **Make expertise reusable.** Supply a named owner, an approved pattern or contract and its limits, a response route, and evidence that the contribution works in the running product — to you, and to everyone else doing the same job.

### A contract in both directions

**The Product Builder provides**

- The outcome, the users, and the context
- The contribution needed
- The constraints it has to sit inside
- An acceptance check
- A decision deadline

**The Ops owner returns**

- A named owner
- An approved pattern or contract, and its limits
- A response or delivery target
- A review path
- Evidence that it works in the running product

**Before building**

### Usable, not just documented.

A document alone is not a usable service. Before building, check which ones actually work: a named owner, a response route, approved access, a working environment, and a way to verify what comes back. When the starter, the conventions or the API you need do not exist, stop rather than invent them — a convention made up on the spot is what a reviewer will undo later — and ask the Ops owner for the artifact by name, with an expected response.

Meanwhile, record the substitute in the journal, dated: what you followed instead, with whose agreement, and what it stands in for. In a small team, one person may hold several of these roles; the responsibilities still need to be visible.

**Example**

On a sharing flow, the Product Builder owns the permissions the product intends and the behavior the people concerned accepted. Design Ops supplies the reviewed pattern and its states, Backend and API Ops the authorization contract, Frontend Ops the starter the front end is written inside, Data Ops the events that show how it is used. The Product Builder walks the flow end to end, with its empty, error and permission-denied states, and checks it as one product.

## The Path

From a folder of scattered documents to something running in production, alone, with coding and design agents doing the work you brief them for: seven gates in one order, and two things that run across all of them.

### Why the order matters

- A folder of documents is not a discovery.
- A discovery is not a PRD.
- A PRD is not a prototype the people concerned recognize as their tool.
- A front end you can click is not a product whose flows hold in depth.

**The question.** Which of those do you actually have in hand? Start where the answer stops being yes, and do not let a session walk through a gate you have not closed: ask it, at every gate, to state which gate it is at, what it has, what is missing, and what you must decide before it crosses. A session that cannot answer has left the method.

> “The line that closes a gate is what you should be holding before you move on.”
>
> — Alexis Boyer

*Figure — image, 21:9: Seven markers in a row on one surface: the sequence as a physical object, read left to right.*

### The seven gates

Seven gates, numbered 0 to 6. Nothing above them, and no sub-phases. Each one says what you do, what you hold when it closes, and the prompts and templates it uses.

### Gate 0 — Set up the project folder

- what_you_do: Put every document the project needs into one folder made for it, and open the session on that folder. Create the memory and the journal before anything else runs, and the project channel with everyone concerned in it. The first prompt converts and indexes; it interprets nothing.
- what_you_have_in_hand: everything in one folder, converted, inventoried
- resources: [Inventory and convert →](/resources/prompt-inventory) · [Memory entry →](/resources/memory-entry) · [Journal entry →](/resources/journal-entry)
- evidence_preserved: Project memory and journal

### Gate 1 — Gather the discovery

- what_you_do: Take stock of whatever you are starting from, and go through the sources for contradictions, ownership gaps and the same name used for different surfaces rather than for a summary. Have an agent read what nobody has time to read; what comes back is input, never a decision.
- what_you_have_in_hand: what is known, what is missing, what contradicts
- resources: [Read the channels →](/resources/prompt-channel-reading)
- evidence_preserved: Discovery notes

### Gate 2 — Write the PRD

- what_you_do: Run the analysis prompt on the folder, make it separate what is established from what contradicts and what is absent, and answer its alignment questions yourself. Then refine the PRD and align it with the business people, the technical parts included.
- what_you_have_in_hand: what is in and what is out, agreed with the business
- resources: [Write the PRD →](/resources/prompt-prd) · [PRD template →](/resources/prd-template)
- evidence_preserved: The PRD

### Gate 3 — Prototype the end-to-end flows

- what_you_do: The coding agent takes the PM role for this step: it writes the prompt for the design tool and demands end-to-end flows, not just the major screens. Iterate in the design tool, show it to the people who will use it, and keep going until they say it is their tool.
- what_you_have_in_hand: a prototype the people concerned recognize as their tool
- resources: [Design specification →](/resources/prompt-design-specification) · [Design instruction →](/resources/prompt-design-instruction) · [Refinement →](/resources/prompt-refinement)
- evidence_preserved: The prototype people accepted

### Gate 4 — Port the prototype into code

- what_you_do: Start from the organization's approved frontend starter and its backend conventions, never from an empty folder or the design tool's export. Then do the back-and-forths: the running front beside the design, you name what is off, the agent fixes it, you look again.
- what_you_have_in_hand: a front end that runs, that you can click
- resources: [Port the prototype →](/resources/prompt-port)
- evidence_preserved: The running front end

### Gate 5 — Connect the backend

- what_you_do: Swap the mock services for real ones, flow by flow, and go deep on each before the next: the empty state, the error, the slow response, the permission that says no. Roles and privacy are enforced at the read-model level, not in the component that displays the data.
- what_you_have_in_hand: the flows hold in depth
- resources: [Connect the backend →](/resources/prompt-connect)
- evidence_preserved: The connected flows

### Gate 6 — Test, then ship

- what_you_do: Give accounts to the people who should test while the connection work is still going on, share the life of the product in the channel, and fix what comes back as it comes back. Then take the go-ahead with the leads of the trades concerned, and ship.
- what_you_have_in_hand: accounts in real hands, then production
- resources: [Prepare a release →](/resources/prompt-release)
- evidence_preserved: The release record

### What the gates leave behind

| Evidence | Question it answers | Produced by | Gates |
| --- | --- | --- | --- |
| Project memory and journal | Why did the product move this way, and what happened when? | Two files created before anything else: the memory holds the current position, the decisions and the trade-offs; the journal holds the dated record, never rewritten, including what turned out to be wrong. | 0 |
| Discovery notes | What did the sources actually say, and where do they disagree? | The source list, the ambiguities, the questions for stakeholders, and a first hypothesis on the product boundary, written in the folder so the next gate can open it by name. | 1 |
| The PRD | What is being built, and what is not? | One document whose first section is the strategic framing, every assumption marked as an assumption with the source it rests on or the person who has to decide it. | 2 |
| The prototype people accepted | Is this the tool the people concerned need? | The end-to-end flows, with their states and their failures, iterated in the design tool and shown to real users until they say it is theirs. | 3 |
| The running front end | Can you walk the flows and click them? | A front end built inside the organization's starter, walked flow by flow beside the design, with what was adapted and what was deliberately left different written down. | 4 |
| The connected flows | Do the flows hold in depth, or only on the surface? | Each flow against the real backend, with its empty, error, slow and permission-denied states, and the roles enforced where the data is read. | 5 |
| The release record | What went out, verified how, and who gave the go-ahead? | What is in the release flow by flow, what was tested and with which accounts, what is known to be broken, and which review did not take place if one could not. | 6 |

Each gate is marked PASS, OPEN, or BLOCKED: pass; open — a named owner is resolving it; blocked — stops dependent work.

**What it takes.** From a folder of gathered discovery material to a front end you can click: three to four hours at best and twenty-four at worst, when the discovery has already partly been gathered. About a month to connect the backend so the flows hold in depth, depending on the size of the application. And the code still goes to developers for review, and passes, because the agent works inside the organization's starter and conventions. These figures are the author's own practice, not a study.

The AI builds fast, so the checks that matter are human ones. The people concerned accept the prototype at gate 3, and convincing has one meaning here: they say this is the tool they need. The code goes to developers for review before production, and the leads of the trades concerned give the go-ahead. Neither check is a stage bolted on at the end.

**Two things run across the gates** rather than inside one. The control session is a second session whose only job is to challenge the first: it reads, checks and challenges, it changes no code and decides no scope, and it returns findings with their evidence for you to decide on. The standing guardrail sends the agent back to the organization's frontend starter and backend conventions before every change to the code — not once at the start, every time. [Control session →](/resources/prompt-control-session) · [Standing constraint →](/resources/prompt-standing-constraint)

**Continuity.** The build does not stop at gate 6. The front stays demoable and keeps evolving: you go back into flows, deepen them, connect what was left, and show it again in the channel. One thing is deliberately frozen, and only one: an MVP that has to go to production, where what is in the release stops moving until it is out.

### Scale it to the risk

- *Narrow fix · starts at gate 6* — **A misleading label, reported by a tester.** The product is already in real hands and the wording is the whole change. Fix it as it comes back, inside the starter's conventions, walk the flow again, and let it go down the delivery path. Nothing here reopens the PRD or the prototype.
- *New product · starts at gate 0* — **A tool that does not exist yet.** One folder with everything in it, the discovery gathered and its contradictions named, a PRD agreed with the business, a prototype the people concerned call their tool, then the port, the backend flow by flow, and accounts in real hands before production.

These two examples show how much of the path a given piece of work actually runs. They do not describe a client project.