The morning of the demo, I was feeling myself.
I'd drafted a thank-you message to the team for a job well done. Blocked everyone's calendars for the evening. Went about my day with the quiet confidence of someone who had done absolutely everything right. A couple of hours before showtime, I jumped on a quick call with the engineers, ran through the features one more time. Everything worked perfectly.
And then, well. It didn't.
I vented on Twitter that evening (I still refuse to call it by its new name) and was genuinely blown away by how many people came out of the woodwork. The stories that flooded in had me howling. Turns out, a deep, visceral dread of live demos cuts across every level, every title, every year of experience.
I've heard people say, flat out: "just expect the worst when you demo."
That should not be normal. And honestly, I don't think it should be acceptable. Because here's a truth worth sitting with: whatever experience you're having during your demo is the experience your users are having in real life. And we definitely want better than "expect the worst" for our customers.
I was fortunate early in my career to have a line manager who was borderline obsessive about keeping applications in optimal shape. Not just before big moments. Always. A lot of what he drilled into me has never left. Combined with a few hard-won lessons of my own, tested, trusted, and occasionally learned the chaotic way, I've put together habits that keep my demos from going off the rails.
Feeling generous today. Here's what they are.
Most tech teams run two environments: Test and Production. I'd argue that's one short.
Picture a team with only those two. An engineer builds something locally, merges to test, it gets reviewed, then deployed to production. Seems fine on paper. The problem is that the test environment is rarely a true reflection of production. More often than not, it's carrying features, data states, or configurations that don't yet exist in the real world. So when the team runs their checks, they're not testing against production. They're testing against a version of it that doesn't quite exist yet.
That gap is exactly where things quietly break. And it has a habit of showing up at the worst possible time.
Now add a staging environment in the middle. Features get built and merged into test as usual. Once verified, they move to staging, which is deliberately set up to mirror production as closely as possible. That's where you isolate what's actually ready, simulate the exact conditions of a live deployment, and properly stress-test changes before anything goes live.
Fewer surprises. More confidence. That's the whole point.
This one sounds obvious. It gets ignored constantly.
No matter how clean a change looks, every deployment carries risk. Something can behave differently in production than it did in staging. A dependency can shift. A config can be slightly off. The rule I follow: anything being demoed should be deployed and fully tested at least three to twenty-four hours beforehand. That window gives you time to catch anything unexpected, roll back if needed, and walk into the room without that quiet dread of "we pushed something an hour ago."
The tighter the gap between deployment and demo, the less room you have to recover.
Just don't do it. Un-Nike.
Even when you've done everything right, things can still go sideways. That's just live software.
What separates a recoverable moment from a full disaster is usually just having the right people available. Before any significant demo, make sure your engineers know it's happening and are reachable. Not hovering over their laptops, but not unreachable either. A quick heads-up beforehand, a shared channel where issues can be flagged instantly, and clarity on who owns what can turn a potential nightmare into a two-minute fix the audience barely notices.
This one came straight from the replies after I posted about the demo fail. A lot of people swore by it, and the logic is simple: anything can happen. Record a clean walkthrough of your flows beforehand, just in case.
I'll be honest, I'm still working out exactly how I'd make that switch mid-demo without it feeling awkward. But I think about it like this. If something breaks, the composed version of you looks the audience in the eye and says: "Apologies, we've hit a technical issue and the team is already on it. So we can still make the most of our time together, I have a recorded walkthrough of the flows. Would you mind if I pulled that up?"
That works. It's calm, it's solution-oriented, and it keeps the meeting moving. Is it the ideal scenario? No. But it's better than silence and a frozen screen.
It's a last resort for a reason. Let's all hope we never have to use it.
Demos will always carry a little bit of nerves. That part isn't going anywhere. But there's a real difference between healthy nerves and dreading the whole thing, and most of what makes demos go wrong is preventable.
The demon isn't the software. It's the shortcuts you took two weeks before the call.
Build the habits, do the preparation, and when something still goes sideways despite all of it, at least you'll know it wasn't you. Software is humbling like that. It will occasionally make a fool of all of us.
Just don't help it.
You are welcome.
