Write the question before the specification
A prototype can test whether a task is technically possible, whether a person understands an interaction or whether the result is useful enough to return for. Those are different questions. A single polished demonstration can obscure the distinction and leave a team with enthusiastic reactions but little direction.
Write one sentence before building: ‘We need to learn whether this person will use this result to do this job.’ Then decide what observation would count as a meaningful answer. If the team cannot agree on that sentence, more implementation is unlikely to create clarity.
Build around the uncertain part
If the question is whether a recommendation is useful, a manually assembled recommendation may be enough for an initial test. If the question is whether a model can produce a reliable answer under real constraints, manual work hides the very uncertainty you need to examine. The shortcut must preserve the thing being tested.
This is why a prototype should have deliberate boundaries. Leave out the account settings if they do not affect the experiment. Keep the difficult source material if it does. Record which parts are simulated so that the team does not mistake a successful test of demand for proof of a scalable product.
Observe use, not just reactions
A guided demo gives the founder too much control. Where possible, let someone attempt the task with limited instruction. Watch where they hesitate, what they try to verify and whether they can explain the result in their own words. An awkward moment can contain more information than a positive rating.
Ask what the person would do next with the output. Would it enter an actual workflow, replace a step or remain an interesting artifact? A prototype becomes more informative when its result meets the messiness of real work.
Decide what the result changes
Before the test, agree on what would cause you to continue, narrow the idea or stop. The thresholds need not be statistically definitive. They do need to prevent every possible outcome from becoming a reason to build more.
Afterward, separate observations from interpretations. ‘Three people needed help finding the source’ is an observation. ‘People do not trust AI’ is a much larger claim. The first can guide a concrete change. The second may send the team toward an expensive solution to a poorly understood problem.
A prototype earns its cost when it changes a decision, even when the decision is to build less.