You have ten minutes to show what you built. The job of those ten minutes is to make a room believe the thing works. That is the whole job. It is not to explain how hard it was, and it is not to display the full range of what is possible.
Most demos lose on the first point. People narrate the journey. We started with one approach, then the library turned out not to support it, so we rewrote the layer underneath, and then there was a whole thing with the certificates. Every word of that is true and genuinely interesting to you, and the room is sitting there waiting to see the screen do something.
So open with the outcome. Here is a customer placing an order, and here is the confirmation arriving. Then, if there is room, put the hard part in one sentence. The certificates cost us two days and are sorted now.
A few things will save you.
Rehearse one path out loud, once, with the actual clicks. Rehearsing it in your head hides exactly the places where you will fumble.
Have the data already in place. Nobody wants to watch you type a name into a form, and typing is where things break.
Record a two minute run of the happy path the day before and leave it open in another tab. If the network dies, you play the recording and the meeting carries on. This is the highest value item on the list and almost nobody bothers.
Do not debug live. If something breaks, say, that is not doing what it did this morning, I will look into it and come back to you, then move on. A room forgives a glitch instantly and remembers four minutes of squinting at logs for a long time.
Name what is not built before anyone finds it. The export is stubbed, and the email goes to a test inbox. Saying it yourself costs you nothing. Being caught by it costs you the rest of the demo.
Then stop early. Finishing with three minutes spare and a room full of questions is a far better outcome than filling every second you were given.
You are not being judged on how much you showed. You are being judged on whether they believed it.
– Asael Shinder
