We started out paying for an off-the-shelf demo-video tool, like most teams do. Then we counted the combinations: two themes, seven languages, and a UI that changes almost every week. The math didn't work. So we built our own demo studio instead — and the fact that a two-person team could do that, in days, is a bigger story than the tool itself.
The problem: a demo isn't one video, it's fourteen
promptShield ships in light and dark themes and in seven languages — English, French, German, Spanish, Italian, Dutch, and Portuguese. A single product demo — "here's how you redact a contract" — is therefore not one clip. It's two themes × seven languages = fourteen renders, each showing the exact same actions against a UI that has to look native in that language and correct in that theme.
Now multiply that by every demo on the marketing site, and then remember that the app underneath is a moving target. We change layouts, rename buttons, tighten spacing, and add features on a weekly cadence. Every one of those changes silently invalidates recordings that were shot against the old screens.
Why the SaaS approach broke down
Tools in the Arcade / Storylane / Supademo / Trupeer class are excellent at what they do: you click through your app, they capture the screen, and you get a polished walkthrough. But they all share one assumption — that a demo is a captured artifact of pixels. That assumption is exactly what falls apart at our scale:
- The combinatorial explosion is manual. Fourteen variants of a demo means fourteen hand-recorded takes. Nobody records the same flow fourteen times in a row without drift, and re-shooting the German dark-mode version six weeks later to match the others is nobody's idea of a good afternoon.
- UI drift orphans everything at once. Move a button and every recording that touched it is now subtly wrong. Because the recording is pixels, there is no way to "re-run" it — you re-shoot, by hand, fourteen times, for every demo the change touched.
- Localization is a second job. The SaaS records whatever language happened to be on screen. Keeping seven language versions of a dozen demos in lockstep with the product is a full-time content role we don't have and don't want.
The honest conclusion was that this category of tool is built for a world where you make a demo once and it stays true for months. Our world is the opposite: the demo has to be regenerated constantly, in every theme and every language, from a product that never sits still.
The unlock we already had
Here's the piece that made building our own realistic rather than reckless. Our public /demo page doesn't fake the app — it mounts the real desktop frontend in the browser, the same React components, the same CSS, the same i18n, with the backend calls swapped for mocks. Every UI change we make to the desktop app already flows into the demo automatically, because the demo is the app.
That meant we didn't need a tool to "capture" our app. We needed a tool to drive it — and since the app already runs in the browser and already knows how to render itself in any theme and any language, the theme and language axes could come for free.
What we built
Internally we call it Demo Studio. The shift in thinking is small and it changes everything: we record a script of actions, not a video of pixels.
Record by demonstration
You turn on capture mode and click through the flow once, in one language, one theme. The Studio doesn't record the screen. It records what you did — a list of semantic events: "click this element", "scroll here", "open this panel" — each tied to a resolvable selector, the preconditions it needs, and a timestamp. On replay, the clicked element flashes so viewers can follow the action, without any of the jittery cursor-tracking that screen recorders fight with.
One script, fourteen renders
That single script is then handed to a headless browser that replays it and captures the result — once per theme, once per language. One recording session produces all fourteen WebM videos and matching still frames, deterministically, because it's the same script driving the same real app with the theme and locale dialed in each time. The German dark-mode version and the English light-mode version are guaranteed to show the identical actions, because they came from the identical script.
An effects timeline — and an AI that suggests them
On top of the raw replay sits a timeline for the polish a good demo needs: zoom into a region, pulse on a control, drop an overlay caption. There's also an "Ask Claude" step that proposes an effects track for a script, so the first pass of "where should we zoom?" is drafted for you rather than nudged in frame by frame.
Slots that keep themselves honest
Every place a demo appears on the site is a <DemoMedia slot="..."/> in the code. The Studio scans the whole codebase for those, and shows you, at a glance, which slots are fully recorded across every theme and language, which are missing a render, and which media directories have gone orphaned because the slot they belonged to was deleted. The tool tells you what's stale instead of you finding out from a customer.
The economics quietly inverted
The point of all this isn't the features. It's what happened to the cost curve. With the SaaS, the marginal cost of a UI change was "re-record every affected demo, fourteen times each, by hand." With Demo Studio, the marginal cost of a UI change is press re-render. The script is still valid — it describes actions, and the actions still exist — so the fix is machine time, not human time.
Adding a new language used to mean re-shooting every demo in it. Now it's one more value on the locale axis. Adding a theme was the same story. The work that used to scale linearly with (themes × languages × demos × release cadence) now scales with the number of distinct flows, and the rest is rendering.
This is a symptom of a bigger thing
For decades the default answer to "we need a tool for X" was "rent it." Building your own was expensive, slow, and a distraction from your actual product, so a whole industry grew up selling narrow, per-seat tools that each did one job passably for everyone. The make-versus-rent line sat far over on the "rent" side, and most internal tooling lived on the wrong side of a build cost nobody could justify.
That line has moved. With an AI coding agent in the loop, a small team can now build a bespoke internal tool — one shaped to its exact problem, not the average of a thousand customers' problems — in the time it used to take to evaluate vendors. Demo Studio wasn't a quarter-long project. It was a handful of focused days, and it fits our two-theme, seven-language, always-moving reality better than any general-purpose product ever could, because it was built for precisely that and nothing else.
This is the part worth sitting with. A great deal of the software-as-a-service ecosystem is built on the old make-versus-rent economics — on the assumption that building your own version of a narrow tool is uneconomical, so you'll pay per seat forever. When the cost of building the tailored thing collapses, that assumption stops holding. The tools most exposed aren't the deep, hard-to-replicate platforms; they're the thin ones — the "we do one clean workflow and charge every user for it" products that a capable team can now stand up in-house, fitted exactly to their own shape, in an afternoon.
We didn't build a demo studio because we wanted to be in the demo-tooling business. We built it because it was suddenly cheaper to build the right thing than to keep fighting the rented one. That calculation is going to get made, quietly, in a lot of companies over the next few years — and each time it does, a little more of what used to be a subscription becomes a weekend's worth of code you own outright.
