DEV Community: DemoVexa

How to Demo a Developer Tool, CLI or API on Video

DemoVexa — Sat, 17 Oct 2026 06:00:40 +0000

Developer products are hard to show because the interesting part is often invisible. Here's how to make terminals, code and API calls readable on video, and what developers actually want to see.

A SaaS dashboard is easy to put on video. There are buttons, charts and something to click. A CLI, an SDK or an API is harder. The product is a command, a few lines of code or a JSON response, and the useful part (what it saves you from doing) doesn't appear on screen at all.

This post covers how to plan and lay out a demo for a developer product so it's readable, honest and short.

Disclosure: I build DemoVexa, a tool that can turn your code into product demo videos. Most of this post is about planning and readability, which applies whatever you use.

Key takeaways

Show the problem, the smallest working example and the result. Developers care about how few steps it takes.
Terminal and code text must be readable on a phone: large font, short lines, and only the lines that matter.
Show real commands and real output shapes, using sample data. Don't fake output your tool can't produce.
Pair the video with copyable code in the post or README, because nobody can copy text out of a video.

Key takeaways
What do developers want to see in a demo?
How do you structure a developer tool demo?
How do you make terminal and code text readable?
How do you show an API, which has no UI?
Should you record your terminal or animate it?
What should go in the post or README alongside the video?
A few common mistakes
FAQ

What do developers want to see in a demo?

Developers watching a demo are usually asking a few practical questions:

How do I install it? One command, or a long setup?
What's the smallest thing that works? The "hello world" of your tool.
What does the output look like? Real shapes, real errors, real formats.
How does it fit my stack? Language, framework, CI, editor.
What does it replace? The script or manual step they do today.

A good developer demo answers three or four of these and skips the marketing.

How do you structure a developer tool demo?

A simple structure that works for most CLIs, SDKs and APIs:

Part	What's on screen	Rough share of the video
The problem	The manual way, or the error people hit today	10 to 15%
Install or setup	One command or one config block	10 to 15%
The smallest example	The core command or a few lines of code	30 to 40%
The result	Output, a file created, a dashboard updated	20 to 30%
Where to go next	Docs link, repo, a more advanced example	5 to 10%

Keep it short. A 60 to 90 second demo of one task usually beats a ten minute tour.

How do you make terminal and code text readable?

Most developer demos fail on readability, not content. Text that's fine on your monitor is unreadable on a phone or in a small embedded player.

Large font. Bigger than you think. Test by watching the video on your phone.
Short lines. Wrap long commands, or use shorter example paths and names.
Fewer lines. Show the five lines that matter, not the whole file.
Highlight the change. When one line matters, highlight or zoom on it.
High contrast. A plain dark or light theme, not a busy custom one.
Slow typing, or none. Real typing speed is too fast to follow. Either type slowly or show the command appearing line by line.

How do you show an API, which has no UI?

An API demo needs something visible on both sides of the call. Common options:

Request and response side by side. The request on the left, the formatted JSON response on the right.
Code, then effect. A few lines of SDK code, then the thing it changes, such as a record appearing in a dashboard.
A sequence diagram. For flows like authentication, a simple animated diagram of who talks to whom.

Use sample keys and sample data. Never show real tokens, even expired ones. The API authentication demo guide on the DemoVexa blog goes deeper into showing auth flows without exposing secrets.

Should you record your terminal or animate it?

Both are reasonable, and the choice depends on the tool:

Record when the real behaviour is the point: timing, streaming output, an interactive prompt.
Use a terminal recorder that saves text rather than pixels when you want sharp, resizable output for docs.
Animate when you want a polished, narrated video that matches a script line by line and survives UI or output changes.

For animated videos, some tools turn your code into product demo videos instead of recording anything. For a developer product, that means recreating the terminal and output as animated scenes with sample data, then timing them to a voiceover. The tradeoff is that the output on screen is a recreation, so check that it matches what your tool really prints.

There's a longer walkthrough of how to make a demo video for a CLI tool on the DemoVexa blog.

What should go in the post or README alongside the video?

The video gets attention. The text gets people to actually try it. Next to the video, include:

The install command as a copyable code block.
The smallest working example from the video, exactly as shown.
A link to the full docs.
Version numbers for anything version sensitive.

A few common mistakes

Starting with the architecture instead of the result.
Using a real project with long, messy paths on screen.
Showing output your tool doesn't actually produce, or hiding errors it does produce.
Talking over a silent, static terminal for 20 seconds.
Forgetting that viewers can't copy anything from a video.

FAQ

How long should a developer tool demo video be?

For one task, 60 to 90 seconds is usually enough. Longer tutorials work on YouTube or in docs, but a short demo of the core workflow is better for a README or landing page.

How do I make terminal text readable in a demo video?

Use a large font, a high contrast theme and short lines, and show only the lines that matter. Watch the result on a phone before publishing.

How do you demo an API that has no user interface?

Show the request and response side by side, or a few lines of SDK code followed by the visible effect. For auth flows, an animated sequence diagram can explain who talks to whom.

Should I show real API keys in a demo?

No. Use sample or obviously fake keys and sample data, even if a real key is expired or scoped.

How to Make a Product Demo Video with Remotion (and When Not to Build It Yourself)

DemoVexa — Sat, 17 Oct 2026 05:57:26 +0000

Remotion lets you write videos as React components. Here's how a product demo maps onto it, what the hard parts are, and what to check in the license before you start.

If you build a React app, there's an appealing idea: why not make the product demo in React too? Your components already exist. Remotion is a framework that renders React components frame by frame into video, so in principle you can reuse your UI, animate it and export an MP4.

That idea works. It's also more work than it first looks. This post walks through how a demo maps onto Remotion, the parts that take the most time, and when it makes sense to use a tool instead of writing it all yourself.

Disclosure: I build DemoVexa, which is product demo video software that writes the Remotion code for you. Everything in the first part of this post applies whether you use it or not.

Key takeaways

Remotion renders React components into video, so a product demo becomes a set of components animated over time.
The hard parts are not rendering. They're the story, recreating screens with sample data, and timing animation to narration.
Check Remotion's license: it's free for individuals and for profit companies with up to 3 employees, and larger companies need a Company License.
Build it yourself for full control. Use a tool if you want the script, voice and timing handled for you.

Key takeaways
How does a demo map onto Remotion?
Can you reuse your real components?
What are the hard parts?
What should you check in the license?
When does it make sense to build it yourself?
What does a tool add on top of Remotion?
FAQ

How does a demo map onto Remotion?

In Remotion, a video is a React component that receives the current frame. You decide what's on screen at each frame. A demo usually breaks down like this:

A composition for the whole video, with a width, height, frame rate and duration.
A sequence per scene, placed at a start frame with a length.
Screen components that look like your app: a sidebar, a table, a form.
Animation helpers that move a cursor, type text or highlight a button based on the frame.
Audio for narration and music.

A minimal scene might look like this:

import { AbsoluteFill, Sequence, useCurrentFrame, interpolate } from "remotion";

export const Demo = () => (
  <AbsoluteFill>
    <Sequence from={0} durationInFrames={90}>
      <InvoicesScene />
    </Sequence>
  </AbsoluteFill>
);

const InvoicesScene = () => {
  const frame = useCurrentFrame();
  const opacity = interpolate(frame, [0, 15], [0, 1]);
  return <div style={{ opacity }}>{/* your invoices table */}</div>;
};

You preview it in Remotion's studio in the browser and render with the Remotion CLI.

Can you reuse your real components?

Sometimes, but often not directly. Real components tend to depend on things a video doesn't have:

Dependency	Why it's a problem in a video	Common fix
API calls and data fetching	No backend while rendering	Pass sample data as props
Auth and user context	No logged in user	Wrap in a fake provider
Global CSS and theme setup	Styles may not load the same way	Import the theme into the video project
Animation libraries tied to real time	Remotion renders by frame, not by clock	Drive animation from the current frame
Browser only APIs	Rendering happens in a headless browser, but some APIs still behave differently	Stub them in the video project

Many people end up writing simplified "video versions" of their screens that look the same but take plain props. That's fine, and it's often faster than making real components render cleanly outside the app.

What are the hard parts?

Rendering is the easy part. The time goes into:

The story. Deciding which screens to show, in what order, and why. No framework helps here.
Sample data. Believable names and numbers for every table and chart.
Timing to narration. If there's a voiceover, each click and caption should land on the right word. That means knowing where each word starts in the audio and converting it to frames.
Formats. A 16:9 layout doesn't work as 9:16. Each format needs its own arrangement.
Maintenance. When the real UI changes, the video version of each screen has to change too.

What should you check in the license?

Remotion is not MIT licensed. According to its license page (checked October 2026), the Free License covers individuals, for profit organisations with up to 3 employees, non profits, and evaluation before commercial use, and it allows commercial videos. Other companies need a Company License, sold through remotion.pro. The page also notes that the license will change slightly in Remotion 5.0, and it has an FAQ for edge cases. Read the current terms before you build anything for a company.

When does it make sense to build it yourself?

Building a demo in Remotion yourself makes sense when:

You want full control over every frame and animation.
You'll make a small number of videos and maintain them like code.
You have someone who enjoys this kind of work and has time for it.

It makes less sense when you need many videos, several languages, or frequent updates, and nobody has time to keep the video project in sync with the app.

What does a tool add on top of Remotion?

Some tools use Remotion underneath and automate the parts above. DemoVexa is one: it's product demo video software that writes the Remotion code for you. Claude reads your app's code, writes the script, and a build agent recreates your screens in React and animates them with Remotion, timing each move to the voiceover. You review the brief, script and scene plan instead of writing components.

FAQ

What is Remotion?

Remotion is a framework for making videos with React. You write components that render based on the current frame, preview them in a browser studio and render them to video files.

Is Remotion free to use?

According to Remotion's license page, it's free for individuals, for profit organisations with up to 3 employees, non profits and evaluation, including commercial videos. Other companies need a Company License. Check the current terms, since the page says they change slightly in Remotion 5.0.

Can I use my app's real React components in a Remotion video?

Sometimes. Components that fetch data, need a logged in user or animate on real time usually need sample data props, fake providers or frame based animation before they render cleanly in a video.

Do I need to know Remotion to make code-generated demo videos?

Not with every tool. In DemoVexa, Claude builds the video in React with Remotion, and you change it by editing the brief and script or by asking for the change in plain words. The DemoVexa FAQ on making demo videos from code covers what else you need.

Screen Recorder or Code-Generated Demo: Which Should You Use?

DemoVexa — Thu, 15 Oct 2026 17:53:06 +0000

An honest side by side of recording your screen and rebuilding your UI from code, with the cases where each one is the better choice.

There are now two very different ways to make a product demo video. You can record your screen while you use the app, or you can have a tool rebuild the app's screens from its source code and animate them. Both produce an MP4. They get there in completely different ways, and that changes what each one is good at.

This isn't a post that ends with "always use code". Screen recorders are the right tool for a lot of jobs. The goal is to make the choice on purpose.

Disclosure: I make DemoVexa, which is demo video software that rebuilds your UI from code, so I have a side in this. I've tried to be fair about where a screen recorder is the better choice.

Key takeaways

Screen recorders capture exactly what's on screen, quickly, with almost no setup.
Code-generated demos rebuild the UI from source, which makes them easier to update and keeps real data off screen.
Recorders win for quick, informal and one off videos. Code-generated demos win for videos you'll keep and update.
Many teams will use both, for different kinds of video.

Key takeaways
How does each approach work?
How do they compare side by side?
When is a screen recorder the better choice?
When is a code generated demo the better choice?
What does each one cost you?
Where does DemoVexa sit?
A simple way to decide
FAQ

How does each approach work?

A screen recorder captures pixels from your display, usually with your voice and sometimes your webcam. What you do is what the viewer sees. Tools range from the recorder built into your operating system to dedicated apps with editing, captions and sharing.

A code-generated demo starts from the product's code. A tool reads it, writes or takes a script, adds a voice, and recreates the screens as animation. Nothing is captured from a display. The output looks like the app because it's built from the same components, labels and styles.

How do they compare side by side?

	Screen recorder	Code-generated demo
Setup	Install and press record	Point the tool at the code, write a brief
First video	Minutes, if the take goes well	Longer, because it builds the scenes
What's on screen	Whatever was on your screen	Recreated screens with sample data
Mistakes in a take	Re-record or edit around them	Fix the script or scene plan and rebuild
After a UI change	Record again	Rebuild from the latest code
Sharpness	Depends on your display and zoom	Drawn at the output size
Live behaviour	Shows real responses and real data	Shows a recreation, not live responses
Your face on camera	Usually supported	Usually not the point
Skills needed	Presenting, editing	Reviewing a script and scenes

Neither column is better everywhere. The rows that matter depend on the video you're making.

When is a screen recorder the better choice?

Quick, informal videos. Explaining a bug to a teammate, answering a support question, giving feedback on a design.
Anything with your face. A founder update or a personal sales follow up works better with a real person on camera.
Live behaviour. If the point is that a real integration responds, or real data loads, a recording shows that honestly.
One off videos. If nobody will watch it after this week, the update cost doesn't matter.
No access to the code. If you can't get the code or a good description of the product, recording is the practical option.

When is a code generated demo the better choice?

Videos you'll keep. Landing page demos, docs videos and onboarding clips stay useful for months, so the cost of updating them matters most.
Products that change often. If the UI changes every few weeks, rebuilding from code is easier than re-recording.
Several formats. When you need 16:9, 9:16 and 1:1, a tool that lays out each format separately avoids awkward crops.
Several languages. Rewriting a script and voice per language is easier than recording a person in each one.
Privacy. When your real environment holds customer data you can't show, recreated screens with sample data avoid the problem.

What does each one cost you?

Not in money, which varies by tool, but in time and attention:

Screen recording costs most in the recording and editing session, and again every time the product changes.
Code-generated demos cost most in setup and review: pointing the tool at the right code, reading the script, checking the scene plan and the final video.

If a video will be redone many times, the second pattern usually ends up cheaper. If it's made once, the first one usually is.

Where does DemoVexa sit?

DemoVexa is product demo video software that rebuilds your UI from code instead of recording it. It's a desktop app for macOS, Windows and Linux, with a CLI. It reads a local code folder, Claude writes the script, ElevenLabs can voice it (or you record your own voice, or use captions only), and the screens are recreated as animated React components and rendered as MP4s in 16:9, 9:16 and 1:1. The page on why it makes videos from code instead of screen recordings explains the reasoning in more detail.

It's not a screen recorder, and it doesn't try to replace one for quick, personal videos.

A simple way to decide

Ask two questions about the video:

Will anyone still watch it in three months?
Will the screens it shows change before then?

If both answers are yes, a code-generated demo is worth trying. If either answer is no, a screen recorder is probably the faster choice.

FAQ

Is a code-generated demo better than a screen recording?

Not in general. It's better for videos you'll keep and update, and for avoiding real data on screen. A screen recording is better for quick, personal and one off videos, and for showing live behaviour.

Can I use both approaches in the same product?

Yes. A common split is code-generated demos for landing pages, docs and launches, and screen recordings for support replies, internal updates and anything with a person on camera.

Do code-generated demos look like the real app?

They're built to. Because they use the app's own labels, layout and styles, they look like the product, but they're a recreation, so it's worth comparing them to the real app before publishing.

What do I need to make a code-generated demo with DemoVexa?

A copy of the code on your computer (or the product's website and documents), Claude Code with a Claude Pro or Max plan or an Anthropic API key, and optionally an ElevenLabs key for AI voices. The page on requirements for making demo videos from code lists them in full.

Why Most Features Ship Without a Demo Video (and What Actually Helps)

DemoVexa — Thu, 15 Oct 2026 17:36:53 +0000

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.

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.

Treat Your Demo Environment Like a Test Fixture

DemoVexa — Thu, 15 Oct 2026 15:11:46 +0000

When a feature demo takes far more takes than it should, the cause is often the app, not the person recording it. A toast from a background job slides in. A table sorts differently than it did last time. A timestamp says "3 minutes ago" in one take and "11 minutes ago" in the next. A dev overlay sits in the corner of every frame.

Developers already know this kind of problem. It's the same thing that makes tests flaky: state you don't control. So the fix is the same too. Treat the demo environment like a test fixture: known data, a known starting point, and nothing that changes between runs.

This post is about that setup. It helps a lot if you record your screen, and most of it still helps if you create demo videos from code instead.

Key takeaways

Most demo retakes come from app state you don't control, the same thing that makes tests flaky.
A seed script plus a reset command means every take starts from exactly the same state.
Fixed dates, a fixed clock, a production build and a fixed window size remove most surprises on screen.
Demo the feature flags your users actually have, and check the flow with a scripted walk through before recording.

Key takeaways
What "deterministic" means for a demo
1. A seed script you can run in one command
2. A reset command
3. Pin the screen
4. Freeze time and quiet the background
5. Match feature flags to what users will see
6. Check it like a test
If you don't record at all
FAQ

What "deterministic" means for a demo

A test is deterministic when the same input gives the same output every run. For a demo, that means the same data, the same screen and the same timing every time. Things that commonly break it:

Relative times ("2 hours ago") and today's date
Random IDs, avatars or colours generated per user
Sort orders that depend on when rows were inserted
Background jobs, websockets and polling that push updates mid take
Feature flags that differ between your machine and production
UI that only exists in development: error overlays, devtools buttons, debug banners

Click through your flow once and write down every one of these you see. That list is your to do list for the rest of this post.

Here's how each one maps to a fix covered below:

Source of flakiness	Fix
Relative times and today's date	Fixed demo day in the seed data, plus a fixed clock
Random IDs, avatars or colours	Fixed values in the seed script
Insert order sorting	Explicit positions or created dates
Background jobs, websockets, polling	A demo mode that turns live updates off
Flags that differ from production	Flag values checked in with the demo config
Development only UI	A production build run locally

1. A seed script you can run in one command

Create the demo data in code, not by clicking around in the app. A seed script is reviewable, repeatable and safe to commit, as long as it holds no real customer data.

// scripts/seed-demo.js
const DEMO_DAY = new Date("2026-03-02T10:00:00Z");

const companies = [
  { name: "Northwind Studio", plan: "Team", seats: 12 },
  { name: "Harbor and Pine", plan: "Solo", seats: 1 },
  { name: "Lumen Labs", plan: "Team", seats: 8 },
];

function daysBefore(days) {
  return new Date(DEMO_DAY.getTime() - days * 86400000);
}

A few rules that make seed data look right on camera:

Believable names. "Test Co" and "asdf" pull attention away from the feature. Made up but plausible names don't.
Fixed dates. Build every date from one fixed demo day, so "last week" means the same thing every time you run it.
Stable order. Give rows explicit positions or created dates, so lists don't reshuffle between takes.
Nothing real. No customer names, emails or internal URLs, even ones that look harmless.

2. A reset command

The seed script gets you a good starting state once. The reset command gets you back to it after every take.

{
  "scripts": {
    "demo:reset": "node scripts/reset-demo.js && node scripts/seed-demo.js"
  }
}

Scope the reset to a demo account or tenant, and make it refuse to run against production. The whole point is that take two starts exactly like take one, without you undoing by hand whatever the last take changed.

3. Pin the screen

Run a production build locally. Development builds often show framework overlays and indicators. A production build looks like what users see.
Fix the window size. If you automate the flow with Playwright, set the viewport in the config. If you click by hand, keep one browser profile just for demos: no extensions, no bookmarks bar, no personal logins.
Pick one zoom level and keep it for every scene and every video.
Quiet the OS. Turn on Do Not Disturb or Focus, close chat apps, and hide anything on the desktop.

4. Freeze time and quiet the background

Relative timestamps are the classic flaky demo problem. If you drive the flow with Playwright, its clock API can pin the time:

await page.clock.setFixedTime(new Date("2026-03-02T10:00:00Z"));

If you click by hand, add a demo mode to the app that reads a fixed "now" from an environment variable. While you're there, turn off the things that push surprise updates into the frame:

if (process.env.DEMO_MODE === "1") {
  // fixed clock, no live updates, no onboarding tours
}

Stub slow third party calls with fixed responses too, so a spinner never hangs in the middle of a scene.

5. Match feature flags to what users will see

Demo the state your users actually get. If a flag is on locally but off for customers, the video promises something they can't find. Write the flag values the demo depends on into the demo config, so they're checked in next to the seed data and not living in someone's local settings.

6. Check it like a test

Before you record, walk the flow once with a script. A short Playwright test that clicks through each step and takes a screenshot will catch most surprises: a missing row, a wrong label, a banner you forgot about. Playwright can also record video of a test run, which is meant for debugging, so check whether the quality is good enough for your use before you rely on it.

A short checklist for the day you record:

[ ] npm run demo:reset ran without errors
[ ] Production build, fixed window size, one zoom level
[ ] Clock fixed, live updates off
[ ] Flags match production
[ ] Screenshot walk through looked right

If you don't record at all

Some tools skip screen capture entirely. DemoVexa is one of them: it reads your code and rebuilds the screens as animated React components with sample data, so there's no recording session to stabilise. I wrote a separate guide on creating software demo videos without screen recording on the DemoVexa blog, which covers that workflow from planning to export.

The fixture mindset still applies there. Clear, consistent labels in your UI, realistic sample data and docs that describe each task in order make any demo easier to get right, whether a person or a tool is putting it together.

What usually breaks your demo takes? I'm curious which items people would add to the list above.

FAQ

How do I make demo data look realistic?

Create it with a seed script instead of by hand. Use plausible made up names and numbers, build every date from one fixed demo day, and give rows a fixed order. Keep real customer names, emails and internal URLs out of it completely.

How do I stop timestamps changing between demo takes?

Fix the clock. If you drive the flow with Playwright, page.clock.setFixedTime() pins the time the page sees. If you click by hand, add a demo mode to your app that reads a fixed "now" from an environment variable.

Should I record a demo on a development build or a production build?

A production build, run locally against your demo data. Development builds often show framework overlays, indicators and debug UI that users never see.

Can Playwright record video of a test run?

Yes. Playwright can save a video of each test run, set through the video option in its config or the recordVideo option when creating a browser context. It's designed for debugging, so check whether the quality suits your use before relying on it for a public demo.

How do I keep customer data out of a product demo video?

Use a separate demo account or tenant filled only by your seed script, and check every screen before you record. Tools that rebuild the UI rather than recording it, such as DemoVexa, show sample data instead of your real customers.

DEV Community: DemoVexa

How to Demo a Developer Tool, CLI or API on Video

Key takeaways

Contents

What do developers want to see in a demo?

How do you structure a developer tool demo?

How do you make terminal and code text readable?

How do you show an API, which has no UI?

Should you record your terminal or animate it?

What should go in the post or README alongside the video?

A few common mistakes

FAQ

How long should a developer tool demo video be?

How do I make terminal text readable in a demo video?

How do you demo an API that has no user interface?

Should I show real API keys in a demo?

How to Make a Product Demo Video with Remotion (and When Not to Build It Yourself)

Key takeaways

Contents

How does a demo map onto Remotion?

Can you reuse your real components?

What are the hard parts?

What should you check in the license?

When does it make sense to build it yourself?

What does a tool add on top of Remotion?

FAQ

What is Remotion?

Is Remotion free to use?

Can I use my app's real React components in a Remotion video?

Do I need to know Remotion to make code-generated demo videos?

Screen Recorder or Code-Generated Demo: Which Should You Use?

Key takeaways

Contents

How does each approach work?

How do they compare side by side?

When is a screen recorder the better choice?

When is a code generated demo the better choice?

What does each one cost you?

Where does DemoVexa sit?

A simple way to decide

FAQ

Is a code-generated demo better than a screen recording?

Can I use both approaches in the same product?

Do code-generated demos look like the real app?

What do I need to make a code-generated demo with DemoVexa?

Why Most Features Ship Without a Demo Video (and What Actually Helps)

Key takeaways

Contents

A "quick demo" is five jobs

The screen recording trap

What actually helps

Write the story before you touch the app

Keep it short and about one thing

Use sample data on purpose

Separate the script from the footage

Plan for every format at the start

Treat demos like code that needs maintenance

Where DemoVexa fits

A quick checklist for your next feature

FAQ

Why do product demo videos go out of date so quickly?

How long should a single feature demo be?

Do I have to record my own voice for a product demo?

Can I just crop a 16:9 demo into a vertical video?

Is there a way to make a demo video without screen recording?

Treat Your Demo Environment Like a Test Fixture

Key takeaways

Contents

What "deterministic" means for a demo

1. A seed script you can run in one command

2. A reset command

3. Pin the screen

4. Freeze time and quiet the background

5. Match feature flags to what users will see

6. Check it like a test

If you don't record at all

FAQ

How do I make demo data look realistic?

How do I stop timestamps changing between demo takes?

Should I record a demo on a development build or a production build?