What Is a Product Demo Video? Types, Length and Examples

You shipped the feature on Tuesday. It took two days. Now the App Store listing wants a preview, the launch post wants something to embed, and the landing page has a grey rectangle on it where a video is supposed to be.

So you go looking for what a product demo video actually is, and every guide hands you the same four-way taxonomy: introductory, walkthrough, custom, live-action. That taxonomy sorts videos by tone. It tells you nothing about the two things that will actually decide your week — what footage you have to produce, and what it costs to make the video again after next sprint changes the screen.

This piece sorts them the other way.

The short answer

A product demo video is a short video that shows a product being used, with the real interface on screen doing real work. It answers "how does this behave?" rather than "why should I care?" Most run between fifteen seconds and three minutes, and the length is set by where the video will be watched, not by how much the product does.

What separates a demo from an explainer or a tutorial

These three get commissioned interchangeably and then underperform, because each answers a different question.

An explainer answers "why." It is usually animated, usually 60 to 90 seconds, and it often never shows the product. It exists to make a stranger understand the problem you solve. Motion graphics and kinetic type are fine here because there is nothing literal to show.

A demo answers "how does it behave." The interface is on screen. Someone taps something and something happens. Its job is to convert a person who already understands the problem into a person who believes your thing solves it.

A tutorial answers "how do I do X." It is for people who already bought. It is longer, slower, and narrated step by step, and it is the only one of the three where completeness beats pace.

If your video shows an illustrated character next to a laptop, you commissioned an explainer. If it walks through settings for four minutes, you commissioned a tutorial. Neither will do the demo's job on a product page.

The four types, sorted by what you have to supply

Here is the reframe. Every type below produces a watchable video. What separates them is what you must hand over to start, and what it costs to produce version two.

The screenshot demo

What it is. You supply stills — App Store screenshots, exported mockups — and a tool animates around them: pans, parallax, a device frame tilting, captions sliding in. This is what most people mean by a product demo animation.

Who it fits. Pre-launch products, teams without a working build, and anyone who needs something on the page this afternoon.

What version two costs. Almost nothing. Swap the PNGs, re-render. That is the real appeal.

The catch. Nothing in it moves the way your app moves. A viewer who has seen ten of these recognises the eleventh instantly, and the thing they cannot tell from it is whether your app feels good to use — which is the one thing a demo exists to prove.

The screen-recording demo

What it is. The default. You record yourself using the product, then cut, zoom, caption and score it. Every guide on the first page of results describes this one and assumes a browser tab.

Who it fits. Anything where you can get a clean take, and especially web products, where the recorder and the product live in the same window.

What version two costs. A full re-record. Not an edit — a re-record, because the footage is a single baked artifact and the changed screen is inside it. This is the cost nobody prices, and for software with a monthly release cadence it dominates everything else.

The catch on mobile. A native iOS app is not a browser tab. You are recording a Simulator or a tethered device, the interaction is a touch flow rather than a cursor, and a mistimed tap ruins a thirty-second take at second twenty-six. Most people get there on take nine. If you are already piping Simulator footage through a general-purpose Mac recorder, how a general-purpose Mac recorder compares is the tradeoff to read before you buy another one.

The generated demo

What it is. You describe the flow, and tools that generate the footage instead of recording it drive the product themselves and return finished video. No take. No timeline.

Who it fits. Teams whose UI moves faster than their video budget, and anyone who has re-recorded the same forty seconds four times this quarter.

What version two costs. Re-running the spec. The description of the flow is the source file; the video is output. That inverts the economics of the screen-recording demo, which is the entire reason this category exists.

The catch. Generating footage means driving a real runtime, which ties the tool to a platform. Nothing does this everywhere. And a generated demo is only as good as the flow someone specified — the tool will faithfully film a boring sequence if that is what you asked for.

The live-action demo

What it is. A person, a camera, and the product in the world. Hands on hardware, a presenter talking to lens, a customer using the thing in a kitchen.

Who it fits. Physical products, and software launches with a budget and a brand reason to put a human on screen.

What version two costs. A shoot. Reshoots are the most expensive line in this article, which is why live-action is used for launches rather than for anything that changes.

Read that column down: almost nothing, a full re-record, a re-run, a shoot. For a product that ships monthly, the type you pick is a decision about the next twelve videos, not this one.

How long a product demo video should be

Length is a placement decision. The same product needs different cuts for different surfaces, and the common advice — "two to three minutes" — is a homepage answer applied everywhere.

Social feed: 15 to 30 seconds. No setup. The interface is on screen inside the first second, because the scroll is the competition.

Homepage hero: 30 to 60 seconds, silent, looping. Assume no sound and no controls. If it does not read muted, it does not read.

Product page: 60 to 90 seconds. The viewer clicked through, so they have declared intent. One flow end to end beats four flows sampled.

Sales follow-up or a SaaS demo video sent after a call: 2 to 5 minutes. Here you have permission for context, objections, and the boring configuration screen the buyer actually asked about.

App Store preview: 15 to 30 seconds, and this one is enforced. Apple's app preview specifications set a minimum length of 15 seconds and a maximum of 30, allow up to three previews per localization, and accept .mov, .m4v and .mp4 (checked August 2026). App Store Connect rejects anything outside that window even when the resolution is right.

Cut for the surface, not for the product. A 90-second product-page video trimmed to 25 seconds is a bad App Store preview; a 25-second preview stretched to 90 is a worse product page.

What a demo video has to contain to work

Six beats. Most weak demos are missing beat one or beat four.

1. The problem state, shown not narrated. The messy version of the screen, the empty state, the manual thing. Two seconds.
2. The interface, immediately. If your product is not on screen by second three, the viewer is still waiting for the video to start.
3. One flow, end to end. A single task completed. Four half-flows read as a feature list and convince nobody.
4. The result. The finished artifact, the saved file, the sent message. A demo that stops at the last tap has shown work, not outcome.
5. The honest constraint. One line naming what it does not do. This costs you four seconds and buys more trust than the other twenty-six combined.
6. One call to action, at the end. Not three, and not one floating over the middle of the flow.

What a product demo video still can't do

It cannot replace a trial. A demo is a claim with evidence attached; a person deciding on a tool they will use daily will still want their own hands on it. Treat the video as the thing that earns the download, not the thing that closes the deal.

It goes stale. This is the failure mode specific to software. You redesign the tab bar and every video you own is quietly wrong — not broken enough to pull down, wrong enough that a careful viewer notices. Ninety percent of the demo-video literature ends at "publish" and never mentions this.

It does not survive muted playback unless you designed for it. Autoplay is silent on every surface that matters. If the narration carries the argument, the argument does not arrive.

It cannot make a confusing product look coherent. A demo that needs eight captions to explain what is happening on screen is a design review wearing a video's clothes.

A concrete example: a 25-second App Store preview, beat by beat

Here is the beat sheet for a preview of a note-taking app's new sharing feature, sized to Apple's 15–30 second window.

0.0–2.0   Empty note list. Nothing happening. The problem state.
2.0–4.5   Tap "New note". Sheet rises. Caption: "Write it."
4.5–9.0   Type a line. Scripted scroll down the note body.
9.0–12.0  Tap the share icon. Hard cut into the share sheet.
12.0–17.0 Pick a collaborator. Avatar lands in the header.
17.0–21.0 Cut to the collaborator's device. The note appears.
21.0–25.0 Title card. One line of copy. No CTA button — the
          App Store already has one under the video.

The interesting column is not the copy, it is the timestamps. Every one of them is a real moment inside a real recording, and every one of them moves when the UI does. Hand-editing means finding all seven again in a new take.

Reely's approach is to stop treating them as timestamps. reely run drives the feature in the Simulator, records it, and writes a timeline.json sidecar of labeled interaction marks beside the recording. The composition then references share-tapped rather than 12.0s, so re-recording after a UI change moves the cut with the tap instead of leaving it 200ms late.

reely run --spec share-note.flowspec.json \
          --device "iPhone 16 Pro" \
          --output out/share-note.mp4

The reel itself is JSON — a FlowSpec for the run and a CompositionSpec for the edit — so version two is a diff rather than a re-record. The FlowSpec and CompositionSpec reference covers the format. The tradeoff is stated plainly above: this works because the tool drives a real runtime, and that means Apple platforms only.

What to look for in the demos you study

Collections of product demo video examples are easy to find and mostly useless as reference, because they are graded on production value rather than on structure. Three things are worth extracting from any demo you admire.

Time the first interface frame. Scrub to the moment the product first appears and note the timestamp. On demos that work it is almost always under three seconds, and it is the single easiest thing to copy.

Count the flows. Watch it once with a finger on the pause key and count how many separate tasks are attempted. Videos that feel confident show one; videos that feel like brochures show five.

Ask what got cut. Every good demo omits a loading state, a login, an empty form. Naming the omission tells you more about pacing than the parts that stayed in.

Four questions, in the order that actually eliminates options.

1. Is the target an App Store preview? Then you need real captured app footage in a 15–30 second window, which rules out most animated formats immediately.
2. How often does this screen change? Monthly or faster, and any format whose version two is a full re-record will bleed you. Optimise for the second video, not the first.
3. Do you have a working build? No build means the screenshot demo, and that is a legitimate answer pre-launch rather than a compromise.
4. Is it native mobile? Then the browser-tab workflow every guide assumes does not apply, and your shortlist is Simulator recorders and tools that drive the app for you.

Frequently asked questions

How long should a product demo video be?

Between 15 seconds and three minutes, decided by placement. Social feeds want 15 to 30 seconds, a homepage hero 30 to 60, a product page 60 to 90, and a demo sent after a sales call can run two to five minutes. App Store previews are the one hard rule: Apple requires 15 to 30 seconds and rejects anything outside it.

What is the difference between a demo video and an explainer video?

An explainer answers why the product matters and often never shows it, using animation to make an abstract problem legible. A demo shows the real interface being used and answers how the product behaves. Explainers typically run 60 to 90 seconds and sit on a homepage or in an ad; demos sit on product pages, in App Store listings, and in sales follow-ups.

What should a product demo video include?

The problem state shown rather than described, the interface on screen within the first three seconds, one complete flow instead of several partial ones, the finished result, one honest line about a limitation, and a single call to action at the end. Anything that does not serve one of those six beats is the first thing to cut when the video runs long.

How much does a product demo video cost?

It depends on which of the four types you pick and how often you remake it. An agency-produced live-action shoot and a screenshot animation you assemble yourself sit orders of magnitude apart. The number most teams underestimate is not the first video but the fourth, since a screen-recorded demo has to be re-recorded from scratch each time the interface changes.

Where to start

Pick your placement first, because it sets the length and the length sets what fits. Then answer question two above honestly — how often does this screen change? — and let that pick the type, since for most software teams the recurring cost outweighs the first production by a wide margin.

If you are shipping a native iOS app and the screen changes every sprint, the version-two problem is the one worth solving first. Reely turns an iOS feature into a finished reel from a spec you can re-run: download it for Mac and point it at your project.