Why screen recordings break in three weeks
Every team that ships UI weekly has the same problem: their demos go stale the moment a feature lands. Here's the math on why, and the only durable fix.
Most product video has a half-life of about three weeks. Here's why, and what to do about it.
The math
A typical SaaS dashboard merges 5–15 UI-touching PRs per week. Most are cosmetic — a copy tweak, a spacing change, a new icon. A handful are structural — a button moves, a tab gets renamed, a flow gets re-ordered.
A 30-second product demo touches roughly 10 UI elements: clicks, types, scrolls. The probability that any single element survives a week of UI churn is high — call it 95%. The probability that all ten survive a week is 0.9510 ≈ 60%.
That's already not great. Compound it over three weeks and you're at 0.63 ≈ 22%. Most product demos are subtly broken three weeks after they're recorded — wrong button copy, wrong tab order, missing element. Not obviously broken; just misleading enough that prospects ask "does it actually look like that?" on the first call.
Why the usual fixes don't work
Teams try three things, and all three fail at scale.
Re-record on a cadence. Quarterly works for one demo. At ten demos it's a half-FTE. At fifty it's impossible.
Generic demos. Strip out anything specific so nothing can go stale. The demo gets vague enough that prospects don't learn what the product actually does.
Screenshots instead of video. Same staleness problem, less compelling. Now you have static screenshots that go out of date, instead of motion video that goes out of date. Step backwards.
The structural fix
The only durable fix is to make the demo regeneratable from a script. Source-of-truth shifts from the recording to the script. The recording becomes a function of the script and the current build:
video = render(capture(script, current_build))The script is hand-authored once. Capture and render run on every UI change. Cursor positions, click targets, captions — all derived from the script + the current rendered DOM, not from a frozen pixel buffer.
That's what CaptureBeam is. The script is YAML. Capture is Playwright. Render is Remotion. The video is an artifact, regenerated on demand.
What this unlocks
Once your demos regenerate, the calculus changes. Instead of 10 tightly managed demos, you can have 100 specific ones. Per feature. Per persona. Per onboarding state. Per pricing tier. The marginal cost of a new demo drops from "a half-day of recording" to "30 lines of YAML and a re-render."
Suddenly demos become a product surface, not a marketing artifact. Engineers ship them with PRs. Product writes them for new features. Sales generates them per prospect. The org starts treating demos like documentation: written once, regenerated forever, accurate by construction.
That's the unlock. Three weeks of demo half-life is a structural constraint, not a discipline problem. Fix the structure and the constraint goes away.