The Demo Always Works

I have given a great many demos over forty years, and I have never once given one that failed. That is not a boast. It is the entire problem, and it took me an embarrassingly long time to understand what it meant.

A demo is a single rehearsed path through a system, walked by the person who built it, on data chosen because it behaves, on a machine that was working ten minutes ago, in front of an audience predisposed to be impressed. Every variable that could go wrong has been quietly removed, most of them unconsciously. A product is every path, walked by people who do not care about you, on data that is wrong in ways nobody anticipated, while you are asleep and nobody who understands it is awake.

The gap between those two things is not a final sprint before launch. It is the company.

The last ten percent is invisible from where the demo stands

Everyone in this business knows the line about the last ten percent taking ninety percent of the time. Almost nobody prices it in, including people who can recite it. I think that is because the remaining work is not merely underestimated — it is genuinely not visible from the position the demo is given in.

Stand on the happy path and look around. You cannot see the error states, because on the happy path nothing errors. You cannot see the second concurrent user, the customer whose data violates an assumption you did not know you had made, the migration that has to run against three years of accumulated reality, the permission model that has to be right for the one org chart that is shaped strangely. You cannot see what happens when a vendor goes down mid-transaction, or what support says in hour three of an outage, or how a refund actually gets processed by a human being on a Tuesday. None of it appears in the demo, so none of it enters the estimate, and the estimate feels honest when you make it.

This is why “we are basically done, we just need to productionize it” is one of the most expensive sentences in a startup. The word just is carrying eighteen months. I have said it myself, sincerely, more than once.

There is a compounding version of the same error in fundraising, and it deserves saying out loud. Investors largely buy demos, because a demo is what fits in a meeting. So founders learn, correctly, that a great demo raises money — and then generalize, incorrectly, that a great demo means a great product is close. The market rewards the artifact that is easiest to produce and hardest to interpret. It is not a conspiracy; it is just a bad incentive that everyone involved is standing inside.

The AI era made this sharper, not easier

Something changed in the last few years that I do not think has fully landed yet. An impressive demo now takes an afternoon. Genuinely — a small team can produce something that would have been a credible Series A in 2015 before dinner. That is wonderful and I would not undo it.

But it means the demo has almost stopped carrying information. When something is cheap to produce, its existence tells you very little, and the signal moves elsewhere. Meanwhile the distance from demo to production has, if anything, grown. A system that is right most of the time is a spectacular demo and a very hard product, because the failure modes are not crashes you can catch — they are confident, plausible, and shaped exactly like success. Everything that made the demo effortless is the same thing that makes the last mile brutal: no compiler tells you the answer was wrong, and the wrongness looks fine.

So the old discipline matters more now, not less. What used to be a defense against overconfidence is now the only way to tell two very different companies apart from the outside.

Three tests I have learned to run

The first is hostile hands. Give it to someone who wants it to fail — a skeptical engineer, a support lead, a competitor's former customer — and stand there without touching the keyboard. Do not explain, do not steer, do not say “oh, you would normally click the other one.” The first ninety seconds of that session will tell you more than a month of internal testing, because your own hands have memorized every place the ice is thin and route around it without consulting you.

The second is to demo the ugly path deliberately. Show what happens when the input is malformed, the network drops, the account has no data yet, the user does the second-most-obvious thing instead of the obvious one. This is a miserable demo and an excellent one, because a team that can walk that path calmly is a team that has actually built something. I have started asking for it when I am the one being pitched, and the reaction is diagnostic all by itself.

The third is the only one that really counts: one real customer, in production, with money or their own reputation on the line, who has no reason to be kind to you. Not a pilot with a friendly logo. Not a design partner who takes your calls because they like you. One indifferent stranger depending on the thing. Everything you have been calling progress gets repriced within the week, and the repricing is the most valuable information the company will receive that year.

The demo always works. That is what a demo is for, and there is nothing wrong with it as long as you never mistake it for evidence. The product is what happens in the room after you leave — and that room is where every company I have built either earned its next chapter or quietly discovered it had been describing one.