Demo versus production: how to tell in a screen share

A demo and a production system can look identical on a shared screen for the first ten minutes. The difference shows up in who chose the account, whether the data has history, and what happens when you ask for something the founder did not plan to show. This page is a list of those tells, written for an angel who will never read the code.

What is the difference between a demo and production?

A demo is a prepared path. The founder has chosen the account, loaded data that shows the product well, and practised the sequence of clicks. It proves that the product can do the demonstrated thing under demonstrated conditions, and that the founder can present.

Production is the product as customers meet it. The data was entered by people who made mistakes. The account has history: things done last week, things left half-finished, settings changed and changed back. The address in the browser is the one customers use. Nothing has been reset, and nothing was loaded for your benefit.

The distinction matters more at pre-seed than it did five years ago. A founder with AI coding tools can build a convincing demo of most software ideas in days. Building the version that survives real customers takes the same work it always did. The demo has therefore become cheap evidence, and the standard angel checklists, which what angel diligence misses on technology covers, were written when it was expensive evidence. The ACA's July 2007 screening guidance records that "many software and internet-focused angels do not consider patents an important factor, yet only consider deals with a working prototype". A prototype was once a bar. It is now the floor.

Reveneau's angel review begins with a request for the product on a real customer account rather than a demo, because the gap between the two is the single most common technical finding at this stage and the cheapest one to close.

How do you tell in a screen share?

Six tells, in the order you will meet them.

1. Who chose the account. Before the call, ask the founder to have a real customer's permission to show their account. On the call, you name the customer, or ask the founder to pick one whose name you can search for while they talk. A founder who says "let me use our demo account, the real data is confidential" has answered the question. Customer data can be shown with permission, and a founder raising money has asked for that permission before.

2. The address bar. Look at the address in the browser. A production system lives at the address customers use. A demo often lives at an address with the word "demo", "staging", "test" or "sandbox" in it. Ask what the address is and why. A staging environment is normal to have; it is not the thing to be shown when the question is whether the product is in production.

3. The data. Real data is untidy. Names are misspelled, fields are empty, a record was created twice, dates are in the wrong year. Prepared data is clean and has plausible names that are too tidy. Scroll through a list and look for the mess. Mess is evidence of use, and prepared data never has enough of it.

4. History. Ask to see the last thing this customer did in the product, and when. Production accounts have a trail: an activity log, a modified date, a comment thread. A demo account was reset before the call and has no yesterday.

5. One click off the path. When the founder finishes the rehearsed sequence, ask for something adjacent that a customer would do next. If the deck says the product sends an invoice, ask to see the invoice that was sent last week, then ask to edit it. Watch the response time and the errors. A production product handles the adjacent thing or fails in a way the founder has seen before and can explain. A demo either does not have the adjacent thing or fails in a way that surprises the founder.

6. The founder's own complaints. Someone who has watched customers use a product has a list of things they dislike about it, and the list comes out unprompted. A founder with no complaints has a demo.

What questions expose the gap without being hostile?

The tone matters, because a good founder wants to show you production and a defensive angel makes them show a demo. These questions work.

Question	What a production answer sounds like	What a demo answer sounds like
"Can you log in as a customer, with their permission?"	"Sure, I asked Northgate this morning, here they are."	"Our demo account has better data for this."
"What did this customer do in the product yesterday?"	Opens an activity log or a modified-date column.	"Let me show you what they would do."
"Show me the last invoice this account sent."	Finds it, with a date.	"Invoicing is on the roadmap for Q4."
"What breaks most often?"	A specific part, a reason, a fix in progress.	"Nothing, it is stable."
"How many accounts are live today?"	A number, and where the number came from.	A number from the deck, with no source.

The last row connects to the MVP question. "We have an MVP" and "we have customers in production" are different claims, and MVP diligence covers what each should mean at each stage.

Why does it matter if the demo is honest?

Because an honest demo still proves the wrong thing. Most founders showing a demo are not lying; they are showing the version that presents well, which is what everyone advised them to do. The problem is what the angel concludes from it.

A working demo proves the founder can build a demo. It does not prove that the product handles real data, that it runs without the founder at the keyboard, that it survives a customer doing something unexpected, or that anyone has used it twice. Those are the properties that decide whether the pre-seed money produces a seed round, and they are the properties a demo is designed to skip.

The gap also has a legal edge now. On 18 March 2024 the SEC charged two investment advisers, Delphia and Global Predictions, over statements about AI capabilities that the companies did not have; they paid $225,000 and $175,000. On 25 September 2024 the FTC announced five actions under Operation AI Comply, including a $193,000 settlement with DoNotPay, which had marketed a "robot lawyer" without testing whether its output matched a lawyer's. In each case, the product described and the product built were different things. A screen share of a real account is the angel's version of the regulator's check.

What if there is no production yet?

Then the founder should say so, and the check changes. A pre-seed company with no customers has no production system to show, and pretending otherwise is the problem, not the absence.

In that case the demo is the right thing to look at, and the questions become: who has used this, what did they say, what did you change because of it, and when does the first real account go live. Y Combinator's Michael Seibel, in his August 2019 talk on planning an MVP, tells founders to build something "ridiculously simple" for their first users "in weeks, not months" and to "launch something bad, quickly". A founder who has done that has users to name even before revenue. A founder who has spent a year on a demo with no users has done the opposite of what the advice says.

The one-hour technical check gives this block fifteen minutes and a written output. If the deal is large enough that fifteen minutes is not proportionate, the full method for verifying a product claim on a later-stage deal is in how to run technical due diligence, and the pillar page puts this check next to the other five.

What should you write down?

Three lines. Whether the account was a real customer's, and which one. Whether the claim in the deck ran on that account, and what happened one click off the path. And the first thing the founder said they disliked about their own product. If the first line says "demo account" and the founder could not explain why, the flag is "stop" until you have seen a real one.