At a glance

A demo is a test of whether the software can do the thing once, under ideal conditions, watched by someone who wants it to work.

Production is a test of whether it can do the thing thousands of times, under conditions nobody predicted, watched by people who will be very cross if it does not. These are not the same test, and passing the first tells you remarkably little about the second.

What a demo actually proves

It proves the happy path exists. Someone can log in, create a thing, see the thing, edit the thing, and the screen does not catch fire.

That is genuinely worth knowing, and it is not nothing. It is just a much smaller claim than the one people hear when they watch it.

What everyone in the room concludes is "the software works". What has actually been demonstrated is "the software worked, once, for one person, with clean data, on a good connection, doing exactly what the person building it expected".

What a demo cannot possibly test

Five things, and they are the five things that break applications.

More than one person at a time. Two users doing the same thing at the same moment is a completely different situation to one user doing it alone, and no single-person demo will ever reveal it.

Real volume. Fifty rows and fifty thousand rows are the same code and a wildly different experience. Demos run on the fifty.

Anyone else's data. When you are the only account, you cannot possibly see another account's information, because there is not one. The permission check that was never written looks exactly like the permission check that works.

Failure. Nobody demos the payment provider timing out, the upload dying halfway, or the user closing the tab mid-save. In production those happen weekly.

Time. Data gets messy. Requirements change. Someone leaves. A demo is a photograph of one perfect moment.

Why this is worse than simply not knowing

An unproven system makes people cautious. A demo that went well makes people confident, and confidence is what gets budgets signed and launch dates promised.

So the demo does not just fail to find the problems. It actively removes the impulse to go looking for them. Everyone leaves the room believing the hard part is finished, when in truth the hard part has not started.

That is why we keep saying a clean demo is a false comfort rather than a good sign. It is not evidence of soundness. It is the absence of evidence, wearing a very convincing suit.

The better question

Instead of "does it work?", ask these:

  • What happens if two people do this simultaneously?
  • What happens with a hundred times more data than we have now?
  • Can a logged-in user reach a record that is not theirs by changing a number in the address bar?
  • What happens when this external service is down?
  • If this breaks at three in the morning, how would we find out?

Five questions. If nobody can answer them, that is your actual status, regardless of how well the demo went.

None of this means the software is bad

It usually is not. Most of what we look at is perfectly reasonable work that simply stopped at the demo, because the demo was the point at which everyone believed it was finished.

The gap between "it works" and "it is ready" is real, well understood, and entirely fixable. It just has to be acknowledged before customers do the acknowledging for you.

If you would rather find out where you stand than wonder, our free AI app risk scorecard walks you through the categories and gives you a score in a few minutes. No sales call attached to it.

It is the same idea this series is built on: AI is a brilliant typist and a terrible architect. A demo tests the typing.

Want a person rather than a questionnaire? Our AI Code Audit is a fixed-price £495 review that tells you plainly what you are dealing with, or get in touch for a no-pressure conversation.