We started with an off-the-shelf demo-video tool, like most teams. Then we counted the combinations: two themes, seven languages and an interface that changes almost every week. The numbers did not work, so we built our own demo studio. One person working with AI models built it in days, and that matters more than the tool.
One demo, sixteen videos
promptShield ships in light and dark themes and in eight languages: English, French, German, Spanish, Italian, Dutch, Portuguese and Polish. So one demo, such as redacting a contract, is sixteen renders. Each shows the same actions in an interface that must look native in its language and correct in its theme.
Multiply that by every demo on the marketing site. Then add the weekly changes to layouts, buttons, spacing and features. Each change makes recordings of the old screens wrong.
Why screen-capture tools did not fit
Tools such as Arcade, Storylane, Supademo and Trupeer are good at what they do. You click through your app, they capture the screen, and you get a polished walkthrough. They treat a demo as a recording of pixels, and at our scale this approach failed in three ways.
- Every variant is recorded by hand. Sixteen variants mean sixteen takes, and nobody records one flow sixteen times without small differences.
- One interface change breaks every recording. Move a button and every recording that showed it is wrong. A recording cannot be updated, so you record again, sixteen times, for each affected demo.
- Translation becomes a second job. The tool records whatever language is on screen. Keeping eight versions of a dozen demos in line with the product would be a full-time content role.
These tools suit a demo made once that stays accurate for months. Ours must be rebuilt constantly, in every theme and language, from a product that keeps changing.
What we already had
Our /demo route mounts the real desktop frontend in the browser: the same React components, CSS and translations, with backend calls replaced by mocks. Every change to the desktop app reaches it on the next build. Demo Studio records its videos from that route. Prospects who want to try the product use the free web app.
So we needed a tool that drives the app rather than films it. The app already renders in any theme and language, so those variants cost nothing extra.
What we built
We call the tool Demo Studio. It records a script of actions, not a video of pixels.
Recording: you turn on capture mode and click through the flow once, in one language and one theme. The studio records each action, such as a click, a scroll or an opened panel, with its selector, preconditions and timestamp. On replay, the clicked element flashes so viewers can follow it.
Rendering: a headless browser replays the script once per theme and once per language. One session produces all sixteen WebM videos and matching still frames. The German dark version and the English light version show identical actions, because the same script drives the same real app.
Effects: a timeline adds zooms, pulses on a control and overlay captions. An "Ask Claude" step drafts a first effects track for each script.
Slot checks: each place a demo appears on the site is a <DemoMedia slot="..."/> in the code. The studio scans the codebase and shows which slots are complete in every theme and language, which are missing a video, and which media folders belong to deleted slots.
What a UI change costs now
With the rented tool, a UI change meant recording every affected demo again, fourteen times each, by hand. With Demo Studio, it means pressing re-render. The script still works because it describes actions, and the actions still exist. The computer does the work instead of a person.
A new language or theme now needs one more render setting. The work used to grow with every theme, language, demo and release, all multiplied together. Now it grows with the number of distinct flows.
Building now costs less than renting
For decades, the usual answer to needing a tool was to rent one. Building was expensive, slow and a distraction from the real product. So an industry grew up selling narrow per-seat tools that did one job adequately for everyone.
With an AI coding agent, one person can now build a tool fitted to their exact problem. It takes about as long as comparing vendors used to. Demo Studio took a few focused days instead of a quarter.
Much of the software-as-a-service market assumes that building your own narrow tool does not pay, so customers keep paying per seat. When building gets cheap, that assumption weakens. The small products that sell one workflow per user are the most exposed.
We built this because building the right tool had become cheaper than working around the rented one. Many companies will make the same calculation in the next few years. Each time, they will replace a subscription with code they own.
Common questions
Why not just use a screen-recording demo tool?
We did, at first. Two themes, seven languages and weekly interface changes turned each demo into fourteen takes, all recorded by hand.
What does a demo studio have to do with your product?
The same reasoning produced both. We wrote our own detection engine instead of shipping an existing toolkit and built the model our web app runs on, because the generic option did not fit the job.
What happens to a demo when the interface changes?
We press re-render. The script records actions, not pixels, so it still works as long as those actions exist. All sixteen videos come out of one session.