Three days. A live prototype demo in front of a jury. Here is how I got the thing working.

Why a Demo Fails

A live demo fails for two reasons. The first is that the product does not do what you say it does. The second is that the product does what you say it does, but nobody watching can follow what is happening on screen. Both are fatal. Both are avoidable. Neither is hard to fix if you look at the demo honestly before you present it.

I had been building this prototype for a while, and I had stopped seeing it the way a first-time user would see it. I knew every click, every edge case, every place where I had cut a corner. That is exactly why I could not trust my own judgment about whether it was ready.

The Honest Self-Review

After being shortlisted on 12 October, I sat down and reviewed the prototype for functional and presentation weaknesses. I made two lists. Functional: things that broke, things that were missing, things that did not work the way they were supposed to. Presentation: things that would confuse someone who had never seen the product before.

I found problems in both lists. Some were small. Some were not. I did not argue with any of them. The point of the review was to find the problems, not to defend against them.

Fixing the Core Before the Polish

On 13 October I worked on the core functionality first. If the thing did not actually work, making it look nice was a waste of time. I fixed the pieces that were unstable, made sure the main path through the product was repeatable, and tested it over and over until it did not break.

Then I worked on the demo flow. The path from the opening screen to the key result had to be short, predictable, and free of dead ends. Every click had to lead somewhere the user expected. Every screen had to explain itself without me narrating. I ran through the flow as if I had never seen the product before, and I wrote down every place where I hesitated or had to think about what to click next. Those were the places that needed fixing.

Making the Flow Stable

The hardest part was not the functionality. It was making the flow stable under pressure. A demo that works when you are relaxed does not necessarily work when you are being watched. The product has to start reliably. It has to recover from any input the user might give it. It has to not crash on the third click, because the third click is always the one the jury tries.

I ran the demo multiple times in a row. I introduced random inputs. I broke it on purpose and watched how it handled the failure. By the fifteenth I was confident that the main path would not break, and I had a backup plan for anything that might.

On the Fifteenth: The Live Demo

On 15 October I gave the live prototype demonstration to the jury.