W3D14Sb
How do you stage a working build and recover when it breaks live, so strangers see a moment that works?
The Demo
βΆ Enter ProjectContext
You're at the Seoul Expo booth presenting JARVIS, your AI-fluency platform. Real strangers walk the floor every 90 seconds. Investors stop for one moment only β the instant they see something work they can't build themselves.
Mission
Ship a rehearsed, live 90-second demo where one moment makes strangers stop walking, and a fallback plan survives failure on stage.
Finish Line
Recorded demo (3 takes showing the moment, the fallback, and recovery), plus team reflection (what broke, how it was fixed, what recovery taught about the product claim).
Team Roles
Founder / Presenter
Own the 90 seconds. Your job is to kill everything that is not the moment.
- Pick the single moment (feature, gesture, outcome) that makes a stranger stop walking β cut all feature tours and breadth.
- Script a beat-sheet: line-by-line narration, exact click sequence, expected UI response for each line. Run it three times with a stopwatch. The demo runs 90Β±5 seconds at normal pace. Record all three timings on the run-sheet. If any run misses the window, cut or reorder beats until all three timings hit the target.
- Perform the demo cold for another team and rewrite the beat-sheet from their feedback: what they tried to click (expected interaction), what confused them (vague narration or invisible UI state), where timing broke. Rewrite affected lines with corrected click/narration and re-time to confirm the fix.
Tech Lead / Booth Operator
Keep it live. Your job is the fallback and the recovery.
- Build and run the live demo environment from scratch 15 minutes before the show β document every step so the recovery is repeatable (OS/browser/tab/network state, asset load order, data preload, login state if any).
- Identify the three most likely failure points (network stall, build state, browser state) and script a <30-second recovery for one of them. Choose the failure most likely to happen in the first 10 seconds of the demo. Write the exact pivot line the Founder will say when you signal failure, and write the fallback format (live reload + same moment on video, mockup screenshot series, or manual walkthrough with narration β pick one). Perform this recovery cold once in front of another team, starting from the Founder's signal, without rehearsal.
- When failure is triggered during the cold run, execute the <30-second recovery and transition to fallback without script prompting. Time the execution and record the outcome on the run-sheet.
Technical Validator / Investor Role
Demand the real. Your job is to interrupt, break, and judge whether the recovery holds.
- During the cold run and live demo, interrupt and touch the demo as a real stranger would β click an unexpected button on the screen, scroll the page, resize the browser window, or ask for concrete proof (show me the source code / run this again / how fast is that?). Record which action triggers a failure, if any.
- When failure occurs, observe and time the Tech Lead's recovery execution (<30 seconds from signal to fallback active). Judge whether the recovery executes as scripted or requires improvisation/apology.
- After the run, score on the rubric. For 'Recovery rehearsed' distinction: after the failure and recovery conclude, ask the Founder to state in one sentence what the product does (the core claim). If they articulate it without reading the script, the moment landed. If they read or stall, the recovery broke the pitch.
Exemplars
- Devin β the first AI software engineer
Cognition AI
Landmark deployed autonomous agent (shell + editor + browser, long-horizon planning) demoed end-to-end β the bar a JARVIS capstone showcase aims at.