Key takeaways

• Use a schedule trigger plus workflow_dispatch, so you can run the same job by hand.
• A concurrency group stops a slow night from overlapping with the next one.
• Retry only the steps that fail for outside reasons, like a voiceover API timeout. Never retry the render itself blindly.
• Set retention-days on artifacts. Video adds up fast.

Contents

• Why render demos at night at all?
• What does the workflow look like?
• How do you stop runs from overlapping?
• Which steps should retry?
• Where should the videos go?
• FAQ

Why render demos at night at all?

Because rendering is slow and nobody needs the result in the next five minutes. A pull request check should stay fast. A demo render pulls fonts, starts a browser or a renderer, generates audio and encodes video, so it belongs in a job that runs once a day against the default branch.

The other reason is drift. If the UI changed today, tonight's render shows it. You find out the demo is stale from a diff, not from a prospect.

What does the workflow look like?

Here is a trimmed version of the file I use:

name: nightly-demo-renders

on:
  schedule:
    - cron: "30 21 * * 1-5"   # 21:30 UTC on weekdays
  workflow_dispatch:

concurrency:
  group: nightly-demo-renders
  cancel-in-progress: false

jobs:
  render:
    runs-on: ubuntu-latest
    timeout-minutes: 90
    strategy:
      fail-fast: false
      max-parallel: 2
      matrix:
        demo: [onboarding, release-notes, cli-quickstart]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - name: Generate voiceover
        run: ./scripts/retry.sh 3 npm run voiceover -- --demo ${{ matrix.demo }}
      - name: Render
        run: npm run render -- --demo ${{ matrix.demo }}
      - uses: actions/upload-artifact@v4
        with:
          name: demo-${{ matrix.demo }}
          path: out/${{ matrix.demo }}.mp4
          retention-days: 14

A few notes on the choices:

1. Cron is in UTC. Write the local time in a comment, or you will misread it in six months.
2. Scheduled runs can start late. GitHub says scheduled workflows may be delayed at busy times, and the top of the hour is the busiest. I use minute 30 for that reason.
3. Scheduled runs only use the default branch. Changing the cron on a feature branch does nothing until it merges.
4. fail-fast: false means one broken demo doesn't cancel the others.

How do you stop runs from overlapping?

Use a concurrency group. With cancel-in-progress: false, a new run waits for the current one to finish instead of killing it.

For renders I want the queue. A cancelled run halfway through an encode leaves nothing useful.

Which steps should retry?

Only the ones that fail for reasons outside your code. In a demo pipeline that usually means:

• Text to speech calls that time out or hit a rate limit
• Downloading fonts, models or other assets
• Uploading the finished file to storage

GitHub Actions has no built-in retry for a step, so I use a small script:

#!/usr/bin/env bash
# usage: retry.sh <attempts> <command...>
n=$1; shift
for i in $(seq 1 "$n"); do
  "$@" && exit 0
  echo "attempt $i failed"; sleep $((i * 20))
done
exit 1

The render step does not retry. If a render fails, something in the code, the script or the selectors changed, and I want that failure in front of me the next morning.

Also set timeout-minutes on the job. The default is 360 minutes, and a renderer stuck on a frame will happily burn all of it.

Where should the videos go?

Artifacts are fine for review. They are tied to the run and expire after the retention period, which is what you want for nightly output. Use retention-days to keep them short; the repository or organization setting caps how long they can live.

For files that ship, such as the clip on a release page, copy them to proper storage with a stable name. I keep nightly artifacts for two weeks and only publish a render after someone has watched it.

I wrote more about the planning side, including what to render each night and how to review it, in batch rendering demo videos overnight. If you want the render command itself without building the pipeline, the DemoVexa CLI for code-to-video demos is what I built for exactly this job.

FAQ

Can I trigger the nightly job by hand?

Yes. Add workflow_dispatch under on, and a "Run workflow" button appears on the Actions tab for that workflow.

Why didn't my scheduled workflow run?

Check that the file is on the default branch. In public repositories, GitHub also disables scheduled workflows after 60 days with no repository activity.

Should every demo render in parallel?

Not always. Renders are CPU heavy and may share API limits for voiceover. max-parallel lets you cap how many matrix jobs run at once.

How long should I keep nightly videos?

Long enough to compare against the last few nights. Two weeks works for me; set it with retention-days.

Baltej Singh is the founder of DemoVexa, a desktop app and CLI that turns a local codebase into narrated product demo videos. He writes from Delaware, USA.

Key takeaways

• The script is better caption text than a transcript, because product names are already spelled right.
• WebVTT is strict about the WEBVTT header, blank lines between cues, and a period before milliseconds.
• One audio clip per script line, measured with ffprobe, is a simple and reliable timing source.
• CI should fail on overlapping cues, long lines and misspelled product names, not only on syntax.

Contents

• Why build captions from the script instead of the audio?
• What does a valid WebVTT file look like?
• Where do the cue timings come from?
• What should CI check before accepting the file?
• How do you wire it into GitHub Actions?
• FAQ

Why build captions from the script instead of the audio?

Because the script is the source of truth and transcription is a guess. Speech recognition is weakest on the words you care about most: product names, API names and button labels. The script has them right. Only timing is missing, and timing is the easier problem.

When narration changes in a pull request, the captions change in the same commit.

What does a valid WebVTT file look like?

A WebVTT file is UTF-8 text that starts with WEBVTT, followed by cues separated by blank lines.

WEBVTT

intro-1
00:00:00.000 --> 00:00:03.200
Open Settings and choose Billing.

Each cue has an optional identifier, a timing line and one or more lines of text. Hours are optional, and the cue text can't contain the timing arrow. Escape &, < and > as entities. The differences from SRT cause most conversion bugs:

Where do the cue timings come from?

The simplest reliable source is one audio clip per script line. Each clip's duration gives the cue length, and a fixed pause between clips gives the gap. Many text-to-speech APIs can also return word timings.

Here is the per-line version, reading demo/script.json, a list of { id, text, audio } objects:

import { readFileSync, writeFileSync, mkdirSync } from "node:fs";
import { execFileSync } from "node:child_process";

const lines = JSON.parse(readFileSync("demo/script.json", "utf8"));
const GAP = 0.2; // seconds between clips
const duration = (f) => Number(execFileSync("ffprobe", ["-v", "error",
  "-show_entries", "format=duration", "-of", "csv=p=0", f], { encoding: "utf8" }));
const ts = (s) => new Date(Math.round(s * 1000)).toISOString().slice(11, 23);
const esc = (t) => t.replace(/&/g, "&amp;").replace(/</g, "&lt;").replace(/>/g, "&gt;");

let t = 0, out = "WEBVTT\n";
for (const l of lines) {
  const d = duration(l.audio);
  out += `\n${l.id}\n${ts(t)} --> ${ts(t + d)}\n${esc(l.text)}\n`;
  t += d + GAP;
}
mkdirSync("dist", { recursive: true });
writeFileSync("dist/demo.en.vtt", out);

The toISOString trick formats times as HH:MM:SS.mmm for videos under 24 hours. This only works if the video is assembled with the same gap, so keep GAP in a config both steps read.

What should CI check before accepting the file?

Valid WebVTT can still be bad captions. My check script fails the build when:

1. The first line is not WEBVTT.
2. A cue ends before it starts, or overlaps the next one.
3. A cue is shorter than one second.
4. A line exceeds 42 characters, or a cue has more than two lines. That is my house rule, close to common broadcast guidance.
5. A product name from a glossary file appears with different capitalization, such as "Add Seat" when the button says "Add seat".
6. The last cue ends after the rendered video does.

How do you wire it into GitHub Actions?

Run both scripts on pull requests that touch the demo.

name: captions
on:
  pull_request:
    paths: ["demo/**"]
jobs:
  vtt:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: sudo apt-get update && sudo apt-get install -y ffmpeg
      - run: node scripts/build-vtt.mjs && node scripts/check-vtt.mjs
      - uses: actions/upload-artifact@v4
        with:
          name: captions
          path: dist/*.vtt

If audio is in Git LFS, set lfs: true on checkout, or ffprobe reads pointer files. On the page, attach the file with a <track kind="captions"> element, served as text/vtt.

In DemoVexa, I took a different route: captions come from the same Script step as the voiceover and export as SRT or VTT, as the FAQ on caption and video export formats lists. The pipeline above is what I'd build when narration lives elsewhere. Then read why uploading SRT and VTT subtitles helps YouTube index your demo.

FAQ

Can I convert an SRT file to WebVTT?

Yes. ffmpeg -i in.srt out.vtt adds the header and switches the comma before milliseconds to a period.

Why doesn't my track show in the browser?

Check that the file starts with WEBVTT and is served as text/vtt. Cross-origin files also need CORS headers and crossorigin on the video.

Should captions match the narration word for word?

For a scripted demo, yes. Viewers notice when captions and voice disagree.

What about other languages?

Build one file per translated script, such as demo.de.vtt, each with its own <track> and srclang.

Baltej Singh is the founder of DemoVexa, a desktop app and CLI that turns a local codebase into narrated product demo videos. He writes from Delaware, USA.

A small group of tools now make product demo videos from code rather than from someone clicking through the app with a screen recorder. If you're a developer looking at them, the useful question isn't "which is best" but "which one starts from what I already have".

Disclosure first: I make DemoVexa, one of the three. I've tried to describe the other two accurately from their own websites and repositories (checked October 2026) and to say where each one is a better fit. Features change quickly in this space, so check each tool's site before deciding.

Key takeaways

• DemoVexa reads a local code folder and recreates the UI as animation. It's a desktop app and CLI.
• PushPlay works from GitHub. It watches merged pull requests and renders the changed screens from React components.
• Screenwright works from Playwright tests. It records your real running app, then adds cursor animation and voiceover.
• Choose by your starting point: a local folder, a GitHub workflow, or an existing Playwright test suite.

Contents

• Key takeaways
• What does each tool start from?
• How does DemoVexa work?
• How does PushPlay work?
• How does Screenwright work?
• Recreated UI or recorded UI?
• How should you choose?
• FAQ

What does each tool start from?

How does DemoVexa work?

According to its FAQ, you point a workspace at a local code folder, write a brief or let Claude draft one, Claude writes the script, ElevenLabs voices it, and Claude builds the video in React with Remotion. It doesn't take a GitHub URL; you clone the repo first. Since version 0.3.5 a workspace can also come from the product's website and uploaded documents, with less exact screens. Claude is billed by Anthropic on your own account, and ElevenLabs is optional. More detail is on the site for the desktop app that turns a local code folder into product demo videos.

Good fit if you want marketing style videos (intros, feature demos, launches) in several formats and languages from a local codebase, without connecting a Git host.

Less good fit if you want videos generated automatically on every merge, or a recording of exactly what the live app does.

How does PushPlay work?

According to PushPlay's website, you sign in with GitHub, paste a public repository URL or install its GitHub App on a private repository, and PushPlay indexes your components. When a pull request merges, it reads the diff, writes a script with one scene per user facing change, voices it and renders the changed screens from your React components with your colours and fonts. It produces a 1080p MP4, a shareable page and a comment on the PR. Its site says the Pro plan can generate a video on every merge automatically.

Good fit if your product is built with React, your team works in GitHub, and you want changelog or client update videos tied to each PR.

Less good fit if your UI isn't React, or you'd rather not connect a Git host.

How does Screenwright work?

Screenwright's GitHub README describes an open source CLI that turns Playwright end to end tests into product demo videos. It generates a demo scenario from a test (with an LLM prompt or a Claude Code skill), lets you edit it, records the flow against your running app, and composites cursor animation and voiceover into an MP4. The screenwright.io site describes a fuller workflow: declarative flows, capture inside your CI, re-rendering on each release through a GitHub Action, and a demo lint step that fails the build when a demo breaks.

Good fit if you already have Playwright tests, want the video to show your real running app, and like treating demos as build artifacts in CI.

Less good fit if you don't have end to end tests, or your app is hard to run in a clean, seeded state.

Recreated UI or recorded UI?

This is the main technical difference:

• Recreated (DemoVexa, PushPlay): no running app or login needed, sample data by design, and each format can have its own layout. The screens are a reproduction, so you should check them against the real product.
• Recorded (Screenwright): the pixels are your real app, so there's no question of accuracy. You need a running, seeded environment, and layout changes per format are harder.

Neither is better in general. It depends on whether you value the real pixels or a polished, easy to update animation.

How should you choose?

• You have Playwright tests and CI: try Screenwright.
• You're on React and GitHub and want per PR videos: try PushPlay.
• You want intros and feature demos from a local folder, any stack, several formats and languages: try DemoVexa.

If you're still deciding between this whole category and an ordinary screen recorder, the post on making a software demo without screen recording covers that choice.

FAQ

What tools make product demo videos from code?

DemoVexa, PushPlay and Screenwright are three examples. DemoVexa reads a local code folder, PushPlay works from GitHub pull requests and React components, and Screenwright turns Playwright tests into recorded demos.

Does DemoVexa connect to GitHub?

No. According to its FAQ, DemoVexa doesn't take a GitHub URL or connect to GitHub. You clone the repository and point a workspace at the local folder.

Is Screenwright open source?

Its CLI is published on npm under the MIT license, with its source on GitHub. The screenwright.io site also describes CI capture and a hosted workflow; check the site for what's included.

Do code-to-video tools work with any framework?

It varies. PushPlay renders React components. Screenwright works with web apps Playwright can drive. DemoVexa's FAQ says it works with a code folder in any language or framework.

Once a product demo works in English, the next request is often "can we have it in Spanish, German and Japanese too?" It sounds like a translation job. In practice it touches the script, the voice, the captions, the timing, the fonts and sometimes the layout.

This post goes through each of those, with a plan you can use whichever tool you make the video with.

Disclosure: I build DemoVexa, a tool to create multilingual product demo videos from code, and I describe how it handles languages near the end.

Key takeaways

• A localised demo has five layers: script, voice, on screen text, captions and timing. Each needs its own decision.
• Keep your product name and the labels on your app's screens as they are, unless your app itself is localised.
• Translated speech is rarely the same length as English, so scenes need to re-time to the new voiceover.
• Scripts that aren't written in Latin letters, and right to left languages, can need different fonts and layouts.

Contents

• Key takeaways
• What actually changes between language versions?
• Should you translate the script or rewrite it?
• How do you handle timing when the voiceover changes length?
• Which voice should you use for each language?
• What about captions, fonts and right to left languages?
• How does DemoVexa handle languages?
• A simple plan for your first localised demo
• FAQ

What actually changes between language versions?

Here's how the layers of a demo usually behave when you make another language version:

The row people most often get wrong is screen labels. If your product only ships in English, a Spanish demo should still show English labels, with the Spanish voice explaining them. Otherwise the video shows an app that doesn't exist.

Should you translate the script or rewrite it?

Rewrite it, using the English version as a brief. A word for word translation keeps English sentence shapes and idioms that sound odd when spoken. A native speaker, or a model you then check with a native speaker, should write the line the way someone would actually say it.

A few rules help:

• Keep each line to one idea, so it can be timed to one action on screen.
• Avoid puns and wordplay in the source script. They rarely survive.
• Write numbers, dates and currencies the way that market expects.
• Keep UI names in quotes or as they appear, so viewers can match them to the screen.

How do you handle timing when the voiceover changes length?

This is the part that breaks screen recordings. If you recorded the English demo with clicks matched to English narration, a German voiceover that runs longer will drift out of sync. You either re-record per language or edit each version by hand.

Animated demos made with tools that create product demo videos from code have an easier time, because the timing is data rather than footage. Each scene can be stretched or shortened to the new voiceover, and clicks can be placed on the matching word again. That's how multilingual product demo videos made from code stay in sync without a re-record.

Which voice should you use for each language?

Use a native speaker for each language, whether that's a person or an AI voice. A voice cloned from an English speaker will usually keep an English accent in other languages, which some audiences find distracting.

If you use AI voices, keep one chosen voice per language and reuse it for every video, so your Spanish videos sound like a series.

What about captions, fonts and right to left languages?

Captions should be generated from the new voiceover so they match what's actually said. Subtitle files (SRT or VTT) should be in the video's language too, so platforms like YouTube can label them correctly.

For languages written in a different script, check your brand font. Many brand fonts only cover Latin characters, so you'll need a fallback that covers the script. Right to left languages may also need captions and cards laid out in the other direction.

How does DemoVexa handle languages?

This section describes one tool, based on its docs. DemoVexa's languages documentation lists 85 languages, the ones ElevenLabs' Eleven v3 model speaks. Claude writes the voiceover, captions, title and end cards and posts in the chosen language, while the product name, module names and app labels stay as they are. For scripts like Arabic, Hindi, Japanese, Thai or Russian, the build agent uses a font that covers the script when the brand font doesn't, and Arabic, Hebrew, Persian, Urdu, Pashto and Sindhi are laid out right to left. Native voices are listed first on the Voice step, and you can make a version of an existing project in another language from the project menu. Each language version counts as a new video on its plans.

A simple plan for your first localised demo

1. Finish the English version first and get it approved.
2. Pick two languages based on where your users or leads actually are.
3. Have the script rewritten, not translated, and checked by a native speaker.
4. Pick one native voice per language and save it for later videos.
5. Rebuild or re-time the video to each new voiceover.
6. Watch every version end to end with captions on before you publish.

FAQ

Can I translate a product demo video without re-recording it?

With a screen recording you can add a new voiceover and subtitles, but clicks and scene changes may drift out of sync. Demos animated from code can re-time each scene to the new voiceover, which avoids re-recording.

Should the app's screen labels be translated in a localised demo?

Only if your app is actually available in that language. Otherwise keep the real labels and let the voiceover and captions explain them in the viewer's language.

How many languages does DemoVexa support?

According to its docs, 85 languages, which are the languages of the ElevenLabs Eleven v3 voice model. All of them are available on every plan.

Do I need an AI voice to make a demo in another language?

No. You can record the translated script yourself or with a native speaker, or make a version with captions and music only.

Most product demo videos start with someone recording their screen. A code-generated demo starts somewhere else: with the source code of the product. Instead of capturing pixels from a running app, a tool reads the code, works out what the screens look like, and rebuilds them as animation.

That sounds like magic until you break it into steps. Then it's a fairly ordinary pipeline, and knowing the steps helps you judge where these tools are strong and where they need a human.

Disclosure: I build DemoVexa, a desktop app for making product demo videos from your codebase, so I'll use it as the worked example. The general process applies to other tools in this category too.

Key takeaways

• A code-generated demo rebuilds your screens from the source code instead of recording a running app.
• The pipeline is roughly: read the code, write a brief and script, add a voice, build animated scenes, render.
• Accuracy comes from reading real labels, routes and components, so the video uses the same words as the app.
• You still need to review the script, the scene plan and the final video, because the tool can misread intent.

Contents

• Key takeaways
• What is a code generated product demo?
• What does the pipeline look like?
• Where does the accuracy come from?
• What does it get wrong, and what do you still review?
• When is a code generated demo a bad fit?
• What does this look like in DemoVexa?
• FAQ

What is a code generated product demo?

It's a video where the screens are recreated from your product's code rather than captured from a screen. The result looks like your app: same layout, same labels, your brand colours. But every frame is drawn by code, which means it can use clean sample data, stay sharp at any size, and be rebuilt when the code changes.

This is different from two things it's often confused with:

• Screen recording with automation. Some tools drive a real browser (often with Playwright) and record it. That's still capture, just scripted.
• Generic AI video. Text to video models produce footage from a prompt, but they don't know what your product's screens actually contain.

What does the pipeline look like?

The details differ between tools, but most code-to-video pipelines follow the same stages.

The order matters. The voice usually comes before the animation, because the animation is timed to the spoken words. Change the script after the build and you usually need a new voiceover and a rebuild.

Where does the accuracy come from?

A screen recording is accurate on the day you record it. A code-generated demo is accurate to the code it read. That has a few practical effects:

• Labels match. If the button in your code says "Export", the scene says "Export".
• Screens match the current version. Pull the latest changes, rebuild, and the video follows.
• Sample data is a choice. The tool shows example records instead of whatever happens to be in your database.
• Brand comes from the source. Colours, fonts and logos can be read from code or set once in a brand kit.

The limit is that code doesn't explain intent. It tells a tool what a screen contains, not why a user cares. That's why the brief and script steps still matter.

What does it get wrong, and what do you still review?

From the way these pipelines work, the usual weak spots are predictable:

1. The story. A tool can find every feature and still pick the wrong one to lead with.
2. Claims. Narration can drift into promises the screen doesn't prove. Strip any line the viewer can't see.
3. Complex state. Screens that depend on real data, permissions or third party content are harder to recreate exactly.
4. Pronunciation. Product names and acronyms often need a fix in the voice step.

A good habit is to review at the cheapest point. Fixing a scene plan takes minutes. Fixing a rendered video means rebuilding it.

When is a code generated demo a bad fit?

It isn't the right tool for every video. A screen recording is often simpler when:

• You need a quick, informal walkthrough for a teammate or a support ticket.
• The demo depends on live data, such as a real integration responding.
• You don't have access to the code and the product's website doesn't describe it well.
• The video is mostly about a person, such as a founder explaining a vision on camera.

What does this look like in DemoVexa?

DemoVexa is one way to create demo videos from code. It's a desktop app (and a CLI) that runs on your computer. You point a workspace at your code folder, write a brief or let Claude draft one, review the script, pick a voice, and Claude builds the video in React and animates it with Remotion. The docs describe how the build agent recreates your UI: it reads the code, recreates the screens, times clicks to the voiceover, adds captions and an end card, and checks still frames of its own work before rendering a preview. According to the docs, a build usually takes 15 to 30 minutes.

Since version 0.3.5 a workspace can also start from a product's website and uploaded documents, though screens recreated that way are less exact than with the code.

FAQ

Is a code-generated demo the same as a screen recording?

No. A screen recording captures a running app. A code-generated demo recreates the screens from the source code and animates them, so nothing is captured from a screen.

Do I need to know React or Remotion to use a code-to-video tool?

It depends on the tool. Some expect you to write the animation code yourself. Others, like DemoVexa, have a build agent write it, and you change things by editing the brief and script or by asking in plain words.

Can a code-generated demo show my real customer data?

It doesn't need to. Because the screens are drawn by code, they use sample data you choose or that the tool generates, which keeps real customer details out of the video.

What happens when my UI changes?

You rebuild the video from the updated code instead of recording it again. The rebuilt video still needs a quick review before it replaces the old one.

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.

Contents

• 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:

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.

Your repository knows the name of every screen, the exact label on every button, the order of every flow, and what changed recently. A demo script built from those facts is more accurate than one written from memory, and it uses the same words the viewer will see on screen.

This is the same reading that tools which turn your codebase into a demo video do automatically, but it works just as well by hand. Here's where to look, and what each source gives you.

Key takeaways

• Your code already holds the screen names, exact labels, flow order and recent changes a demo script needs.
• Navigation gives the map, UI strings give the vocabulary, fixtures give the sample data and end to end tests give the flow.
• Git history shows what's new, and docs show what a feature is for. If code and docs disagree, fix that first.
• A one page plan built from these sources can be traced back to the code line by line.

Contents

• Key takeaways
• 1. Routes and navigation: the map of the video
• 2. UI strings: the vocabulary of the narration
• 3. Fixtures and seed data: what the screens should contain
• 4. End to end tests: the flow, already written down
• 5. Git history: what's actually new
• 6. Docs and how to guides: the intent
• Putting it together: a one page demo plan
• Letting a tool do the reading
• FAQ

1. Routes and navigation: the map of the video

Start with whatever defines your screens. In a React app that might be a router config, a pages or app folder, or a sidebar component that lists the main sections.

# Next.js app router: every page in the app
find app -name "page.tsx"

# A sidebar or nav config
rg -n "label:" src/components/Sidebar.tsx

The navigation tells you two things. First, the names of the main areas, exactly as users see them. Second, the shortest path to any screen. If your feature lives three levels deep, the demo needs a plan for getting there, or it should start on that screen directly.

2. UI strings: the vocabulary of the narration

The most common accuracy mistake in a demo is the narration calling something by a different name than the screen does. The voiceover says "download" and the button says "Export". The script says "workspace" and the app says "project".

If your app has translation files, those are a ready made glossary:

rg -n "\"export" locales/en.json

If it doesn't, search the components for the visible strings in the flow you're demoing. Copy the exact labels into your script notes. When you write narration later, use those words and only those words for UI elements.

3. Fixtures and seed data: what the screens should contain

Test fixtures and seed scripts are often the best sample data you have. They were written to exercise the feature, so they usually cover the interesting cases: an overdue invoice, a user without permission, an empty state.

Read them for two reasons. They tell you which data makes the feature look like itself. And they tell you what to avoid: if a fixture is named broken_user or full of placeholder text, it's a sign you need a cleaner demo dataset before anything goes on camera.

4. End to end tests: the flow, already written down

An end to end test is close to a demo script with the narration missing. It lists steps in order, names the elements a user touches, and asserts the result.

test("send an invoice", async ({ page }) => {
  await page.getByRole("link", { name: "Invoices" }).click();
  await page.getByRole("button", { name: "New invoice" }).click();
  await page.getByLabel("Client").fill("Northwind Studio");
  await page.getByRole("button", { name: "Send" }).click();
  await expect(page.getByText("Invoice sent")).toBeVisible();
});

Turn that into scenes and you have: open Invoices, start a new invoice, pick a client, send, see the confirmation. The last assertion is usually the moment the demo is built around.

5. Git history: what's actually new

For a feature launch or changelog video, the commit log tells you what changed and when. A quick look at recent history for the feature's folder is often enough:

git log -20 src/invoices

Look for the commit that introduced the user facing change, and read its diff. It tells you which screens changed, which strings were added, and sometimes why. That "why" is worth putting in the first line of your narration, if it's something a user cares about.

6. Docs and how to guides: the intent

Code tells you what the product does. Docs tell you what it's for. If you have a how to guide for the task you're demoing, it already describes the steps in user language and usually says who the feature is for. Use it to check that your scene order matches what you tell users in writing.

If the docs and the code disagree, fix that first. A demo that matches the code but not the docs will confuse people who read both.

Putting it together: a one page demo plan

After going through these sources, you can write a plan in a few minutes:

Add one line on top: who the video is for and the one thing they should remember. That's a complete brief, and every detail in it can be traced back to the code.

Letting a tool do the reading

This kind of reading is exactly what DemoVexa automates. You point a workspace at a local code folder (in any language), plus docs if you have them, and Claude reads it to learn the product's screens, names and flows before it drafts a brief and script. If the folder is a git repository, DemoVexa can also suggest video ideas from recent history. The docs page on choosing a code folder and docs for demo videos has practical advice on choosing the right folder and writing how to guides that turn into clear scenes.

Whether you do it by hand or with a tool, the principle is the same: the code is the most up to date description of your product you have. Start the demo there, not from memory.

FAQ

How do I list every page in a Next.js app?

With the app router, each route is a folder under app that contains a page file, so find app -name "page.tsx" lists them (adjust the extension if you use .jsx or .js). With the older pages router, the files under pages are the routes.

Can an end to end test be used as a demo script?

It's a good starting point. A test already lists the steps in order, names the elements a user interacts with and checks the result. You still need to add narration and decide which steps are worth showing.

How do I make sure the narration matches the labels in the app?

Copy the exact strings from your translation files or components into your script notes, and use only those words for UI elements. If the button says "Export", the voiceover should say "Export" too.

Can I make a demo video straight from a GitHub URL?

Not with DemoVexa. It reads a local folder, so you clone the repository to your computer first and point a workspace at that folder. Pull the latest changes before making a video about a new feature.