The traditional order is: gather requirements, write a specification, get it signed, build it, deliver it. It is orderly, it is defensible, and for interface work it fails with remarkable consistency.
It fails because a specification is prose, and prose about an interface is ambiguous in ways nobody notices until it is too late.
The sentence problem
Take a requirement as ordinary as this: "Users can filter the list of orders."
Everyone who reads that agrees with it. Everyone who reads it pictures something different. Is the filter a sidebar, a row of dropdowns, or a search box that understands what you type? Do filters combine? Do they persist when you come back tomorrow? Are they in the URL so you can send one to a colleague? Does it filter live or on submit? What does zero results look like?
Every one of those has a right answer for your business and none of them is in the sentence. The client signs off imagining one thing, the developer builds another, and both are technically correct. The disagreement surfaces at delivery, which is the most expensive possible moment to find it.
You could write the sentence more precisely. Specifications that try to eliminate this ambiguity become enormous, and nobody reads an enormous document carefully enough for it to work. You end up with a document that provides legal cover instead of shared understanding.
What we do instead
We build the real thing, early and rough. Within the first week or two of a project you have a link. You open it, you click through it, and the main flow works. It is unfinished in obvious ways and it is not pretending otherwise.
It is not a design mockup and it is not a clickable Figma file. Those look convincing and still leave the important questions unanswered, because they cannot show you what happens when the data is real, or slow, or missing. It is the actual application, running in a browser, with the core path working.
Then we ask you to try to break it, and to tell us everything that is wrong.
Why this is cheaper, not more expensive
The intuition is that building before deciding wastes work. In practice the opposite holds, for one reason: the cost of a change rises steeply with how much has been built on top of the thing being changed.
Changing a flow in week two touches a handful of files. Changing the same flow in week nine touches the flow, the six screens built assuming it, the data model shaped around it, and the tests. The change costs perhaps ten times more, and by then there is pressure to work around it rather than fix it, which is how products accumulate the awkwardness that makes them feel wrong to use.
The prototype front-loads disagreement to the cheapest week in the project.
What it surfaces that a document never does
Three things reliably appear the moment a client uses a working version, and essentially never appear in a requirements review.
- Steps that are technically correct and feel wrong. Nobody can predict this from a description. Everybody notices it within ten seconds of using the thing.
- Missing states. Empty lists, first-run experience, long names, failed uploads, someone with forty items instead of three. Specifications describe the happy path almost exclusively.
- Features that turn out not to matter. Something argued over for a week in planning goes untouched when the working version is in front of you, which is a large saving discovered for free.
What this asks of you
This approach only works if you engage with the prototype properly. That means using it as though it were real, with your real data and your real scenarios, and being blunt about what is wrong.
The failure mode is politeness. A client who says "looks great" to a rough prototype has not given us anything, and we will keep asking until we get something usable. The most valuable feedback we ever receive sounds like criticism.
It also asks you to accept that early versions look unfinished. If seeing rough edges is going to worry you rather than inform you, the approach will be uncomfortable. It is worth knowing that about yourself before starting.
Where specifications still belong
This is not an argument against writing things down. We write down scope, price, and timeline, and we are precise about them. Business rules get written down properly too: VAT calculations, eligibility criteria, and permission models are exactly where prose is better than a picture, because they are logic rather than interface.
The argument is narrower than it sounds. For anything a person looks at and interacts with, a working version communicates in an afternoon what a document fails to communicate in a month.