A prototype should prove a decision
A prototype is not a smaller final product. It is a focused instrument for making one expensive uncertainty cheaper.
Prototypes become expensive when they are asked to look complete before they have answered anything important.
The useful question is not “How much of the product can we fit into a week?” It is “Which decision would become easier if this interaction existed in front of us?”
Name the uncertainty
A focused prototype might test whether:
- a founder understands the operating model without onboarding;
- a field worker can complete the flow with one hand;
- a client trusts the generated output enough to approve it;
- the data model can represent the real exception, not just the happy path;
- the central interaction is faster than the current workaround.
Each question implies a different prototype. Only one of them may need polished visuals. Another may be a command-line flow with excellent logs. Another may be a static interface connected to fixtures.
Define evidence before building
The prototype should begin with an evidence contract:
- Who will use it?
- What will they attempt?
- What observation changes the decision?
- What is explicitly fake or omitted?
This prevents the prototype from quietly turning into an under-tested production system.
Throw away the right parts
The interface can be disposable while the learning remains durable. Preserve the tested language, the domain rules, the edge cases, and the evidence. Rebuild the parts that only existed to create the experiment quickly.
That is not wasted work. It is the prototype completing its job.