App Promo Videos: The Demo Structure That Actually Converts

The default app promo video is a feature tour: open the app, walk through the menus, show each capability in order, end on a logo. It's the most common structure and one of the least effective, because it answers a question nobody asked. Viewers don't want to know what your app contains. They want to know what it does to their problem.

This is the structure that converts, the recording setup that makes it look right, and how to build one demo that feeds twenty different ads.

Why feature tours fail

• They front-load navigation. Menus, settings, and onboarding are the least interesting parts of any product and the first things a tour shows.
• They're organized by your architecture, not the viewer's problem. Your information hierarchy is not their priority order.
• They dilute attention across many features. A video about six things is a video about nothing; viewers remember at most one.
• They delay the payoff. By the time a tour reaches the genuinely impressive part, most viewers have left.
• They open on the product. Screens read as interface, interface reads as advertising, and advertising gets skipped. Explained fully in reaction hooks.

Nobody has ever installed an app because they were impressed by its settings menu.

The structure that works

1. 0–3s — human hook. A reaction clip with a bold caption. Not your app. Not your logo. A face and a claim.
2. 3–8s — the wow moment, mid-action. Hard cut directly into the single most surprising thing your app does, already happening. No login screen, no empty state, no navigation to get there.
3. 8–14s — the payoff made concrete. What just happened, stated plainly: 'that's twelve invoices, sent, in about forty seconds.'
4. 14–18s — one supporting capability. The second-best thing, kept brief. Resist adding a third.
5. 18–20s — soft CTA. App name on screen, 'free to try.'

The load-bearing decision is what goes in seconds 3–8. Pick the one moment that makes a new user say 'wait, it does that?' — not your most-used feature, not your most technically impressive one. The most *surprising* one. Surprise is what earns the remaining fifteen seconds.

Recording a demo that looks right

• Record at device resolution, vertical. Reframing a landscape recording into 9:16 crops away exactly the UI you needed.
• Use realistic, populated data. Empty states and `test test test` entries destroy credibility instantly. Fill the app with plausible content before recording.
• Slow your cursor and taps deliberately. What feels sluggish while recording reads as clear on playback; native speed reads as a blur.
• Record far more than you need. Ten minutes of raw footage yields the six usable seconds. Recording exactly what you planned means reshooting when the edit needs a beat you didn't capture.
• Turn off notifications. A banner mid-demo is both distracting and, occasionally, an accidental privacy incident.
• Consider hand-held phone footage. A real hand holding a real device sometimes outperforms a clean screen capture, because it reads as usage rather than as a product video.

Turning one demo into twenty ads

Because the hook and the demo are separate clips joined by a hard cut, the demo becomes a fixed asset and everything in front of it becomes a variable:

The niche-framing row is quietly the most valuable. One demo plus five audience framings often outperforms five different demos, because specificity reads as relevance and you're only re-recording narration. The full testing system is in creative testing.

Choosing which feature to show

This is the decision most teams get wrong, and it's worth a structured approach rather than an instinct. Score each candidate feature on three axes:

Your most-used feature usually scores badly on surprise (it's expected) and your most technically impressive one often scores badly on visual legibility (it's invisible). The winner is frequently a smaller feature that happens to be instantly comprehensible and mildly astonishing — a one-tap import, an automatic categorization, a thing that fills itself in.

Editing rules for app demos

• Cut every loading state. Even a 400ms spinner reads as friction. Trim it out entirely.
• Speed up navigation, keep results at real time. Fast-forward the getting-there; let the payoff land at natural speed so it's believable.
• Zoom in on the moment that matters. Full-screen UI on a phone is small; a punch-in on the changing element directs attention where you need it.
• Add a subtle highlight or cursor. Viewers need to know where to look, and you have about a second to tell them.
• Captions for everything spoken. A large share of viewing is muted; uncaptioned narration reaches only part of your audience.
• No transitions between demo beats. Hard cuts throughout. Transitions read as production, and production reads as advertising.

App store videos are a different job

Don't reuse your ad as your app store preview. The contexts are opposite: an ad interrupts someone who wasn't looking for you, while a store visitor already tapped through and is evaluating. The store video's job is confirmation, not seduction.

• Lead with the core use case, not a reaction hook — the viewer is already interested.
• Show more of the actual interface. Here they genuinely want to know what using it feels like.
• Assume muted playback. Store previews often autoplay silent; captions must carry it.
• First frame matters enormously — it's the poster image shown before playback.
• Keep it 15–30 seconds. Long enough to demonstrate the loop, short enough to finish.