It's happened to the best of us: you're on a video call with the client, showcasing your latest work in progress, when suddenly an unexpected bug appears mid-demo. "What!? This didn't happen before!" you think to yourself as panic sets in. You make a few nervous jokes and promise everything will be resolved in the final release. The curse of the live demo is a well-known and frustrating phenomenon—almost a rite of passage for engineers. In fact, it recently caught out Google as they demonstrated their latest AI product. In the best-case scenario, you have a trusting audience who understands the perils of a live demo. In the worst case, you risk losing their trust or even their business.

In this article, I'll shed light on ways to make your live demos as bulletproof as possible. Not all solutions will work in every situation, but hopefully, this will give you food for thought on how to improve your current process.

Common solutions

Below you'll find some common ways engineers try to improve the reliability of their live demos and the potential trade-offs with each.

Pre-demo run through

Before a live demo, set aside time to ensure your code base is up to date, you have no working changes, and all dependencies and third-party services (like APIs) are available. Give the exact flow you'll be demoing a run-through yourself. Think of this as the technical equivalent of rehearsing a speech in front of a mirror. It offers a chance to spot issues while you still have time to resolve them and helps you practice for a smooth presentation.

While this is an effective way to guard against live demo issues, it can be time-consuming and disruptive to your workflow. The more changes you make to the code base after your pre-demo run-through, the higher the risk of introducing new issues. This means you need to schedule the run-through close to the actual demo time, which reduces preparation time.

Skip the live demo entirely

Some companies prefer a hands-off approach to live demos by not doing them at all. Instead, they show a presentation with screenshots of the feature or share designs with the client. In these scenarios, the client's first hands-on look often comes when they're QAing the feature near the end of the task life cycle.

While this approach may work for some companies and clients, in my experience, most clients want to see the most real-world scenario as early as possible. Screenshots or design files don't instill the same confidence as seeing a functional feature, even if it's still a work in progress. Another downside is the potential for diverging expectations between the client and team. Ideally, the client should see the highest fidelity possible to ensure the work meets their needs, and if it doesn't, the team should find out sooner rather than later.

Let the client have free rein

An alternative to live demos is providing preview or QA links to the client, either during a call or for them to explore independently. This allows clients to examine the feature while it's still a work in progress, giving them time to see if it truly solves their problems and meets expectations.

However, this method has its downsides. Some clients may see it as an invitation for scope creep, generating new ideas they want to include in the release. Other clients might be less engaged and not review the link in their own time, causing the team to miss out on valuable feedback.

Demos as part of the process

One way I've adapted my workflow to counter live-demo issues is to shift left and integrate demos into my development process, rather than waiting until near the end of the task life cycle.

As an engineer, when I complete development on a task and I'm ready for code review and QA, I take the opportunity—while my local machine is fully configured for this new piece of work—to record a video demo of the feature. This could be a Loom with a voice over or simply a screen recording.

This video demo becomes versatile. It allows me to share an accurate representation of how the feature should look and behave with QAs or other team members quickly and easily, as well as being shared in client presentations in place of a live demo. The linear nature of video means less flexibility—you can go back and forth, but you can't change the flow of operations. This can be beneficial when presenting, as it limits the context and scope of the discussion to what's being shown. I've had clients pick up on unrelated background elements during live demos, such as debugging software or test data. The video approach makes it easier to ensure the presentation stays focused. Additionally, when a live demo manipulates data, you may not be able to "go back" or revert changes mid-demo, whereas with video, you can simply rewind.

It's important to note that in my experience, clients expect live demos. Going against this expectation by presenting a pre-recorded video, even if you talk through it live on the call, may not inspire as much confidence as a successful live demo would. The key word here is "successful." As discussed, live demos are less reliable, so this needs to be handled on a per-client basis. One way I often try to alleviate concerns is by following up with a preview link for the client to get hands-on with the feature after the call. This way, if they're truly engaged and want a deeper look but weren't satisfied with the video demo, they can check it out themselves, hopefully boosting their confidence.

Conclusion

While this article has focused on ensuring our demos as engineers are as reliable as possible, it's worth noting that clients shouldn't expect bug-free feature demos during development. Ideally, you'd have a client who understands this and a solid team that can effectively manage expectations. However, this isn't always the case, which is why we need to do what we can to ensure our demos run smoothly. Transitioning from live demos to any of the alternatives presented here may seem jarring, but in my experience, most reasonable clients care more about the quality of delivery than the method of presenting work, especially once a way of working has been established.