A demo on dummy data is a promise

It has never been cheaper to build a convincing demo. A working dashboard, a chat assistant or a review tool can be put together in days, running on sample data that looks real. In a pitch, that is powerful. A client who can click through a product understands it far better than one reading a proposal.

It is also a risk. A polished demo on dummy data makes a promise about speed, accuracy and cost that nobody has tested yet.

What dummy data hides

Sample data is clean by construction. Every field is filled in, every name is spelled the same way, and every date is a date. Real data in a bank or insurer is none of those things. The gap shows up in three places.

Data access. In the demo, the data is a file in the repository. In the real project, it sits in several systems, behind several owners, and getting it out takes approvals that can run for weeks.

Edge cases. The demo shows the ten cities where the story is clearest. The real product must handle the district with no records, the duplicate customer and the policy issued under an old product code.

Running cost and review. The demo answers instantly because nothing is being checked. In production, someone has to review the output, and that time is a cost the demo never showed.

Four rules for demos

Any demo that runs on sample data should say so on screen. That is the first of four rules worth following.

1. Label the data. Say clearly, on screen, that the numbers are illustrative. A label costs nothing and prevents most misunderstandings.
2. Show the seams. Point out which parts are real and which are faked: the model, the data pipeline, the integrations, the review step.
3. Name the hard part. Every demo has a part that will be hardest to make real. Say what it is before the client asks.
4. Price the gap. If the demo leads to a proposal, the proposal should cost the work between the demo and production, not just the work the demo implies.

A demo should make the decision easier, not the delivery harder.

Are demos worth it?

Yes, used well. A demo helps a client decide what they want, which is often the hardest part of a technology project. It surfaces disagreements early, when they are cheap. It replaces pages of description with something people can react to.

Used badly, a demo wins the work and then damages the delivery, because the team spends months explaining why the real thing is slower, messier and more expensive than the thing the client saw.

The difference is honesty about what the demo is. Treat it as a question you are asking the client, not as a product you are selling them.