A demo is built to survive one specific run in front of one specific audience. The product has to survive every run, including the one nobody rehearsed.
I once spent an evening getting a feature into a state where I could show it working cleanly, start to finish, in front of someone whose opinion mattered to me. I picked the path through the feature carefully, made sure the data behind it was tidy, and ran through the sequence myself twice beforehand so nothing would surprise me live. It worked exactly as intended. I came away from that evening with real confidence that the feature was finished, because I had just watched it succeed with my own eyes, in front of a witness, on the first attempt, which felt at the time like about as strong a piece of evidence as I could reasonably ask for.
The first time someone else touched it for real, on their own account, in their own order, it broke on a case that had never come up in any of my rehearsals. Nothing about the code was different between the demo and that moment. The difference was entirely in which paths had been exercised, and a demo, by its nature, only exercises the path someone chose in advance to make the thing look good. Every other path is untested by construction, not by oversight, because the whole point of preparing a demo is choosing which corner of the feature gets shown to the room, and every corner left out of that choice has simply never been asked to do anything yet.
I do not think building towards a demo is dishonest, and I still do it deliberately, because forcing a feature into a state where it can be shown cleanly is a useful kind of pressure. It cuts scope. It surfaces the parts of a feature that are actually finished versus the parts I have been telling myself are nearly there for weeks without quite admitting it to myself. A demo that goes badly in rehearsal is one of the more efficient ways to find out something is not ready before anyone else ever sees it, and I have cancelled more than one planned demo purely because rehearsing it honestly told me what a calendar invite never would.
The mistake was never preparing a demo. It was letting a successful one stand in for proof that the underlying thing works, when what it actually proves is narrower: that this one path, set up carefully, run by someone who already knew where the edges were, produced the right result once. That is a real fact, and it is a much smaller fact than "the feature works," and treating the two as the same claim is exactly how something that looked finished the night before breaks in front of a stranger the next morning, on a path nobody thought to check because nobody thought to ask what had never been walked.
What I do differently now is treat a clean demo as the start of the actual test, not the end of it. The questions that matter come after: what happens on someone else’s data, in an order I did not choose, on the account that was created oddly or the input with a character in it nobody thought to type during rehearsal. The demo tells you the feature can work. Only the messier run after it tells you whether it does.
The same gap shows up anywhere a curated run stands in for the real thing: a pitch, a prototype, a proof of concept demonstrated once in a controlled room. None of these are dishonest by default, and all of them earn their keep for the same reason a rehearsed demo does — they force a decision about what to show and what to leave out, and making that decision teaches you something about the feature you would never have learned by only ever running it privately. The mistake only ever comes later, in forgetting which parts were chosen deliberately and which parts simply never had the chance to fail.