Demo Videos That Never Go Stale: the Reproducible Script

The expensive part of a demo video is not the first recording. It is the fourth, after the sidebar moved, the button got renamed and the onboarding changed. Klevo stores every demo as a reproducible script, so the fourth version costs one sentence: “render it again”.

Why do demos go stale?

A screen recording is a photograph of the app on one afternoon. The app keeps moving. Within a quarter the clip on the landing page shows a navigation that no longer exists, and the one in the onboarding email tells new users to click a button that was renamed. Everyone notices; nobody re-records, because re-recording means rehearsing the flow, capturing it cleanly, editing the cursor and captions back in, and exporting it for every channel again.

So the stale clip stays, and quietly does the opposite of its job.

What is a demo script?

In Klevo, a video is the output of a script: a short JSON file that says where the demo starts, which device to use, how to log in, and the steps with their captions.

{
  "version": 1,
  "title": "Create a project",
  "url": "https://staging.myapp.com/projects",
  "device": "desktop",
  "auth": { "type": "password", "secret": "DEMO_LOGIN" },
  "output": { "format": "16:9", "frame": "browser", "style": "smooth" },
  "steps": [
    { "action": "click", "target": "role=button[name='New project']", "caption": "Start a new project", "zoom": true },
    { "action": "type", "target": "label=Name", "text": "Q4 launch", "caption": "Give it a name" },
    { "action": "click", "target": "text=Save", "caption": "Done" }
  ]
}

Three properties make it durable:

Property	What it means	Why it matters
Targets are semantic	A step says “the button named New project”, not “the pixel at 840, 120”	A moved button is still found; a renamed one fails loudly instead of clicking the wrong thing
Secrets are references	The script names DEMO_LOGIN; the password lives encrypted on the server	The file is safe to keep in a repo and share with the team
Output is separate from steps	Format, frame, style and brand sit in their own block	The same steps render as a landing-page clip and a vertical story

Your AI writes this file for you while it drives the app; the script tool hands it back as JSON, and the video page has a download button. Keep it next to your code, at .klevo/create-project.json or wherever your docs live.

How does re-rendering work?

A render is a replay. Klevo opens a fresh browser, logs in with the named secret, performs the steps at a human pace, records every frame, and composes the video: cursor, zoom, captions, frame, intro card. Nothing from the original session is reused except the script.

That is why “render it again” after a UI change produces a current demo and not a patched one. The browser clicks the button where it is today. Ask for it in the chat (“render script abc123 again”) or from the video page (“Render again”), and change the output while you are at it: 9:16 on a phone frame for a story, 1:1 for the feed, a snappier style for a changelog, the minimal style for a help center.

What does a failed step tell me?

When a step cannot be performed, the render stops and the result says which step, with a screenshot of the page at that moment and the browser’s console errors.

Read it like a test failure, because it is one:

• The target is ambiguous (two Save buttons): make the step more specific and render again.
• The element is gone (Save was renamed to Create): the demo needs updating, and so does every doc that mentions Save.
• The page broke (a console error and a blank panel): your app has a bug on staging that a demo found before a customer did.

Failed renders do not count against the monthly limit.

Which clips should come from one script?

A launch is a dozen placements that each want a short clip. With one script you can cover them:

• the landing page hero (desktop, 16:9, browser frame, smooth);
• the Product Hunt gallery (desktop, 16:9, no frame, so it fills the slot);
• the story or short (mobile device, 9:16, phone frame, captions at the top);
• the changelog entry (desktop, 16:9, snappy style, zoom on every click);
• the onboarding email (the same clip as the hero, or a shorter script with three steps);
• the support article (minimal style, no zoom).

Record once, render six times. When the feature changes, render six times again.

What is planned next?

The script already makes a demo reproducible by hand. The next step is to make it automatic: an API that takes a script and returns a render, and a GitHub Action that re-renders your demos on every deploy and comments the link on the pull request. If a step fails, the job fails, which turns every demo into an end-to-end check. This is planned, not shipped; the scripts you save today are the ones it will run.

Frequently asked questions

Can I write the script by hand? You can, and the format is documented, but the fast path is to let your AI record it live: it sees the page, picks working targets and writes the captions.

Does re-rendering need the AI? No. A render is a replay of the saved steps; the AI only helps if you want to change them.

What if my staging data changed? The steps type their own values (“Q4 launch”), so a different starting state is usually fine. If a step depends on existing data, say so in the caption and keep a seeded test account for demos.

Can the team share scripts? Scripts belong to the account that recorded them. Keeping the JSON in the repo is the simplest way to share them today.

Start free, record the flow you keep meaning to update, and let the script carry it from now on.