Demo reliability under pressure

The first principle

A demo is reliable when the audience can see the promised outcome even if the live system degrades. That means reliability is not only uptime. It is route planning.

The team needs a primary demo path, a fallback path, and a final proof artifact. If the network, API, database, or browser state fails, the story should still land.

The three paths

Primary path

This is the live flow you want to show. It should have the fewest possible moving parts and the clearest visual payoff.

Fallback path

This is the same claim shown through a seeded account, fixture, local mode, screenshot, or recording. It should not feel like a different product.

Final proof

This is the artifact that proves the team actually built something: repo, deployment, logs, screenshots, dataset, or generated output.

1. 01Seed demo data before judging starts.
2. 02Use one browser profile for judging and do not browse randomly in it.
3. 03Keep a local recording of the successful demo path.
4. 04Prepare a short sentence for every unavailable external dependency.
5. 05Open all required tabs before the pitch begins.
6. 06Verify text size from the back of the room.
7. 07Have one teammate responsible for recovery, not everyone talking at once.

Failure modes to design against

• Authentication expires.
• Sponsor API rate limits or returns unexpected data.
• The database is empty because someone reset it.
• The demo account has stale state.
• Text is too small on the projector.
• The browser asks for permissions during the pitch.
• The network is slower than your local environment.

Recovery language

Do not apologize for a system dependency for thirty seconds. Name the dependency, switch to fallback evidence, and keep the story moving.

Example: The live API is slow, so I will show the same run from our seeded session. The important thing to watch is the state transition after the user submits the request.