What a software demo should show you, and what it is hiding

A demo is a performance: the vendor chooses the data, the order and the path through the screens. It proves the software can work; you need to know whether it works on your case, at your volume, on the day something goes wrong. It flips when the vendor opens a test environment holding your own records before you sign: the demo stops being a performance and becomes a rehearsal you can grade.

Why does the demo look better than the system will?

Because everything in it was chosen. The data is small and clean — familiar names, no empty fields, no duplicate customer left over from an import. The path is the one rehearsed last week, with one person logged in and the vendor driving.

None of that is dishonest; it is curated, and production is inherited. Your Tuesday has eleven users, a printer that jams and an export nobody has documented. A demo answers "can it do this at all", rarely the question that decides it.

What is the difference between showing a feature and showing your case?

A feature is a capability: "you can issue an invoice." Your case is a document — the one with a discount agreed on the phone, a returned item from last week, and a customer already over their credit limit. Ask for those three, in that order, without help, and watch where the mouse goes.

What the demo shows	What it proves	What to ask for instead
A record created on an empty form	The form exists	The same record imported from your export
A report with sample figures	The report runs	The report on your last month
A fix typed in live	Someone can type it	Who changed it, and where that is recorded

The third column is the article: what a vendor shows you exists; the question is whether the version to run your business exists.

What are the five questions that force it off the prepared path?

Each of the five you will answer yourself after go-live, so ask it before you pay.

1. Show me the error. Hand them a file with a row that has no customer, and a phone number with a letter in it. What appears, who is told, and what happens to the other rows? "The system validates it" is not an answer; the screen is.
2. Show me who changed this. Open a record, change a price, save, and ask where that change is visible. If the answer is "the manager knows", the first dispute about a price goes back to memory.
3. Show me it with our volume. Bring your real counts: customers, open orders, invoice lines in a year. A list that opens instantly on forty rows is a different program on two hundred thousand.
4. Show me it on the slowest connection. Throttle it, or join from a phone on mobile data. How a page behaves while loading is measurable — Core Web Vitals are the published measures described by the web platform team — but the honest test is on the network your staff use.
5. Show me what happens when two people edit at once. Two windows, same record, both save. Either the second person is told, or the last write wins silently and the first person's work is gone.

A vendor who answers four of the five with a screen has shown you a system; one who answers "that is a configuration detail" has told you where the first month goes.

Why does the recording matter more than your notes?

Because three people will remember three different demos, and the recording is the only neutral account of what was said. Notes in shorthand lose the conditions: "works with the courier" becomes "works", and the condition vanishes between the meeting and the build.

Ask permission, and let the vendor record their own screen share if they prefer; what matters is a file you keep. Then watch it with the person who will actually use the system, and time-stamp every promise as it is made. That list, one line per promise with a time, becomes the sheet you compare vendors on and the first draft of your acceptance tests.

What should you ask for afterwards?

One thing: a test environment with your own data in it. Two hundred customers from your export, one month of orders, the duplicates left in, two logins, one phone.

It is a small ask and the answer is informative: a vendor with a staging process says yes and gives a date; one who cannot may be small rather than careless, but you have learned where the first weeks go. The environment is also the only honest test of the import, the part no demo can show, because demo data was designed to load.

How do you run a demo so that it produces evidence?

1. Send the case in advance: one real document, one awkward one, last month's export with the names changed.
2. Say at the start that you will ask for the failure path.
3. Let the person who will use the system drive, with the vendor talking; you learn where things are only by clicking them.
4. Ask the five questions in order and write the answers in the vendor's words.
5. Ask who will do the implementation, and how long they have worked on this product.
6. Record it with consent and time-stamp each claim as it is made.
7. Close by asking for the test environment with your data, and for the date.

Where this goes wrong

• The manager attends and the clerk does not. The person who spends eight hours a day in the tool is the only one who can say "that is not how we do it".
• A good demo becomes the specification. What looked obvious in a prepared sequence turns out to be undefined: month end, a courier returning half a delivery.
• "We can customise that" with no mechanism. No date, no owner, no idea what it takes — a promise with no shape is the first thing to slip.
• One demo compared against a memory of another. The second is fresh and the first has become a feeling.

What this does not cover

It does not tell you how to compare quotes, which needs a written scope, and it does not cover the contract, the warranty or who owns the code. It is no substitute for calling a reference customer. It matters less for a product you will never customise: with a fixed tool, a trial on your own data beats any demonstration, and the five questions become support questions — who answers, in what language, within what time.

We build systems, and we have sat on both sides of that table; the demo we ask for is the one we would want to give — your case, your volume, your failure, in an environment you are allowed to break.