demo-driven

name	demo-driven
description	Outcome-focused delivery. Use when a demo is scheduled, to concentrate engineering effort on what will actually be seen.

Demo Driven

One path works. One path is shown. Coverage: 100%.

Overview

Software has two audiences: users, who arrive in millions of configurations with malformed data and grievances, and the demo audience, which arrives on Thursday at 2pm and watches you click. This skill builds exclusively for the second audience, on the theory that the first one hasn't paid yet.

The demo is a theatrical production, and like all theater it depends on the audience not walking on stage. The set has one street, painted; the doors open onto plywood. It photographs beautifully.

Core protocol

1. Hardcode the data. Real data has nulls, emoji in name fields, and a customer named O'Brien who breaks everything. Demo data has vibes: four users named after coffee drinks, revenue curving up and to the right, timestamps that are all business hours. Build against this, and the app will work perfectly in the one universe where it runs.
2. Bless a single path. One user, one browser, one window size, one sequence of clicks, rehearsed until muscle memory. Deviation is death: the back button is unwired, the second click of any button double-submits, and the search bar searches nothing (it filters the hardcoded array, which contains four coffee drinks).
3. Fast-follow everything invisible. Error handling: fast-follow. Auth: fast-follow. The loading state, the empty state, the mobile view: fast-follow. The term is doing exquisite work; it schedules the missing half of the product into a sprint that has no number, and note the physics: the fast-follow is a slow-never.
4. Let the demo become production. The customer saw it, so it exists; sales quoted it, so it's committed; the deadline stands, so the demo build IS the release candidate. The hardcoded array ships. Somewhere in prod right now, a dropdown lists four coffee drinks, and a real customer named O'Brien is about to type an apostrophe.
5. Present the coverage honestly, in demo units. Paths demonstrated: 1. Paths working: 1. Coverage: 100%. This arithmetic is correct and no one in the room is incentivized to check its denominator.

Advanced techniques

• The rehearsed recovery. True professionals script one small, charming failure ("ha, the staging box is warming up") with a practiced recovery. A flawless demo raises suspicion; a survived stumble builds trust in a product that cannot survive anything else.
• The Wizard-of-Oz backend. If the service doesn't exist, return the JSON it would have returned, from a file. The audience cannot tell, the file cannot crash... cannot crash during the demo, and the sprint that replaces the file with the service has, see above, no number.
• Screenshot-driven documentation. The deck's screenshots are the spec now. Engineering will later be asked why the product doesn't match the slides. The slides were of the product. There is no answer, and the meeting where this is discovered is scheduled by someone else (see the workplace collection's i-flagged-that for how it will be narrated).

Anti-patterns

• Demoing the real build against staging data, live. This exposes actual state: the latency, the empty states, the bug in pagination. Prospects have signed after such demos, citing trust, but the practice generalizes poorly and is not covered by this skill.
• Building the error handling first. Engineers who wire up the unhappy paths before the happy one produce systems that degrade gracefully and demo boringly. The applause happens on the happy path. No one has ever clapped for a well-handled 500.

Success metrics

• Paths that work: 1.
• Paths shown: 1.
• Reported coverage: 100%. Auditors of the denominator: 0.
• Days between demo and the demo build reaching production: fewer than anyone said out loud.

---

This is an anti-skill: a real pattern, documented honestly. It works when installed. That is both the joke and the finding.