How we think product explanation should work.

1. Real over generated

Customers want to see the product working, not a presenter describing it. Everything Stagewright shows is recorded from a running build of your product, and it carries the build it came from: Recorded from build a1b2c3d · verified 3h ago.

We don’t make avatars, generated UI, or frozen HTML copies of your app that drift from the real one. Where AI does something concrete, like drafting a script from a feature’s code and its support tickets, the draft says what it was written from (“written from src/invites/** and 9 tickets”), and it stays labelled as a draft until a person approves it. No sparkles.

2. Walkthroughs are tests

A walkthrough is a file in your repository: steps, narration, and a check on every step that changes the screen. It runs against your product on every pull request, like any other test. If it can’t complete, something customers are taught to do no longer works.

This idea isn’t ours. Docs as Tests, the approach Manny Silva set out in his book and talks and built into the open-source Doc Detective, tests documentation by performing its instructions, so docs that stop matching the product fail instead of quietly misleading people. Walkthroughs as tests applies the same idea to product videos, help articles and training: the thing customers watch is the thing that ran.

Because a walkthrough is a test, it has to be trustworthy. Locale and time zone are pinned, screenshots wait for frames to settle, regions that change run to run are masked and called out, and every failure is recorded a second time before it’s judged. A check that cries wolf gets ignored, so a failure that doesn’t repeat is reported as flaky and never blocks a merge.

3. Approve or file

When a walkthrough no longer matches, other tools treat it as a content problem: re-record it and republish. We treat it as a signal with exactly two answers.

• The change was intended. The new recording waits on the pull request with before and after frames. Someone approves it, and that approval is the gate to publishing: the player, the help article and the course update together.
• The product broke. That’s a regression. It’s filed in your issue tracker with the clip of the failing step and steps to reproduce, assigned to the PR’s author, and the fix PR is replayed to prove the fix.

Either way it’s decided before merge, by the people who made the change, in the place they already review code. Practitioners have asked for exactly this: “‘Docs updated’ should also be a release approval condition.”

4. Honest numbers

Content tools count views. Views don’t tell you whether anyone understood anything.

We measure what we can stand behind: where people stop watching, by the second and by the line of narration; how many support conversations each feature gets. When we compare people who watched with people who didn’t, we say who they were compared with (“compared with similar non-viewers”) and offer a holdout to confirm it. We never write “caused” or “drove” without one.

The same rule applies to us. We don’t have customer results yet, so this site shows none. Every chart on it is labelled as example data, every comparison table says when it was last checked, and nothing here describes a feature we haven’t built.

5. Theirs, not ours

The repository is the source of truth. Walkthroughs, courses and the project’s settings can all live in it as YAML, JSON or stagewright.config.ts, and change through pull requests. Recordings run where your code runs: on a laptop against localhost, in any CI, or on a runner inside your network. Help articles go back to your help center, issues to your tracker, and events come from the analytics you already have. Stagewright sits downstream of all of it.

6. Exact and calm

Counts, build SHAs, file paths and real frames, instead of adjectives. If a sentence on this site can’t be checked, it shouldn’t be here. If you find one, tell us at support@stagewright.ai.