The Live Demo: Presenting Under Pressure
Expo Demo
The live product demonstration is simultaneously one of the highest-stakes moments in commercial technology and one of its most reliably theatrical forms. The history of tech demos is a history of carefully managed reality: the product that exists for forty minutes on a keynote stage, and the product that ships twelve months later.
Google Gemini Demo Video Was Edited to Show Capabilities the Live API Doesn't Have — Company Admits
Google's promotional video for Gemini, which showed the model understanding and responding to live camera input in real time, used edited footage where the AI responses were to still images rather than live video, and text prompts rather than voice. Google confirmed this in a blog post framing it as showing "what the model can do" rather than the product as shipped.
"A video showing what a product will one day do is called a concept video. Calling it a demo is a different thing."
Apple's "Personal Intelligence" Demos at WWDC'24: Six Months Later, Half Still Unavailable
A six-month review of features demonstrated at Apple's WWDC 2024 keynote found that approximately half remained unavailable in production builds. Apple's approach — demonstrating features at announcement with "coming later" footnotes — has become normalised in the industry, though analysts note it creates measurable gaps between expectation and experience.
Y Combinator Tells Founders: "Demo Day Is Theater" — Authenticity Study Shows Investors Prefer Rough Demos
A Y Combinator internal study of 240 Demo Day presentations found that polished demos with rehearsed flows received lower follow-up interest rates than rough, technically interrupted demonstrations where founders adapted in real time. The finding has circulated as internal guidance: investors assess founder capability through problem-solving, not performance.
"The failure is the demo."
TED Introduces "Demo Verification Protocol" — Speakers Must Submit Working Code or Functional Prototype Before Stage
Following several high-profile TED talks featuring technology claims later found to be unsubstantiated — including one AI health diagnostic that turned out to be a manually-operated spreadsheet — TED announced mandatory verification for any technology demonstration in talks, requiring a working artefact pre-submitted to the TED technical team.
Is a product demonstration that shows capabilities slightly beyond what the current product can do a form of fraud, or is it a legitimate form of vision communication that the audience understands as aspirational?
Live Demo Staging
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.
FINAL PRESENTATIONS
The Demo Gods Are Cruel. Learn to Perform Anyway.
Your code works. Your idea is solid. Then you stand in front of the room and something breaks.
Learn how to structure a live demo so it survives failure, tells the story you intend, and leaves the audience believing in your work — not because nothing went wrong, but because you knew what to do when it did.
**Moment A: Doubt.** Preventative action: rehearse a live proof. Do not explain or defend. Instead, modify the interface in real time (change the prompt, re-run it) to show causality. The second run proves the first wasn't hardcoded.
**Moment B: Handoff.** Preventative action: load the dashboard data into cache before the demo starts. Eliminate the load time entirely, or add a visible progress indicator (spinning logo, "Fetching results...") so the silence reads as intentional.
**Moment C: Data.** Preventative action: do not rely on live API keys or live network data. Before the Expo, capture representative API responses and stub them into the demo environment. Let the system query local cache, not the network.
**Moment D: Scope.** Preventative action: reduce the demo to one core skill ("Watch the agent break down a question"). Do not show breadth. If asked about other features, respond: "This demo focuses on [one thing]. The system can do more, but this is the proof point."{
"structure": "A complete script has: (1) a single, clear problem statement (e.g., When X, Y fails...); (2) a one-sentence description of the setup state (data loaded, app open, etc.); (3) a narration of the action that matches what the feature does—no jumping ahead, no if you click here...; (4) a 1-2 sentence callout that ties the problem to the solution (e.g., So instead of X taking Y minutes, we are now doing it in Z seconds). Timing: script should take 55-65 seconds when spoken at normal pace. If under 50 seconds, move too fast; if over 70, cut a step or tighten a phrase. Word/phrase revision is a real finding—it is the sign you are actually rehearsing, not just reading."
}Demo Script Polish
Write a 90-second demo script for your agent. Include: one input question, the agent's internal step (showing the audience your reasoning), one output. Use AI to identify jank in your transitions (places where silence would feel broken) and tighten the language. Paste both the original script and the AI-polished version.
Task Ai Polish Script
Take your 60-second demo script and your recorded voice memo. Upload both to your AI tool (Claude, ChatGPT, or your choice). Ask it to:
Rewrite the problem statement to be more urgent or concrete. Compare the original and rewritten versions—which one makes you want to watch the demo?
Tighten the script so it's naturally 60 seconds (not rushed, not padded). Strip any filler phrases or secondary details.
Flag places where the audience needs visual clarity—moments when you should slow down, pause, or point at something on screen.
Export the polished script. Speak it aloud again. Record a second take.
Submit:
- The original script
- The AI-polished script (with notes on which changes you kept)
- A 2–3 sentence reflection: Did the AI rewrite hit harder? What did you change your mind about after hearing the second take? What's the hardest part of sounding natural while staying on time?