Why Stagewright
Couldn't we just build this with Claude?
Mostly, yes, for the first video. Here's what one afternoon with a coding agent produces, what it doesn't, and where Stagewright fits next to the agents your team already uses.
The tailwind
Apps are being built faster than ever with coding agents. Work that took a sprint can take an afternoon, so the interface changes more often, and every video, help article and training course that shows it goes stale sooner.
That’s the reason Stagewright exists. It’s also the obvious objection, turned around.
Yes, you could build the first version
Any team with Claude Code can script Playwright to click through a flow, ffmpeg to cut the recording, and a voice API to read a script over it. It’s a good afternoon’s work, and the video at the end will look fine.
We agree, and we make it easier. The CLI is free and MIT-licensed, it records on your machine and in your CI without an account, and the prompts we’d give an agent to set it up are on the site, ready to copy. If a script in your repo is all you need, use it.
What the afternoon doesn’t produce
The first video is the easy part. The work is in what happens on the fortieth release, when nobody remembers the script exists.
| One afternoon with an agent | Stagewright |
|---|---|
| A video, once | History. A baseline per walkthrough, every run kept, when each was last verified, and what changed in which pull request |
| Content in a folder | Joined data per feature. The feature’s code, its videos and articles, how it’s used, how many support conversations it gets, and its open issues, in one place and over time |
| Scripts you maintain | Integrations maintained both ways. Intercom, Zendesk and Productlane; Linear, Jira and GitHub; GitLab, Azure DevOps and Bitbucket. Content goes out, and articles, conversations, issues and comments come back |
| A flaky script | Checks people trust. Pinned locale and time zone, frames that settle before they’re compared, masked regions, a second run before any failure is judged, an approval on the PR, and a verdict that doesn’t cry wolf |
| Files to host | Hosting and proof. A player, password, members-only and expiring links, your own domain, the verified stamp (“Recorded from build a1b2c3d · verified 3h ago”), and where people stop watching, by the second |
History
A video someone made last spring can’t tell you whether it’s still true. Stagewright keeps every run of every walkthrough, compares each one with the approved baseline, and stamps the player with the build it was recorded from and when it last passed. When something changed, you can see the pull request that changed it and who approved the new recording.
Joined data per feature
The useful questions cross tools. Which features have no current guide? Which get the most support conversations? Did the guide we published last month change how often people ask? Answering them means mapping code, content, usage events, support conversations and issues to the same features, and keeping that mapping right as the product changes. That’s a data model, not a script.
Integrations, both ways
Writing an article to a help center once is a short script. Reading the help center back to find what’s stale, sending updates as drafts for review, filing a regression in Linear or Jira with the clip and the steps to reproduce, and posting the same verdict on a GitHub, GitLab, Azure DevOps or Bitbucket pull request is a set of integrations that each have their own auth, webhooks and API changes. We maintain them so your team doesn’t have to.
Checks people trust
A check that fails for no reason gets ignored, then turned off. Most of the work in a walkthrough check is making it quiet when nothing changed: pinning what varies, waiting for the screen to settle, masking what changes run to run, and recording every failure a second time. A failure that doesn’t repeat is reported as flaky and never blocks a merge. When a change was intended, someone approves the new recording on the PR; when it wasn’t, it’s filed as a regression. The method explains why.
Hosting and proof
Files in a bucket aren’t a player. Customers need a page that loads fast and says when it was last verified; training teams need private and expiring links; marketing wants it on your domain; and you want to know which sentence of narration people stopped watching on.
Not a rival to your agents
Your agents write the code. Stagewright keeps the explanation honest.
We’re the tool your team’s agent uses, not a competitor to it. The Stagewright plugin for Claude Code and Codex, the MCP server and the Copy prompt blocks across the dashboard let an agent write a walkthrough, run it, read why a step failed and fix it, with the same tools a person uses. The agent ships the feature; Stagewright checks that what customers are shown still matches, on the same pull request.
What’s planned
Some things only a product used by many teams can learn: typical drop-off by lesson length, how often content goes stale at a given release cadence, which kinds of script keep people watching. Benchmarks across customers are planned, opt-in and anonymized, and will come after the first design partners. They don’t exist today, and nothing on this site depends on them.
Stagewright is in private beta. Everything above is built, and we’re proving it on live accounts with the first teams. If you’d rather start with the free CLI and a coding agent, the developer page has everything you need.
Try it on your own product
Record a first walkthrough on your machine with no account. PR checks, approvals and publishing are in private beta: join the waitlist and we'll set you up by hand.