5 Tips to Nail Demo Day (Prevent Bugs & Blunders)

Software is sensitive. Let’s face it, one ">" could be the difference between looking like an expert, or wanting to immediately disappear from the face of the Earth.

After years of developing and years of doing it professionally (for a living) with my face and name behind everything we produce, I’ve come to understand the theory of "when, not if, it breaks".

Let me begin by saying this: there’s no easy way to handle a catastrophic bug, or even a small-detail bug, on demo day. That piece of software you have been working on, will at some point, embarrass you. What matters is how you mitigate the chances of things blowing up in your face.

Based on my humble and insignificant experience, these are the steps we’ve taken throughout our processes that can help lower the chances of a complete bug-triggered meltdown on demo day.

To start off…

If you will be the one doing the demo of the "final" software product to clients, potential investors, or prospective users, you have to pay more attention than anyone else.

At the end of the day, you’ll be the one holding your hands to your face and sweating profusely when something goes wrong.

The mindset should be, "No one cares as much as me." Even if your team is a bunch of rockstars, everyone should still be thinking that no one cares as much as they do.

1. Manage your deliverable schedule to your advantage

So, to the point, if your schedule says the client presentation is on Monday, write it down for the Wednesday before that and have everything mocked up as if it were the actual Monday.

Do not think of this mock date as a practice run – it’s not. We should think of it as THE date and act like it is.

Go through every step like you were in the actual presentation, and you will uncover the right bugs (meaning the ones with a higher propensity of showing up in the actual demo). If you fail to accurately portray this date as the actual presentation date, it won’t be very beneficial.

2. Narrow down the scope of your demo

If you know the exact functionality you will be showing off, don’t focus on debugging everything. Focus on debugging your demo-specific functionality.

A few weeks ago we were delivering a medium-sized, consumer-facing, social influence portal for a Latin American company. They wanted to demo the registration process so that they could start signing up potential users.

We knew exactly what they wanted. We debugged that along with the rest of the platform – big mistake!

The night before the demo (out of pure luck), we found a ginormous bug at the exact moment when the user would hit "Register" in a specific, nightmare-inducing, browser which will remain nameless (but we all know which one I am referring to). Keep your debugging efforts focused.

3. Focus on Plan B, and A (and don’t forget Plan C)…

When things go wrong, and you are caught off guard, take a second to feel like a fool… and then swiftly transition into Plan B mode. Have several different backup plans that will allow you to continue with your demo.

Have an offline version. Have a version that isn’t hooked up to the back-end, and is just a front-end version. Keep a prototype on your phone. Mockups. Videos. Something. Don’t put all your eggs in one proverbial basket.

4. … And give yourself ample time to prepare

During this step, you might just find that your piece of software has a problem. You might uncover a huge bug that will at some point blow up during your demo, and this is a great opportunity to decide which materials you will utilize: Plan A + Plan B, or maybe just Plan B, or Plan C, etc.

There are so many factors that can play against your software demo, not just the lines of code. Think about the Internet, the computer you will be demoing on, the projection, etc.

Give yourself time to find out if the version of the software you will be running will be okay. And if that’s not the case, you’ll have time to react.

5. Hand it off, and hand it off a lot

Every developer can understand where I’m coming from when I say, "let it see the light." As developers, and creatives in general, we tend to overprotect our creations until they are the brightest-shining gems, ever. In reality, though, you’ll turn that gem around and find a big chip on it, when you least expect it.

"Deliver" or show the product as much as you can to people that can pilot the application in different environments, browsers, resolutions, operating systems, user accounts, etc. Get the back-and-forth process started on your product early and keep it constant. Development-oriented users couldn’t be more different than end-users.

Wrap Up

The demo-bug-apocalypse can happen to anyone. Just think of the most recent headlines where some of the biggest companies in tech were implicated of the most amateur errors. The point is: let’s not be caught off-guard when important things are on the line.