The day before go-live, don't take the demo

A demo looks like a status update. It’s really a handover. Whoever stands up and drives it becomes the person the client calls when something looks wrong a few weeks later, whether anyone meant it that way or not.

The clearest version of this I’ve seen came up on a fifteen-minute internal standup, the day before a go-live. Nobody on it would have called it a lesson. It was just a team working through a short list. But two decisions got made on that call that I’d want every delivery lead to make the same way, and one thing got missed that I’d want every delivery lead to catch sooner than we did.

TL;DR

On the day before a go-live, the outside lead who knows the most should often not run the demo. Who presents a system decides who owns it in the client’s eyes afterward, and if that’s the person who’s leaving, you’ve built a dependency instead of a handover. Don’t bluff a step you don’t fully understand in front of the client. Check the boring blocker before the visible milestone: can the person who has to use this get in yet? And a production cut is safe to take early when the old manual way keeps working alongside it.

Where things stood

The work was a small integration for a veterinary clinic group: a booking tool wired into the practice-management system the clinics already ran on. It was ready for production the next day.

One fact made that date easy to hold. The new tool was optional. Staff could keep working the old manual way, and going live didn’t take that away from them. Nothing already in place was put at risk by turning it on.

Two loose ends were still open. The clinic group’s owner couldn’t log in yet. And our delivery lead, the person on our side who had done most of the setup, wasn’t sure how one setup step worked in the practice-management system.

That’s an ordinary day-before list. Neither item is exotic. What made the call worth writing about is how the team handled them.

The demo he didn’t take

A member of the build team had planned to run the demo for the client, and he said he’d cover the unclear step there.

On paper, the delivery lead was the obvious presenter. He’d been in the system more than anyone. He’d logged in and, in his words, “done a whole bunch of things.” Most of the setup was his.

He chose not to step in. His reasoning, close to verbatim:

“It’s one thing to record and do a voiceover. It’s a different thing to swoop in and say I’m going to do it, step aside. That’s going to play differently.”

A recorded walkthrough with his voice over it would have been fine. It puts what he knows on the table without putting him at the front of the room. Showing up on demo day and moving the builder aside sends a different message, and it’s the one the client would remember: the outside guy is the one who really runs this.

There was a second reason, and he named it plainly. He’d done the setup, but he couldn’t say how that one step worked. If he pretended to know, “I’m going to look stupid.” He wasn’t going to go “guns blazing” into a step he didn’t fully understand, in front of the client.

I think this is the call a lot of senior people get wrong. When you know the most, the instinct is to hold the wheel. That instinct protects the demo. It doesn’t do much for anything that happens after it.

Who presents it owns it

This is the rule I’d pull out of that standup, and it’s the core of the piece.

A client doesn’t read a go-live demo as a progress report. They read it as a map of who to call. The person driving the screen is the person they’ll message when something looks off, when they want a change, when they can’t remember how a thing works.

If that person is an outside lead whose part of the engagement is winding down, you’ve just created a dependency on someone who’s leaving. If it’s the builder who’s staying close to the work, you’ve started the handover in the one meeting the client is paying full attention to.

This is where I’d expect pushback, and it’s fair pushback. A delivery manager who’s watched a less experienced person stumble through a client demo will tell you the demo is the wrong place to economize on expertise. First impressions of a new system stick, and a fumbled step on day one is expensive to walk back. A client executive who’s paying for senior people may say the same thing more bluntly: why isn’t the expert presenting?

I don’t disagree with the risk. My claim is narrower. When the gap is one step, the fix is to get the knowledge to the presenter, not to replace the presenter. Record the walkthrough. Hand over the notes. Be on the call and answer if you’re asked. What you don’t do is take the chair the day before go-live.

It’s the same logic that sits under putting senior leadership next to a CTO you already have. The point is to make the person who stays stronger, not to become the person the business quietly depends on.

Don’t bluff the step

He could have taken the demo and talked his way past the unclear step. Plenty of people would. It might even have worked, right up until someone at the clinic group tried to repeat it without him.

Naming the gap to your own team costs a minute of discomfort. Bluffing it in front of the client risks the exact credibility you were trying to protect by presenting.

The wrong turn: we were rehearsing the wrong milestone

Here’s the part we got wrong.

While the team was focused on the demo, the more basic blocker had been open since the previous week. The clinic group’s owner still couldn’t log in.

Think about what that means on go-live day. You can run a flawless demo of a tool the owner can’t get into. The demo is the visible milestone. It has a slot on the calendar and an audience. A login problem is a support ticket, and support tickets don’t feel like milestones. So it sat, and the whole team, me included, let the demo set the agenda.

I brought it back to the top. The owner being unable to log in mattered more than anything we were going to show, and I committed to join part of the call.

That’s the question I’d want asked on every day-before standup, and it almost never is: can the person who has to use this get in yet? It doesn’t get asked because there’s nothing interesting about it. That’s exactly why it’s the one that gets missed.

”Your face says it all”

One more beat from that call is worth keeping. When I reset the priority, the delivery lead read my face on the video and said so: “Your face says it all.” Then: “stuff happens, that’s how we’re dealing with it.”

I like that more than I’d have liked a smoother version. The disappointment was real, it got said out loud, and the call kept moving. The alternative is a team that reads the room, says nothing, and carries the tension into the client meeting, where it shows up at the worst possible moment.

Why going live the next day was the easy call

With one blocker open and one step unclear, you could argue for slipping the date. The decision stood: go to production the next day.

It rested on one fact. The old way still worked. Staff could keep doing what they’d always done, and the new tool sat alongside the manual process instead of replacing it. If something went wrong, the fallback was the clinics working the way they already did. That’s a reversible change, and a reversible change that doesn’t disrupt the existing business is safe to take early.

I’ve argued for the opposite on a different project, and the two don’t conflict. In the rushed migration piece, the change replaced the thing the business ran on, right before a deadline, with no clean way back. Capped upside, uncapped downside. Here the downside was capped as well. The date on the calendar isn’t what makes a production cut risky. Whether the business keeps working if the cut goes wrong is.

That’s also something you can design for rather than get lucky with. If you’re scoping an integration, ask early whether the old path can stay alive through go-live. When it can, you can ship before everything is perfect and fix the rough edges while nobody’s stuck waiting on you.

The day-before list

Four questions I’d put on any standup the day before a go-live. They’re not equal. The first one matters most.

• Can the person who has to use this get in yet? Not the admin, not the builder. The person on the client side whose tool this is.
• Who’s presenting, and are they the person who stays? If it’s the outside lead, change it, or turn their knowledge into a recording the presenter can lean on.
• What’s the step nobody on our side can fully explain? Name it on the internal call so you don’t discover it on the client one.
• If this goes wrong, does the old way still work? If yes, go. If no, you’re making a different decision, and it deserves a longer conversation than a standup.

After you leave

Every engagement ends, and the system stays behind with whoever the client thinks owns it. We’ve written about what happens when a system ends up living in one or two heads. A lot of the time it starts with a moment like this one: a capable person stepping in because it was faster.

The delivery lead on this project knew more about the setup than anyone on that standup. The most useful thing he did the day before go-live was leave the demo to someone else.