The demo is not the product

A demo is a rehearsed path through clean data.

That is not an accusation. It is what a demo is for. The sales engineer has walked this path a hundred times, the sample vendors have sensible names, the quantities are round and every document was created by the same person that morning.

Everything that will go wrong in real use is off that path. So an evaluation session is worth having only to the extent that you take it off the path.

Bring your own material#

Before the meeting, collect four documents from your own files. Photocopies or photographs are fine. Bad ones are better.

• A challan photograph with a smudged number. Taken at the gate, at dusk, slightly out of focus, with one figure overwritten. The one your storekeeper actually sends.
• A vendor bill whose total is wrong. Quantity times rate does not equal the line, or the tax is calculated on the wrong base. These exist in every office and they are the whole reason for checking.
• An invoice for a partial delivery. Half the order came, the invoice is for half, the order is still open. Many systems cannot say this cleanly.
• A work order with a variation on it. Extra work agreed after the fact, at a rate settled verbally and confirmed in a message.

Hand these over at the start and say you would like to see them entered. Not described. Entered.

Ask for the keyboard#

Where the meeting allows it, the person who will actually use the screen should do the typing, on the vendor's laptop, with the sales engineer watching rather than driving.

This single change tells you more than the rest of the session. You find out how many fields there are, which ones are compulsory for no reason, what the error message says when a date is entered in the Indian order, and whether your storekeeper can find the save button without being told.

When the vendor's hands are on the keyboard, you are watching a performance of competence. It is theirs, not yours.

The things to ask to see, not to be told#

Ask in these words: show me. A promise is not evidence and costs nothing.

A correction after approval. A bill was passed and the quantity was wrong. Fix it in front of you. Watch whether the old value survives anywhere, who is recorded as having changed it, and whether the approver is told. Then look at the record's history, using the questions in ask to see the audit trail.

A cancelled document. Not deleted — cancelled. A challan entered against the wrong site, a duplicate receipt, a purchase order raised and then dropped. Ask what happens to anything already linked to it.

A duplicate. Enter the same challan number for the same vendor twice. A system that accepts it silently will accumulate duplicates for years. A system that refuses it outright will eventually block a legitimate case, because suppliers do repeat numbers across financial years.

The screen the storekeeper will use. Not the dashboard. The narrow, dull, frequently used screen where a lorry gets received. Ask how many taps it takes one-handed on a mid-range phone. If the answer is a laptop, you have learnt something important.

What happens with the network off. Turn the wifi off on the demo machine, or ask them to put the phone in flight mode, and continue. Watch the entry being made, then watch it arrive when the connection returns.

The audit trail of the record you just made. Not of a sample record. The one created ten minutes ago from your smudged challan.

The export. Ask for the data you entered today to come out as a file, and open the file in the room.

Red flags#

None of these is fatal on its own. Two together should slow you down.

"That's on the roadmap." Treat a roadmap item as not existing. It may arrive, but it will not arrive on the date you need it and no part of your decision should depend on it.

A demo environment they will not let you touch. If you cannot have a login to a sandbox for a week, ask why. The usual reason is that the unrehearsed paths are not presentable.

No answer about who else runs this at your scale. You are not asking for names they cannot give. You are asking whether a builder of your size, with your number of sites, is already living with the product.

Refusal to show an error state. Every real system has failures, retries and messages. A vendor unwilling to show one is telling you the messages are not fit to be seen. Whether an error explains itself is the difference described in the app should tell you why.

A dashboard shown for longer than data entry. Charts are the easiest part of any system to build and the least used. The time split in the demo is a fair estimate of where the product's attention has gone.

Get it in writing, dated#

The demo is the only moment in the whole relationship when the vendor is answering questions rather than asking for money. After the contract, the same questions go to a support queue.

So before the session ends, agree that a written list will follow: what was shown, what exists today, what is configuration, what is custom work, what is on a roadmap, and what was said about data export and about support. Dated, and from the vendor rather than from your own notes.

You are not building a case for a dispute. You are removing the ambiguity that otherwise settles in over the following months, when everybody involved remembers the meeting differently and nobody is lying.

Then stop deciding. A demo can only tell you whether the product can do the work. Whether your organisation will do the work in it is a separate question, answered by a trial designed to be capable of failing — a pilot that tells you something. The wider decision it feeds into is in how to choose construction software.

The short version#

The demo path is clean because it was rehearsed. Take it off the path with your own smudged, wrong, partial documents, and ask for the keyboard.

Insist on seeing corrections, cancellations, duplicates, the storekeeper's screen, the network off, the audit trail and the export. Then get the promises in writing, dated, while the vendor is still answering.