The point of a prototype is disagreement
A prototype is not a preview and not a sales asset. It exists so the people who do the work can look at a screen and say "no, the approval goes to finance first", which is the sentence that saves a project. If nobody disagrees with your prototype, it is probably too vague to disagree with.
That single purpose decides everything else about what it should contain. Anything that helps someone react belongs in it. Anything that only makes it look finished does not.
What belongs in it
Five things make a prototype argue-able, and all five can exist within a few hours of a conversation.
- Real screens, in your terminology. Not "Entity A" and "Status 1", but the words your people use, because half the disagreements are about vocabulary.
- One workflow, followed all the way through. A prototype that stops at the interesting screen leaves the hard part untested.
- Enough working logic to test the idea. Clicking through should change something, otherwise you are reviewing a picture.
- Sample data that looks like yours, including the awkward cases. Clean demo data hides exactly the problems worth finding.
- The decision point. Where a person has to approve, reject or intervene, and what they see when they do.
What does not belong in it
Connections to your live systems. Read-only exports or invented sample data are enough to prove the shape, and integration work spent before the idea is confirmed is work spent on a guess.
Every edge case. A prototype that handles all of them has become the production application without the testing that the production application deserves.
Polish for its own sake. Visual finish makes people review the surface. A slightly rough prototype gets better feedback, because nobody assumes it is finished.
A price. If a prototype is quoted for, it has become a deliverable to be defended rather than a question to be answered.
How long it should take
Hours, not weeks. We work to two to three hours from the end of the first conversation, which sounds aggressive until you notice what it forces: the scope has to be one workflow, the questions asked in that conversation have to be the right ones, and nobody has time to gold-plate.
The deadline is the discipline. A prototype that takes three weeks has already consumed enough time and attention to make people defend it rather than judge it.
How to judge one
Put it in front of the person who does the work, not the person who sponsors the project, and watch rather than present. Three questions tell you most of what you need:
- Did they try to do something the prototype does not support? That is the requirement nobody wrote down.
- Did they correct a word on a screen? Vocabulary mismatches usually mean a process mismatch underneath.
- Could they say what would make it useful on Monday? If not, the workflow chosen was the wrong one, and that is worth knowing before a build.
When the answer is that the idea was wrong
This is the outcome people forget to plan for, and it is the cheapest useful result software can produce. An afternoon spent establishing that the real problem is somewhere else beats a year spent building the wrong application competently.
The test of a supplier is what happens next. If the prototype disproves the idea and the response is a proposal for a bigger prototype, you have learned something about the supplier too.