A prototype for a pitch: what to show, what to skip
Pitches always arrive at the worst possible moment, with too little time and far too much to show. The temptation is to demonstrate everything: every module, every screen, every clever idea the team has had. It almost never works. A client deciding whether to trust you doesn’t need to see everything. They need to believe it.
Breadth looks impressive, depth convinces
A prototype that touches twenty screens but completes none of them leaves an uneasy impression. Clicks lead nowhere, data is obviously fake and the presenter keeps saying that this part will work later. By contrast, a single flow that works from start to finish feels real. The client can follow it, imagine their own users in it and sense that the rest will be built with the same care.
What to show
I choose the flow that carries the heart of the proposal: the moment where the product solves the client’s main problem. I make it realistic, with plausible data, the client’s colours and their language. I add just enough context around it, a home screen and a glimpse of navigation, so it feels like part of a whole. And I rehearse it, because a smooth demo of one flow beats a nervous tour of many.
What to skip
I skip settings, edge cases, administration and anything the client won’t ask about in the first meeting. I skip features that are interesting to us but secondary to them. I also skip polish in places nobody will look. Those decisions free the time to make the main flow genuinely convincing, which is the only thing a pitch prototype has to do.
A prototype is an argument
A good pitch prototype is not a smaller version of the product. It is an argument, made in clicks rather than slides, for why this team understands this problem. With a well-built design system and today’s tools, making that argument has never been quicker. Choosing what to leave out is still the part that wins the work.
Is your design system starting to fade?
I’d like to hear about it →