Are you not a developer? Good.
The prototype is not the product. This is the most important thing to understand about how we build — and the most commonly misunderstood. The prototype is cosmetic. No data. No runtime. No connected systems. Nothing persists. Nothing executes. It is a high-fidelity mock, and calling it a mock should feel disrespectful given how production-ready it looks. That is the whole point.
The product looks production-ready because it has to. A blueprint that looks unfinished produces an unfinished building. The fidelity of the prototype is not vanity — it is the methodology.
Step one: UI first, from deep UX understanding
Not wireframes. Not lo-fi sketches. A high-fidelity prototype built from genuine product taste and deep user experience sessions. This becomes the living blueprint — not a PDF, not a Figma file you present once and archive. A running thing you can point at, walk through, and think from.
Because the UI was built from deep understanding of the user experience, the flows are already implicit inside it. You are not inventing them later. You are transcribing what the prototype already shows.
Step two: flows from the prototype
Because the prototype exists and is high-fidelity, the flows can be written with real specificity. General first — enough to communicate the user story, the scenario, what gets accomplished. Then decomposed deeper. Always mapped back to what exists in the running prototype, because the prototype is the reference, not the document.
A flow is a statement. A consultant imports a CSV. Contacts appear in their Board. Tower evaluates one contact against one rule and surfaces a result. That is a flow. Simple, complete, testable.
Step three: the register maps software to flows
This is the key move. The register is not documentation written after the fact. It is where real software components get mapped to the flows you just wrote. When you do that, you get test cases for free — because a flow with software mapped to it is a testable assertion. You did not write tests. You wrote flows and then mapped tools to them. The tests emerged.
Step four: build
Now you build. Not from a blank plan. From a register that already knows what should exist and what each piece does. The prototype told you what the product needs to do. The flows transcribed it. The register mapped the software. The build is almost just execution at this point — filling in what the blueprint already specified.
Is this waterfall?
No. Waterfall plans the entire system then builds linearly, accumulating the cost of a changing plan as it goes. What this describes is something different: plan one version completely, build it, then discover the next version from what you learned. The prototype is the agile artifact. Each build cycle is bounded by what the prototype already proved. The prototype is cheap to change. The register adapts as you build. Discoveries during build feed back into the prototype before they feed into the plan.
The reason this works — and the reason it only works with a production-fidelity prototype — is that the blueprint has to be trustworthy before you can build from it. A lo-fi wireframe is an approximation. A production-fidelity prototype is a commitment. You are not guessing at what the product should feel like. You already know. You built it. Now you are just making it real.