An AI Product Has Almost No Visible Surface. The Demo Has to Build One.

In a normal SaaS demo the interface is the product. You record a workflow and the workflow is the argument: click, state changes, task done. The viewer follows cause and effect because both are visible. An AI product breaks that in three ways.

First, nothing on screen changes state in a way that reads as progress. A cursor blinks in a text box. Second, the impressive part arrives all at once, at the end, after a wait. There is no build. Third, and worst, the viewer cannot distinguish a genuinely good output from a merely plausible one.

You are also shooting for an unusually sceptical room. Only 46% of people globally are willing to trust AI systems (KPMG and the University of Melbourne, 2025, 48,000 people surveyed across 47 countries). Among developers the split is worse: 46% distrust the accuracy of AI tools against 33% who trust it (Stack Overflow, 2025 Developer Survey, 33,244 responses on that question).

Assume the viewer thinks it is cherry-picked. Shoot to defeat that, not to impress.

The answer differs by category, and getting it wrong is the most common reason an AI demo feels thin.

Two rules cut across all five. Never center the frame on the model when the output can be there. And never show an AI feature without showing what it displaced.

Six things, in order of importance.

• Show the input in full. Do not cut away from the prompt, and do not crop it. If the prompt is off screen, the viewer assumes it was engineered for twenty minutes.
• Keep the generation moment in one continuous take. Cut the wait if you must, but never cut inside the event itself. A cut mid-generation reads as a splice.
• Show the output being used, not admired. The strongest shot in an AI demo is the output landing somewhere consequential: a pull request opened, a deck presented, a ticket closed. A wall of generated text is a screenshot with a soundtrack.
• Let something be imperfect and visible. One messy row in the source data. One field the user fixes by hand. Perfect inputs are the tell that the whole thing was built for the camera.
• Use real structure. Swap customer names, keep the mess. Real data has duplicates, blank fields and inconsistent date formats. A demo with none of that is not a demo of real work.
• Use the median run, not the best one. Run the same prompt three times and take the middle result. It is the difference between a demo that survives a trial and one that creates a refund conversation.

Show the check, not the claim.

A voiceover line saying the model is highly accurate is worth nothing. A shot of the user opening the citation, reading the source and closing it is worth the entire section. Same for a diff reviewed before merge, or a test suite running green after generated code lands.

This is not a stylistic preference. 66% of developers say their single biggest frustration with AI tools is solutions that are almost right, but not quite (Stack Overflow, 2025). A demo that never acknowledges near-misses is talking to an audience that does not exist. Your viewer will check your work too: 94% of B2B buyers who used AI in their purchase journey fact-check its responses at least some of the time (TrustRadius, 2026 B2B Buying Disconnect Report, 1,862 buyers surveyed).

Practical rules. If you have evaluation numbers, put them on screen with the benchmark name and the date, held long enough to read. If you do not have them, do not gesture at accuracy at all. If the product exposes a confidence signal, show a low-confidence case too. An indicator that is always green is decoration.

Most attempts fail the same way: multi-step autonomy on screen looks like a computer doing random things quickly.

Give the agent a persistent visual spine. A plan panel that stays in frame for the whole sequence, steps checking off, so the viewer always knows where they are. Then frame it as two layers: intent on one side, effect on the other. The plan updates, the application changes. Cause and effect become visible again.

The proof shot is the deviation. Find the moment the agent hits a state it did not expect, a failing test, a missing field, a rate limit, and rewrite its plan on screen. That single beat does more for credibility than five clean steps, because it is the one thing a scripted fake would not contain.

Two more rules. Signpost time compression with an elapsed timer that visibly jumps or a card saying how long passed. And do not narrate every step. Narrate the decision, then let the steps play under music.

Real thinking time is dead air. Cutting it to zero reads as pre-rendered. The answer is compression with the seams left visible.

• Keep 0.5 to 1.5 seconds of the real wait before compressing anything. That beat establishes the work is happening now.
• Ramp into and out of the speed change. A hard jump cut mid-motion reads as a mistake.
• Put an on-screen elapsed timer on any run longer than 10 seconds. It converts dead air into a countdown and it is honest.
• Use the wait rather than hiding it. Streaming tokens, retrieved sources appearing, plan steps resolving. If your product shows nothing at all during a 20 second wait, that is a product finding worth sending to your PM.
• Keep one uncut take of the full wait. Sales will want it for the sceptic who asks how long it really takes.

Yes. One, deliberately placed, in any demo over two minutes.

The failure you show is not a crash. It is the model getting something wrong and the product catching it: a low-confidence flag, a human-in-the-loop approval, a retry with a different tool, or a clean refusal. That is a claim about product maturity. Guardrails only exist in products that have met real users.

Placement matters. Put it in the second or third minute, after the product has earned the right. Never in a 30 second short-form cutdown, where there is no room to resolve it.

Our interface is genuinely just a text box. Is there anything to shoot? Yes, but not in the text box. Shoot the surrounding work: what the user had open before, what they do with the output, what stopped happening in their week. The product is the hinge in that sequence, not the subject of it.

Should we use a real customer's data? Use real structure with substituted identifiers, cleared in writing before the capture session, not after the edit. Rebuilding a demo because legal rejected a dataset is the most avoidable delay in this category.

How do we stop the demo being obsolete in six weeks? Shoot modular. Separate captures per workflow, separate voiceover per section, no continuous take spanning three features. When the nav changes you replace 15 seconds, not the whole video.

Should the video explain how the model works? Almost never in a demo. Architecture belongs in an explainer video or a technical long-form piece. A demo that stops to describe retrieval has lost the evaluator it was made for.

Do we need a separate version for developers? Usually yes, and it is a different edit rather than a different shoot. Developers want the request, the response, and the failure mode, with less voiceover and more screen time on code. Same capture, different assembly.