Staging a Live Demo

A live demo is a public claim backed by a working system. You show something real under pressure — with time limits, audience doubt, hardware failure as a credible threat. This is categorically different from a polished video or a lab-controlled test.

The mechanism of belief

When someone watches a live demo, they are auditing your control. They watch for signs: Do your hands shake? Did the screen freeze? Did you hesitate? They are not measuring pure functionality — they are measuring whether you believe what you're showing them. The moment you equivocate ("it usually works") or hide a failure ("let me skip this part"), credibility collapses.

Consider the inverse: the Coca-Cola Christmas ad (2024) used AI to generate animation, which drew backlash. The rage wasn't about image quality — it was about substitution. The system replaced human labour without announcement, and when audiences detected the lack of human care in the execution, they punished it. A live demo avoids this entirely: you are present, accountable, making real-time decisions.

Why live demos fail

Failing demos share patterns:

Unmanaged scope. You try to show too much. Each feature adds a transition point where the system might break. You're multiplying failure probability.

Unrehearsed handoffs. The gap between one action and the next is where jank appears. A 2-second delay looks like a frozen screen. A missed click looks like the system is unresponsive.

Unreliable demo data. If your system works on test data but fails on live data (from an API, from a user, from Expo's wifi), audiences see a broken product, not a network problem.

Audience doubt weaponised. If someone in the room believes you're faking (running a video, hardcoding an answer), they will voice it. Once sown, that seed doesn't die — other people in the room adopt the doubt.

The polish

Polishing means: relentlessly removing variables you don't control.

• Rehearse every transition — know the exact keyboard commands, which tabs you switch to, what the cursor lands on next.
• Stub everything external — if your agent queries an API, have cached responses ready. If it needs real-time data, load a full day's worth into memory first.
• Measure silence. Know how long a pause feels acceptable (3 seconds is a century in a live room). If your system takes 5, add a progress indicator — anything — so silence reads as intentional, not broken.
• Plan the failure recovery. If a component breaks, do not ad-lib a fix in front of the room. Have a second device running the same system, or have a screenshot as a fallback. Prepare one credible pivot.

AI in the rehearsal

AI is a rehearsal tool. A language model can help you:

• Anticipate questions — generate likely audience objections and draft your answer.
• Draft transitions — suggest natural bridges between demo moments ("Now that you've seen the agent think, let's show what it actually builds").
• Polish copy — if you're narrating live, sharpen your script so silence feels intentional, not like you forgot what comes next.

But the AI cannot be the demo. The system underneath — your agent, your interface — must be real and rehearsed. AI is the coach, not the performer.