Prototype, demo or MVP: what to build for an investor or customer demo

For an investor or customer demo on a fixed date, build the smallest thing that makes one claim believable to that audience on that day. Depending on the room, that means a clickable prototype, a coded prototype or a scripted demo build; unless the product already exists, it does not mean an MVP. An MVP answers a different question: whether real customers will use the product, and what you learn when they do. That needs time in customers' hands after release, which a demo date does not give you.

So decide two things first: who will be in the room, and the one sentence you need them to believe. Then plan fidelity screen by screen, stage only what is not the claim, say out loud what is staged, and decide before you build whether the result will be thrown away or hardened afterwards.

The four artefacts, and the question each answers

The words get used loosely, and teams argue past each other because of it. Stephanie Houde and Charles Hill, then designers at Apple, made the case in What Do Prototypes Prototype? that describing a prototype by its tool or its polish misleads, because "detail is not a sure indicator of completeness". Describe each one by the question it answers instead.

• Clickable prototype. Linked design screens that someone can tap or click through along a set path. It answers: does the story and the flow make sense? It shows layout, wording and sequence. It cannot respond to anything it was not built for.
• Coded prototype. A small piece of running software, built to answer one question with sample or real data. It answers: does the behaviour hold up once real data, typing, resizing or a slow AI answer are involved? Our glossary sets out how a coded prototype differs from a Figma prototype and from production code.
• Demo build. Software or a prototype prepared for one path in front of one audience. The path is real or rehearsed; everything off it is stubbed, seeded or missing. It answers: will this audience believe this claim? It is a tool for a performance, not a product.
• MVP. Eric Ries, who popularised the term, defines it as the version of a new product "which allows a team to collect the maximum amount of validated learning about customers with the least effort". He adds that it "is not about creating minimal products". It answers: what do real customers do with it?

A fifth term appears in the same searches. A proof of concept answers whether the hard technical part can work at all. NASA's Technology Readiness Levels place it early: "Often during TRL 3, a proof-of-concept model is constructed", when studies test whether a technology is viable. It convinces your engineers and a technical reviewer more than it convinces a room.

Choose by the audience and the claim

Write the claim before you open a design tool: one sentence, in the audience's words, that the demo must make believable. "Our product turns a week of manual reconciliation into one review screen" is a claim. "We have built a platform" is not. Every screen you build either carries that sentence or gets you to the screen that does.

Then look at who is judging it. Houde and Hill found that the right prototype depends on its audience, and that "less expert audiences cannot normally be expected to understand such approximate representations". Rough work reads well to your own team and badly to a stranger.

Investors buy the narrative, the insight and the team. Y Combinator's guide to Demo Day presentations, by Geoff Ralston, notes that "demos seldom work in modern demo day presentations" and that "investors are investing in you and your team above all". In a longer meeting, a short demo earns its place when it makes the insight concrete: the moment where the problem visibly goes away. A clickable prototype or a demo build of that one moment is enough for that. The data has to be believable and tell the story; it does not have to be anyone's real data, as long as you say so.

A pilot customer is asking a different question: will this work in our world, with our records, our roles and our odd cases? Polish matters less than behaviour. They will want to type their own example, and they will ask what happens when a record is missing. That calls for a coded prototype on their data, or on sample data shaped like it, with the awkward cases built first. It is how we run coded prototyping: the question agreed in writing before any code, and the empty, error and dense-data cases built before the happy path. Our guide on when to prototype in code instead of Figma covers that choice in more depth.

A trade show or public launch has the broadest audience of all, and no second chance to explain. Houde and Hill describe Apple's Knowledge Navigator video, a highly produced vision film, and conclude that "high resolution was necessary" because the audience was "almost anyone in the world". Here the demo has to look finished, run unattended, survive a bad connection and be safe for strangers to touch, so most of it is staged and the loop is short.

If the date is the day a customer starts using the product without you beside them, it is not a demo. It is a release, and the question becomes what a first release must prove. Our article on what a SaaS MVP must prove and what to leave out covers that case.

Why an MVP is the wrong thing to build for a demo date

A demo is a claim, not a product. An MVP and a demo build spend effort in opposite places. An MVP spreads it across everything a stranger needs to use the product unaided: sign-in, roles, errors, recovery, data that persists. A demo build concentrates it on one path and the moment the claim lands.

Try to make one artefact do both by a fixed date and both suffer. The breadth an MVP needs eats the time that should have gone into the claim's path, so the moment the room is judging is the least finished part. The rush to hit the date leaves the MVP's foundations thin, and those are the parts real customers lean on. In our view, a founder who builds an MVP for a demo date ends up with neither a good demo nor a good MVP.

There is one clear exception. If the product already exists and works on the path you need, show the real thing; nothing is more convincing. Staging is for what does not exist yet, not a habit.

Plan fidelity screen by screen

Fidelity is a decision per screen, not per project. Write out every screen and moment on the demo path in order, then mark each one real, staged or absent.

• Real means it behaves as the product will: it responds to input and handles the data it is given.
• Staged means it looks right and is driven by a script, fixed data, a recording or a person.
• Absent means it is not built, and the path never goes near it.

The rule: the screens that carry the claim are real, the screens that only lead there may be staged, and everything else is absent.

Two checks before you commit to the plan. First, count the real screens: if the list is long, the claim is probably too broad, so narrow the sentence rather than build more. Second, ask what the sharpest person in the room will try to do off the path, and decide in advance whether you will let them.

What you may stage, and how to say so in the room

You may stage anything that is not the claim, provided you would say so if asked, and you say it unprompted when it matters to the decision in front of them. You may not quietly stage the claim itself. If a colleague is typing the "AI" answers, the demo proves nothing about the AI.

That technique has a name and an honest history. J. F. Kelley's 1984 paper in ACM Transactions on Office Information Systems described what he called "the OZ paradigm", in which participants believed they were using working software while "the experimenter surreptitiously intercepts communications" and supplies the answers. As a research method it lets a team learn how people talk to a system before the system exists. Used undisclosed in front of an investor or a customer, the same trick misleads them about what exists.

Houde and Hill make the general point: a prototype's value depends on communicating its limited purposes to each audience, and their model is meant to show what a prototype explores "and equally important, what it does not explore". Our own glossary puts it plainly: running code can look more finished than it is, so a good prototype states what it tests and what it simulates.

Saying so costs less than founders fear. A few sentences cover most cases:

• "This runs on sample data shaped like yours; connecting your live system is the next piece of work."
• "Sign-in is switched off for this demo."
• "This answer is a recording of a real run, so you can see it without waiting; we can run it live afterwards."
• "Everything you are seeing is designed and clickable; the engine behind this screen is what we build next."

Put the same list in your follow-up email, under two headings: what is real and what is staged. It protects you later, when someone remembers the demo as more finished than it was.

The coded demo we built for ConnectX, a company that wanted an AI-first product for managing energy across commercial buildings, was scoped this way. It covered eight defined scenarios on an interim data layer, and its case page states plainly what it did not demonstrate: live telemetry, adoption, operational savings or commercial outcomes.

Plan backwards from the date

Start at the date and work back. Each step fixes something the step before it depends on.

1. The room. Who attends, how long you have, whose screen and whose network, who drives, and whether anyone will ask to try it. These are fixed; design around them.
2. The final rehearsal. On the same laptop, display and network as the day, with someone playing the most sceptical person in the room.
3. The fallback. A recording of the full path and stills of the claim moment, ready to switch to without apology if the live build fails.
4. The freeze. After this point, only fixes to the path. No new features, however small.
5. The staging. Fixed data, recordings and stubs for everything marked staged, each one listed so you can name it in the room.
6. The claim screens. Built first and finished first, because if time runs out you cut from the edges of the path, never from the claim.
7. The data. Get or make the data the claim needs early. A customer's own records need their agreement and their help, and can be the last thing to arrive.
8. The script and the claim. One sentence, then the path that proves it, written before any build starts. The script decides which screens exist.

Read the list from the bottom up and you have the order of work. Read it from the top down and you have the questions to answer on the first day.

After the demo: throw it away or harden it

Decide before you build, because the answer changes how you build. Houde and Hill observed that "it is often desirable to treat even implementation prototypes as disposable". A demo build full of staging is the first candidate to throw away.

Throw it away when it was built for the room: staged in many places, made in a tool your product will not use, or shaped around a story rather than a workflow. Keep the script, the claim and what the audience asked; they are the most valuable output. Do not leave a staged build with an investor or a customer as if it were the product.

Harden it when it is a coded prototype in your own stack, the claim's path is real, and a pilot customer wants to keep using it. Hardening starts by naming everything that was simulated, then sorting the code into keep, redesign or replace before anyone adds features. If the demo was made with an AI app builder and real customers are next, our Prototype Readiness Review marks each part as proven, assumed or missing, including the cases a demo skips: failed payments, double taps, locked-out users. Our guide to taking a vibe-coded app to production sets out the steps in order.

Either way, the demo did its job if the room believed the claim and the claim was true. What you build next should start from what they asked, not from what you happened to stage.