Investors have seen a lot of AI demos by now. Many look the same: a prompt goes in, something impressive comes out, and the room is meant to be amazed.
A magic trick is not what persuades a careful investor. Evidence does: a real person doing real work faster with your product, and a founder who knows where it can go wrong.
I sold my startup, Stacks, to EBSCO. One lesson from that applies here. A serious buyer pays for something that works, not an idea, and vanity numbers do not survive a serious conversation. Investors are not acquirers, but they are asking a similar question.
Show a real workflow, start to finish
Pick one user and one task they do today. Show the whole thing: what they start with, what they do in your product and what they end up with.
- Use realistic data. Messy documents, incomplete records, the kind of input customers actually send. Clean examples make every AI product look good.
- Never use real customer data without permission. Build a demo workspace with realistic made-up records instead.
- Do not hand-pick the one input that works. If you are confident, let an investor choose from a pile of samples.
- Show the product people will actually use, not a special demo build. If part of it is mocked, say so.
When I mentor founders, I ask to see the product used live rather than in slides, and where it breaks. Investors want the same thing.
Be honest about where a person is in the loop
If a person reviews the AI's output before it counts, show that step. It is not a weakness. It is how the product earns trust, and the review screen is often the most thoughtful part of the design.
If something behind the scenes is still done by hand, say so plainly. Investors will find out in diligence. It is far better they hear it from you, along with your plan for it.
Show the moment it saves real time
Every good AI product has one moment where the value is obvious. Find it and build the demo around it.
Show the old way briefly first: the spreadsheet, the email thread, the afternoon of copying. Then show the new way. Only claim time savings you have measured, and say how: with whom, on how many tasks. Count review time too. If the AI takes seconds but checking its work takes ten minutes, the saving is the difference between the old way and both of those together.
If real users have used it, show what they did. Usage beats a demo.
Have answers ready for five questions
These come up in almost every conversation about an AI product. Rehearse them as carefully as the demo.
What happens when the model is wrong? Show it. Have a case where the AI gets something wrong and the product catches it: a check that fails, a low-confidence flag, a reviewer who fixes it in one click. Then say how you measure accuracy, ideally against a set of real tasks you run on every change.
What does it cost to run? Know your cost per successful result, as a range, including retries, failures and review time, for light, typical and heavy customers. I wrote about what an AI feature costs to operate.
What if your model provider changes or goes away? Providers retire models on a schedule. Anthropic's deprecation policy gives at least 60 days' notice for publicly released models, and OpenAI's deprecations page lists at least six months for generally available ones, unless safety or compliance concerns require faster. A good answer is that model choice lives in configuration, you have a test set, and you have run it on a second provider.
Where does customer data go? Know what goes to which provider, whether they train on it and how long they keep it. OpenAI's data controls, for example, say API data is not used to train its models unless you opt in, and that abuse monitoring logs are kept for up to 30 days by default. Know the equivalent for every provider you use, and how each customer's data is kept separate from the others.
What is defensible beyond the model? Your competitors can use the same models. So what is yours? Usually some mix of:
- deep knowledge of one workflow and the people who do it;
- integrations with the systems customers already use;
- the corrections and reviews your users make, which improve your tests and your product;
- the trust, security and compliance work a newcomer would have to repeat;
- relationships and distribution.
If the honest answer is "a good prompt," the demo will not save you.
Prepare for the live demo to fail
Live demos fail. Networks drop, a provider slows down, a model gives an odd answer at the worst moment. Plan for it.
- Record a clean run of the same workflow, on the same data, ahead of time.
- Freeze a demo environment with seeded data a day or two before. Do not demo from the branch you changed this morning.
- Know your slow steps and what you will say while they run.
- Bring your own connection.
- Keep screenshots of the key moments as a last resort.
If it fails, say what happened in one sentence and switch to the recording. Label the recording as a recording. Never pass off a recorded or staged result as live.
A failure handled calmly can even help. If your product shows a clear message and keeps the user's work when something breaks, that says a lot about how it will behave in production. Experienced investors know a working demo is not a launch. Showing you know it too is part of the pitch.
A demo checklist
- One real workflow, start to finish, on realistic data.
- The human review step shown, not hidden.
- One moment that clearly saves time, with numbers you measured.
- A rehearsed answer to each of the five questions.
- A recorded backup, a frozen environment and your own connection.
- Nothing staged that you would not admit to in diligence.
If you have an investor demo coming up for an AI product, email me. I am happy to watch a run-through and ask the questions investors will.