version.cam re-records product demo videos in CI on every push and fails the build when the app no longer matches the clip

Every README has the GIF. It showed the app in March, and by June the button in it has moved, been renamed, or gone. Nobody re-records it, because nobody gets paid to re-record it.

version.cam’s pitch is a demo video that fixes that by re-recording itself. The page’s headline is “Demo videos that re-record themselves,” and its tagline is “Short product videos of your real app, recorded by your CI.”

The split of labor is the clever part. “Your coding agent writes the clip,” the page says, once. After that it is just a script. CI “drives your real app through it on a clock the script sets, renders the video, and fails the build when the app no longer matches the clip.” Pushing code runs it again, and no model is called.

That also turns the video into a test. If someone renames a control, the clip can’t find it, and the pull request fails. The page says a check fails for four reasons: “a control was renamed or removed, a page moved, a wait never came, or the app would not start.” And the failure is specific: “The failure names the control it could not find and the second it gave up.” A passing run looks like PASS 01-create-a-shipment followed by “1/1 clips still match the app.”

The page also says the clip the agent writes gets checked by a separate reviewer before you use it, which is a sensible thing to do with a script you didn’t write.

Getting started is one command. npx versioncam ci generates the GitHub workflow file, you commit it and push, and the free recorder and Action run in your own CI. The service’s part is storing the recordings after CI makes them.

Here is where the sharing link earns its keep. It is “a permanent link that only plays the newest version from your default branch that passed.” If a clip is broken at the moment, viewers get the last good one instead of an error. The page says the links embed in Notion, Confluence, GitBook and docs sites, and a clip can serve as a README GIF.

So the public never sees a broken demo, and you see a red check. The video and the failure alarm are the same file.

The price is where the catch sits. Public repositories get three projects with ten clips each and thirty days of history, free, with the pull request check and README badge. Private repositories are $35 per project per month, or $350 a year, which the page calls a planned price “until the first invoices.” Beta accounts get 20% off their first year, and the first ten people to ask get Pro free for a year. Pricing is per project, not per seat.

The code is source-available under FSL-1.1-ALv2 and, per the page, “you can use it for free in your own apps and CI.” Each version converts to Apache 2.0 two years after its release. The page doesn’t name who is behind it and points at the versioncam organization on GitHub instead, where the Contributors section lists no names either.

Expect screenshots and docs videos to follow the same path tests took: written once by whoever knows the app, then run by a machine on every push, and noticed only when they fail. The mechanism that makes it work is cheap, because the expensive step, an agent writing the script, happens once.

The lock-in question is real too. The recordings live on the vendor’s service, and the license is a source-available one. A team with a docs site full of embedded clips should read the terms before the beta ends.

That’s a wrap. Take two, on every push.