Live software demos have a special way of finding the one thing you did not rehearse.
I recently put together a complicated sprint demo involving manual and automated behavior, smaller UI fixes, and an endpoint used to seed data. It went well! It also included an unavailable log source, unexpected staging data gaps, and a bug I found while presenting!
The point of preparation is not to make every surprise impossible. It is to understand your story and your system well enough that you can make the next useful move when something changes.
Build a Story from the Sprint
I started by organizing my brain! (My favorite tool for mind mapping is Miro.) I gathered the tickets that the team completed during the sprint and pasted them in as sticky notes. I color-coded the big feature work, smaller bug fixes, and items that were still being QA’d. Then, I grouped them by area of the application.
Once I could see the work grouped together, I could build the demo around a user journey. The journey moved from using an endpoint to seed data, to seeing that data in the UI, to completing the relevant workflow.
That gave the audience a through-line. It also gave me an anchor.
Plan a Flexible Route
One feature I needed to show included an automated process that runs on a schedule. In production, it checks once a day whether a record is old enough to take action on. For development and staging, we shortened that loop substantially so we could observe the behavior during a demo.
I started by showing the manual version of that workflow, then kicked off the automated version and told the audience we would come back to it. If the automated process had enough time to run while I showed smaller bug fixes and UI improvements, I could return to the completed result. If it had not, I could continue with the larger user journey and come back later.
I also gave myself a few different ways to show the work. Some of the smaller UI fixes were difficult to demonstrate live because the “before” state was already gone in staging. They were subtle enough that the audience might not remember exactly how the old behavior felt, either.
For those, I recorded the old behavior ahead of time, then showed the fixed version live. That let me make the improvement visible without trying to recreate an inconvenient state on demand. Between the live workflow, the recorded before-and-after clips, and the rest of the user journey, I had more than one way to keep the demo moving.
Write a Run-of-Show That You Can Actually Use
After I had the order of operations, I wrote down lightweight run-of-show notes on a small notepad. Each entry had the ticket or feature, what I wanted to do, and anything important to point out.
I like writing these notes by hand because it helps me remember what I planned. The small page also requires me to be brief, and the disposability of a sheet from a notepad makes it easy to cross things out or start over. It never feels precious enough to avoid rewriting.
This is a matter of preference and what works best for your brain, but I keep my notes very minimal. During a demo, I cannot process long lines of text quickly. I need to be able to glance down and remember my intention: where to start, which test data I specifically set up for that feature, a star for something I want to highlight, or an important step I skipped when I practiced.
For me, overly detailed notes can become a second interface to parse while I’m also trying to manage the demo. Other people may prefer a more detailed script, but the goal is the same: your run-of-show should reduce cognitive load and help you get back on track after a question, a pause, or an unexpected issue.
One other small way I put myself at ease is by making the test data a little fun. I have used Keanu Reeves to demonstrate dual citizenship, built an address in Lizzietown, and filled an organizational-chart PDF with Wallace and Gromit characters. The goal is not to turn the demo into a bit. It is to create a little warmth—for yourself and, sometimes, for the audience.
A Snag Is Not the Same as a Failed Demo
Right before this demo, I was testing the endpoint that seeds some data into our system. I got one success, and then a string of failures with cryptic errors. I thought something might be broken. Unfortunately, the staging logs were not available at the time, so I could not use my usual path to investigate. Nor did I have time, frankly!
While our delivery lead opened the demo with sprint updates, I kept testing safely in the background. I eventually realized that the endpoint has an intentional uniqueness constraint: once a specific supplemental ID has been used to seed the data, it cannot be used again. I had been hitting the endpoint with the same data multiple times.
The endpoint was working; I had just forgotten an important requirement!
I had been prepared to skip that portion of the demo if I could not resolve it. Instead, I had enough time and enough of a hypothesis to try a few safe options. Once I understood what was happening, I could show the endpoint as planned.
The important word there is safe. A demo is not the time to push code or make risky changes in an environment just to save face. It’s also not the time to throw yourself off by digging around in a panic. It worked because I was ready for either outcome and felt confident enough about the rest of my demo that I wasn’t adding more stress to my plate; I was simply curious whether I could close the gap.
Later in the demo, I did find a real bug. I tried a configuration I had forgotten to run through beforehand, and I could not continue through the workflow. I said, “Nice, we found a bug. Can someone take a note of that? Let’s try that again, and I’ll steer clear of that path so we can see the rest of the workflow.”
That was enough. We had useful new information, the issue was recorded, and the demo could continue.
Bring a Wing-Person
For complicated demos, designate a demo wing person. In my case, staging had recently been refreshed, which meant some expected data still needed to be migrated or seeded. A teammate involved with the deployment was available to help approve data while I continued through the presentation.
Next time, I would make that role more explicit. A wing person can know the run-of-show, keep their laptop open, and be ready to prepare data or investigate a small issue while the presenter keeps the narrative moving. They can also be an intentional part of the demo: for a messaging system, for example, they can play the person on the other side of the conversation.
You do not need to hope someone catches you. You can plan for collaboration.
Trust Yourself Enough to Recover
The best way to get comfortable with demos is, unfortunately, to do demos. Preparation helps, but you will never rehearse every possibility.
The goal is not to become perfectly unflappable. It is to build enough experience, preparation, and self-compassion that you can pause, take a breath, and make the next useful move.