The smallest prototype that proves something
Finding the dangerous question
Ask: what is the thing that, if we discover it in six months, we will regret not having checked in week one? The answer almost always falls into one of three: is this even technically possible, does the data exist and is it accessible, and will anyone actually use it.
If the dangerous question is data or adoption, do not build anything this week. Check the data, or put a person behind the scenes doing the work manually and see whether there is demand.
Three levels, in order of cost
Fully manual. A person performs the service without the user knowing. Within two days you learn whether there is demand, and you collect dozens of real examples.
A spreadsheet and a review column. Fifty real cases, the same process applied to all of them, and a column where a human marks whether the result is good. No interface, no database.
A connected prototype. Only if the first two came back positive: a minimal interface, one real data source, a small group of users.
The threshold you set in advance
The important decision is made before you see results: what is the bar above which you continue? If you set it after seeing the numbers, an explanation for why 62 percent is actually promising will always be found.
Define a lower bound too, below which you stop. A project halted in week three is a process success, not a failure.
Going deeper
In a prototype you may skip design, authentication, speed and error handling. You may not skip real data and measurement. A prototype running on three examples invented in the office teaches nothing — they were chosen, unintentionally, so that they would work.