This is a methodology. Not a workflow preference, not a style choice � a repeatable method for building software products that I arrived at by doing it, and that I think describes how the best builders are going to work going forward.
It has four steps. They are sequential. The order matters.
Step one: UI first, from deep UX understanding
Not wireframes. Not a mockup you present once and archive. A high-fidelity prototype built from genuine product taste, deep user experience sessions, and a real understanding of what the product needs to do. This becomes your living blueprint � a running thing you can point at, navigate, and hand to someone who has never heard of the product and have them understand it.
The prototype is not the warmup for the real work. It is the real work at this stage. Everything downstream depends on it being honest and complete.
Step two: flows from the prototype
Because you built the UI first, the flows are already implicit in what exists. You are not inventing them � you are transcribing what the prototype already shows. A consultant imports a CSV, contacts appear in their board. Tower evaluates one contact against one rule, surfaces one result. Those are flows. Statements, not specs. General first, then decomposed into finer detail. Always mapped back to what exists in the running prototype, never floating free of it.
This is not a flow: a long paragraph describing a system. This is a flow: a short declarative sentence describing what happens. The distinction matters because flows need to be testable, and long paragraphs cannot be tested.
Step three: the register maps software to flows
This is the key move. The register is not documentation you write after the build. It is where you map real software components to the flows you just wrote � what tool, what service, what function handles each step in each flow. When you do this, you get test cases for free. A flow with software mapped to it is already a testable assertion. You have not written a single test case explicitly, but you have produced a complete set of them.
The register is also where you see the build clearly for the first time. Not as a list of features, but as a set of assertions about what should happen and what is responsible for making it happen.
Step four: build
Now you build. Not from a blank plan, not from a feature list someone assembled in a meeting. From a register that already knows what should exist and what each piece does. You are not figuring out the product as you go � you are implementing something that has already been figured out, at the level of detail that matters.
Is this waterfall?
No. Waterfall plans the entire thing, then builds linearly, and the plan does not survive contact with the build. What this methodology describes is planning one version completely, building it, and then discovering 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 plan changes because the prototype changes � not because the build ran off the edge of the plan.
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. That is the cycle. Waterfall has no such cycle � it builds until it cannot anymore.
Why this is how builders are going to work
The high-fidelity prototype is now accessible to anyone with strong product taste and access to the right tools. You do not need a team of designers and a six-month discovery phase to produce a living blueprint. You need deep understanding of the user experience and the judgment to translate it into something real. Once you have that, the flows follow, the register follows, the build follows. The methodology is the same whether you are one person or twenty.
The prototype is not a deliverable. It is a method. That is the shift.