Seven Tells of a Rehearsed Demo, and the Tests That Replace It

Nobody buys software after watching it fail. That is precisely the problem. A demonstration is a rehearsed sequence, performed by someone who has run it fifty times, on data selected to make the product look capable. It is theater, and theater has conventions. Once you know the conventions, you can stop grading the performance and start inspecting the production behind it.

What follows are seven tells worth watching for in any custom software pitch, and for each one, the test a buyer can substitute in place of applause.

1. Pages that load before the request is finished

A screen that renders in under a second during a demo may be doing very little. Sometimes it is showing cached data from the previous session, or a prepared fixture that never touches the production data path.

Ask instead: request that the demo be run against a read-only copy of your own data, in your environment or a sandbox provisioned for the purpose, with the network throttled to something resembling a normal office connection. Load time on unfamiliar data is a more honest number than load time on a curated set.

2. A dataset with no gaps, duplicates, or abandoned records

Demo data is tidy because it was authored to be tidy. Production data has misspellings, orphaned references, and fourteen spellings of the same customer name.

Ask instead: supply a deliberately dirty extract and watch what the system does. You are not looking for perfect handling. You are looking for whether the vendor anticipated the problem at all, and whether the failure mode is a clear message or a silent corruption.

3. The features that were skipped past

Every demo has a section the presenter moves through quickly, with a sentence that begins with something like and this is where you would configure. Those transitions are often where the unfinished work lives.

Ask instead: stop the presenter and request a full walkthrough of that screen, including the validation rules and the error states. Note whether the presenter knows the screen or is meeting it alongside you.

4. Permission checks that are assumed rather than shown

Role-based access is easy to claim and laborious to build. A demo run by a single all-powerful account proves nothing about it.

Ask instead: request two live accounts with different roles and attempt the operations each should be denied. Broken authorization is one of the most common defects in custom business software, and it is invisible in a single-user demo.

5. The phase two hand-wave

The phrase we will handle that in phase two is sometimes a reasonable scoping decision and sometimes a euphemism for the hardest part of the problem. The tell is whether the presenter can describe phase two concretely.

Ask instead: request a written phase two scope with an estimate and a named owner, delivered within a week. A vendor who cannot produce it has not thought about the problem. A vendor who produces it has given you a document you can hold them to.

6. A mobile or secondary view that never appears

Responsive behavior and secondary interfaces are frequently demonstrated by assertion. It is described as working, and the conversation moves on.

Ask instead: open the product on a device you brought, on a browser you chose, and perform one complete transaction end to end. Nothing about this request is unreasonable, and the reaction to it is informative in itself.

7. Answers that arrive faster than the question

The most revealing moments in a demo are the unscripted ones. A vendor who responds to a novel question with a specific, slightly uncomfortable answer — that this edge case is not supported yet, or that this report requires a schema change — is demonstrating something more valuable than polish. They are showing you what working with them will feel like when the demo is over and the change orders begin.

Ask instead: pose three questions the demo did not anticipate and write down the answers verbatim. Then ask what the top three technical risks of your project are. A vendor with none is either unfamiliar with the project or unwilling to say.

Turning evaluation into an inspection

The common thread across all seven tells is that each substitutes the vendor's prepared artifact for your unprepared one. The remedy is the same in every case: bring your data, your accounts, your devices, and your questions, and insist that the demonstration survive contact with them.

Buyers who adopt this posture do not usually get better demos. They get something more useful — an early, honest look at the build they are about to fund, delivered while they still have the leverage to change it.