Case Study 1 — Raj's Demo Crashes (And the Backup Saves It)

A worked scenario. Raj Patel is the backend engineer who rebuilt a neglected open-source project's README and docs (Chapter 25). Here he takes that project to a developer conference — and the demo gods turn on him. This is a composite, fictional-but-realistic account.

The setup

Raj has thirty minutes at a mid-sized developer conference. His talk is good: a clean assertion–evidence deck (Chapter 30), a real story (a project that went from four GitHub stars to six thousand once the docs got fixed), and a hook he rehearsed until it was automatic — "Eighteen months ago this project had no install instructions and one contributor: me, at midnight, wondering why no one used a tool I knew was good." He has rehearsed out loud three times and lands at twenty-six minutes for a thirty-minute slot — about 87%, with a little buffer.

The centerpiece is a live demo: he'll run the tool against a sample service, show the one-command setup that used to take an undocumented hour, and let the audience watch it work. Nothing is more convincing than the real thing running live. Nothing fails more memorably when it doesn't.

Raj did the boring, decisive thing the week before. He recorded a screen capture of the entire demo working perfectly — clean terminal, big font, the whole flow start to finish. He told himself he probably wouldn't need it. He also wrote one sentence on an index card: "If the demo dies: 'Looks like the conference network isn't cooperating — good thing I recorded it,' then play the video." And he arrived forty minutes early to test the projector, found it mangled his terminal colors, and bumped the font size and switched to a high-contrast theme. (He could not test the conference Wi-Fi against his demo's external dependency, because the network wasn't live until the session started — a gap he noted but couldn't close.)

The failure

Eleven minutes in, the talk is going well. The room is with him. He reaches the demo, types the setup command, and narrates: "So now I just run this one command, and the service spins up and—"

The terminal hangs. A cursor blinks. Five seconds pass — an eternity on stage. Then a red stack trace scrolls up: a connection timeout. The tool is trying to reach a package registry the demo depends on, and the conference network is silently blocking the outbound request. The room goes quiet in that specific way a room goes quiet when a demo dies. Raj feels his heart rate spike and the hot prickle of two hundred people watching him fail in real time.

This is the ten seconds the whole chapter is about. It is not about whether the demo failed — that was always possible, and the cause (a hostile venue network) had nothing to do with Raj's code or competence. It is about what he does next, and that was decided the week before, not now.

The recovery

Raj does not re-type the command. He does not apologize three times. He does not mutter "this worked this morning" and fiddle for ninety seconds while the room's goodwill drains away. He glances at his index card, exhales once (the long, low exhale from his pre-talk routine), and says — evenly, almost cheerfully:

"Well, the demo gods are not with us today. The tool's trying to reach a package registry and the conference network is blocking it — which, honestly, is a great illustration of why you don't depend on the venue Wi-Fi. Good thing I recorded this."

A small ripple of laughter. He switches to the screen recording and narrates over it exactly as if it were live — same words, same emphasis, pointing out the one-command setup, the output, the result. The audience watches the thing work. They hear his explanation. Total time lost: about eight seconds. The talk continues, and Raj lands his conclusion — "The code was always good; what changed was that we wrote down how to use it. Writing was the feature." — with thirty seconds to spare.

In the hallway afterward, three people tell him the recovery was their favorite part. One says, "I always panic about demos — watching you just roll with it was the most useful thing I saw all day." The failure became a footnote, and the composure became a credential.

What made the difference

Notice that almost none of the save happened on stage. It happened in preparation:

And one honest limitation: Raj couldn't fully eliminate the risk, because the network wasn't testable until showtime. That's exactly when a backup earns its keep — the precaution covers the risk you can't close. Had he run the demo against a purely local environment with the registry pre-cached (the stronger version of "don't depend on the venue network," 31.7), the live demo itself might have survived. The recording was his second line; the local environment would have been a better first line. Both are cheap insurance against an expensive, public failure.

The lesson in one sentence: A live demo is a controlled risk only if you prepare for it to fail — and the thirty minutes spent recording a backup is the highest-leverage preparation in technical speaking.

Questions for reflection

1. Raj's recovery line did three things at once. Name them. (Hint: tone, content, and a teaching point.)
2. The chapter says "always have a backup." Raj had a recording but not a local-cached environment. Rank the precautions he could have taken, and explain why the recording was the non-negotiable even though a local environment would have been a better first line of defense.
3. Why did the audience warm to the demo failure rather than judge Raj for it? What would have happened to that goodwill if he'd had no backup and melted down (see Case Study 2)?
4. Raj couldn't test the venue network in advance. List two other talk risks that are similarly "untestable until showtime," and for each, name the backup that would cover it (the way the recording covered the demo).

Back to: Chapter 31 · Case Study 2 · Exercises · Key Takeaways