What investors actually look for in a demo

A demo is not a product walkthrough. That's the most important thing to understand before you build one for investors. A product walkthrough shows what you've built. A demo shows what you're building — the shape of the eventual thing, the specific problem it solves, and that someone has the judgment and skill to get there.

Those are different goals, and they require different decisions about what to build, what to simulate, and what to leave out entirely.

What investors are evaluating

In the first two minutes of a demo, an experienced investor is assessing:

• Is the problem real? (Do I recognise the pain from conversations or other companies?)
• Is this the right solution shape? (Does the product flow match how people actually work?)
• Does this team understand the problem deeply? (Are they solving the thing, or a toy version of the thing?)

The technology specifics come much later, if at all. The product intuition on display is what closes early rounds.

What to build, what to fake

The distinction that matters is core loop vs. supporting infrastructure:

Build the core loop. Whatever the primary action is — the thing a user does every day if the product succeeds — that needs to work. Slowly, imperfectly, with rough edges: fine. But it needs to be real, because it's what you'll demo, and demos of non-working features collapse under any question that deviates from the script.

Fake everything else. Auth flows, settings pages, billing, onboarding, admin dashboards — these take weeks to build properly and contribute nothing to a five-minute demo. Hard-code the data. Skip the loading states. Put a "coming soon" label on the empty states. Investors who have built products know this is the right call. Investors who haven't are not the ones you want.

Skip entirely: anything that exists to demonstrate technical sophistication rather than product value. A real-time collaborative feature in a solo productivity tool. A data visualisation layer for an app that doesn't yet have data. Investors fund the problem solution, not the engineering complexity.

The error you cannot afford to make

The worst demo outcome isn't a bug. It's a product that doesn't make the investor feel the problem. You can recover from a crash ("we'll send you a screen recording, this part works"). You cannot recover from thirty minutes of features that the investor didn't understand were solving a real problem.

Start with the pain, not the product. Before touching the screen, describe a specific situation where the problem costs someone real time or money. Then show how your product changes that situation. The demo is evidence for the story, not the story itself.

After the demo

Two things to prepare for every demo session:

• A "what would you want to see next" prompt — the investor's answer tells you what they found believable and what they're still skeptical about
• A technical depth answer for anyone who asks — even if the demo is simple, you should be able to describe the architecture and the hardest part you've solved

Investors who pass often do so because they couldn't tell whether the team knew how to scale what they'd built. Not because the demo was rough — but because they couldn't form a view on the path from here to product-market fit.

The demo's job is to make that path feel obvious.