It's not laziness. A demo video is a five job pipeline, and developers only signed up for one of those jobs.
A feature gets merged. Someone says "we should make a quick demo for this." A week goes by. Then the next release goes out. Then the UI changes, and the demo you never made would have been out of date anyway.
If you build software, you've probably seen this happen. The feature is in the changelog and maybe in the docs, but there's no video showing it working, so plenty of users never find it.
I don't think this happens because developers don't care. I think it happens because a demo video looks like one task and is actually five.
Key takeaways
- A demo video looks like one task, but it's really five: story, script, voice, footage, and editing with formats.
- Screen recordings go stale with every release, so the real cost is remaking the video, not making it once.
- Writing the story and script as text before recording, and keeping each video to one feature, makes demos cheaper to redo.
- Treat demos like docs: when a release changes a screen, the demo for that screen goes on the update list.
Contents
- Key takeaways
- A "quick demo" is five jobs
- The screen recording trap
- What actually helps
- Where DemoVexa fits
- A quick checklist for your next feature
- FAQ
A "quick demo" is five jobs
Here's what a decent product demo actually needs:
- A story. What problem is this feature solving, for whom, and in what order should the screens appear? This is product marketing work.
- A script. Words that match each scene, short enough that people don't drop off.
- A voice. Either you record yourself, which most of us hate, or you find someone who will.
- The footage. Usually a screen recording. Which means clean sample data, a clean browser, no notifications, and a cursor that doesn't wander.
- Editing and formats. Cuts, zooms, captions, and then a 16:9 version for YouTube, a vertical one for Shorts or Reels, and maybe a square one for LinkedIn.
Each of these is a separate skill. A developer can do all five, but they'll be slow at three of them, and the whole thing competes with the next ticket. So the demo slips.
The screen recording trap
Most of us start with step 4 because it feels like the "real" work. Open the app, hit record, click through the feature.
Then the problems show up:
- You fumble a click on take three, so you restart.
- Your local database has test rows called "asdf" and "test test 2" that you don't want on camera.
- Someone's real email address is visible in a table.
- You finish recording and realise you never explained why the feature matters.
Each of these has a fix that you can set up once:
| Problem | Fix |
|---|---|
| A fumbled click ruins the take | Record scenes separately, so one mistake costs one scene |
| Test rows like "asdf" on camera | A seed script or demo account with believable data |
| Real customer data visible | A demo account that never holds real data |
| The "why" never gets explained | Write who, before and the one moment before recording |
| The video shows an old UI after a release | Put the demo on the list of things to update when that screen changes |
And the biggest one: the recording goes stale with every release. You rename a button or move a menu, and now the video shows something that doesn't exist. You either re-record, or you leave an outdated video up and hope nobody notices. Usually it's the second.
This is why I think a lot of teams quietly give up on demos after the first few. The cost isn't just making the video once. It's making it again every time the product changes. That repeat cost is the main argument for making product videos from code instead of screen recordings, which I'll come back to below.
What actually helps
Here are habits that help, whatever tools you use.
Write the story before you touch the app
Before recording anything, write three lines:
- Who is this for?
- What were they doing before this feature existed?
- What is the one moment that shows the feature working?
That third line is your video. Everything else is setup. If you can't write it down, a recording won't fix it.
Keep it short and about one thing
In my view, a demo for a single feature should usually be under a minute or two. One feature, one flow, one result. If you need to show five things, make five videos. Short videos are also much easier to keep current, because when one screen changes you only redo one of them.
Use sample data on purpose
Make a seed script or a demo account with believable data: realistic names, realistic numbers, nothing private. You'll reuse it for every demo, screenshot and docs page. It's a small piece of work that saves you from blurring things out later.
Separate the script from the footage
If the voiceover and the visuals are recorded together, any change means redoing both. Write the script as text first. Then the visuals can be redone without re-recording your voice, and the voice can be fixed without touching the visuals.
Plan for every format at the start
If you know you need a vertical version, design for it from the start. Cropping a 16:9 recording to 9:16 almost always cuts off the thing you're trying to show.
Treat demos like code that needs maintenance
This is the mindset shift that matters most, in my opinion. A demo is not a one off asset. It's tied to your product the same way docs are. When a release changes a screen, the demo for that screen should be on the list, the same way a docs update would be.
If that sounds like too much work, it's a sign the way you make demos is too expensive to repeat.
Where DemoVexa fits
That last point is the idea behind DemoVexa, product demo video software built around rebuilding a video after a release instead of re-recording it. It's a desktop app (and a CLI) that reads your code and docs, writes a script, adds a voiceover, and rebuilds your UI as animated React components instead of recording the screen. Since version 0.3.5 it can also start from a product's website and uploaded documents, though screens recreated that way are less exact than when it reads the code. When the product changes, you rebuild the video from the latest code.
I'm not saying you need a tool for this. The habits above work with a plain screen recorder too. The point is that the cost of a demo has to be low enough that you'll actually make the next one.
A quick checklist for your next feature
- [ ] Three lines written: who, before, the one moment
- [ ] Demo account or seed data ready, nothing private on screen
- [ ] Script written as text before recording
- [ ] Under two minutes, one feature only
- [ ] Formats decided up front (16:9, 9:16, 1:1)
- [ ] Added to the "update when this screen changes" list
If your team has a way of keeping demos current that works, I'd like to hear it in the comments.
If you want to see what rebuilding a demo from code looks like, DemoVexa has a 14 day free trial, no card needed.
FAQ
Why do product demo videos go out of date so quickly?
A screen recording captures the UI exactly as it was on the day you recorded it. Any renamed button, moved menu or changed flow makes the video show something users can't find. Unless updating demos is part of the release routine, old videos tend to stay up.
How long should a single feature demo be?
There's no fixed rule. In my view, one feature should usually fit in under a minute or two, showing one flow and one result. If you need longer, it's often a sign the video covers more than one feature.
Do I have to record my own voice for a product demo?
No. You can record yourself, use a text to speech voice, or skip narration and rely on captions and music. Whichever you pick, writing the script as text first makes it easier to change later.
Can I just crop a 16:9 demo into a vertical video?
You can, but cropping a wide recording to 9:16 usually cuts off part of the screen you're trying to show. A vertical version works better when each scene is laid out for the taller frame, with the important part of the screen larger and centred.
Is there a way to make a demo video without screen recording?
Yes. Some tools rebuild the interface instead of capturing it. DemoVexa, for example, reads your app's code and recreates the screens as animated React components with sample data, so there is no recording step. The FAQ on making demo videos from code covers requirements and pricing.
Top comments (0)