Picture the week before a launch. A product marketer is pulling together a help article, a demo script and a short walkthrough video. They ask for screenshots. Engineering sends some from last quarter. One shows a button that has since moved. Another has a customer’s name in the corner that someone has to blur by hand. Then the screen changes on Tuesday, and the walkthrough needs re-recording.
None of that is anyone’s fault. It’s what happens when docs are treated as a project: a push to catch up, a release, and the gap opens again.
That was close to where we were at Swip Tools. When we audited our docs, every screenshot on the site was older than the latest releases. We could have scheduled a screenshot session. We built a system instead, so that keeping docs, screenshots and demo clips current is a re-run, not a project. The case study has the project side of the story.
It has four parts. Each has a plain version here and a technical version you can open.
Start from what the product really does
The first rule: nothing goes in the docs that the product doesn’t actually do. Instead of writing from memory, we start from the product’s own code, and every statement has to be traced back to it. Anything we can’t confirm stays out.
For a marketer, that’s the difference between “the docs say” and “the product does.”
How we traced every claim
Agents read the operator and admin code and record each label, route and behavior with the file and line that proves it. That list is the spec.
It changes what “update the docs” means. When the app changes, the spec shows which sentences the change touches.
A screenshot pipeline, not a screenshot session
Scripts open the real product under the same conditions every time and take most of the pictures. Before each shot, customer and company names are swapped for a demo company, and the few screens we capture by hand get the same treatment, so the images are safe to publish by default. When a screen changes, we re-run instead of starting over.
Figure 1. The drill-down behind a downtime bar. The total at the bottom has to match the bar, so the page proves its own arithmetic.
Figure 2. The operator’s work board, with generic cell, part and order names.
How the capture script works
The admin screenshots come from Playwright scripts, using the Playwright already in the app’s own dependencies, run against the running app.
- Same conditions every time. One viewport (1440×900), one theme, one demo tenant.
- Anonymizing is a rule set. Just before each shot, the page text is rewritten: one facility called Demo Plant, cells named Cell A through M, operators numbered, emails on example.com. The data underneath never changes.
When a shot needs to look cleaner, we change a rule and re-run. Unique names in the user list and plain-language notes in a drill-down came from rule changes and a re-run.
Animations for the moments a screenshot can’t carry
Some things are a sequence, not a picture. Picture a plant manager on a Tuesday morning. A cell’s Friday came in at 71% against an 85% target. Why?
Our animation walks the same path they would. The day drops under the target. The downtime chart shows the biggest named cause, waiting on material. One click opens the stops behind that bar, and the total at the bottom matches the bar. A screenshot can show one of those moments. The animation shows the order they happen in, and why each step leads to the next. (The numbers are example data, and the animation says so.)
Figure 3. From a missed target to its cause. The day falls to 71% against an 85% target, the downtime chart shows waiting on material as the biggest named cause, and the drill-down total matches the bar. Example data.
Figure 4. A shift against plan. The operator taps Complete cycle, a short overlay confirms it, and the next cycle starts on its own. The shift ends with a summary. Example data.
Figure 5. A stop and the time it costs. The operator logs a reason, a banner counts the time until the stop ends, and the lost time shows up in the admin view. Example data.
These aren’t edited video. Each one is a small piece of software, so it can be checked automatically, it works for people who use screen readers or prefer reduced motion, and adding the next one is small.
How the animations work
Each explainer is a single SVG, and every frame is a pure function of a playhead t. There are no timers in state and no animation library. A simplified version:
// every visual value comes from the playhead
const bar = lerp(0, 105, ease(prog(t, 6000, 9000)));
const drawerX = lerp(100, 0, ease(prog(t, 12000, 13500)));That one decision makes the animations behave like any other tested component:
- Testable. The helpers are plain functions, so unit tests cover clamping, easing, keyframes and parsing the
?t=URL parameter. - Repeatable.
?t=9500freezes the page at that moment, and aseek()hook lets a script step through the loop frame by frame. The clips above were recorded that way, straight from the live docs. - Accessible by construction. With reduced motion on, the final frame shows with all captions. The text transcript lives in the page once, controls appear after hydration, and the animation pauses when it scrolls out of view.
- Cheap. Each explainer is about 3 KB gzipped, with no new dependency, and it hydrates only when it scrolls into view.
One checklist for every change
Whether the change is a paragraph, a screenshot or a new animation, it goes through the same checklist before it ships. Then two independent reviews run, one on quality and one on security, by agents that didn’t write the code. Nothing lands until we decide it should.
That sameness is what lets everything else move fast.
What’s in the checks
The gate is a build, unit tests, a type check, and a link and image check over the built site. The two reviews are a principal-engineer review and a security review. The pull request stays a draft until we decide to land it.
What a system gives product marketing
- Screenshots that match the release, because they’re captured from it.
- Safe to publish by default. Demo company names, no customer data on screen.
- Reusable assets. Every animation has a text version in the docs, and the recording script turns any of them into a clip with a poster frame for a launch post.
- One consistent look. Same viewport, same theme, every time.
- Accessible by default, for screen readers and for people who prefer reduced motion.
- A review before anything goes public.
How it got built
We built this with Claude Code, working with several AI agents in parallel. The work splits into independent pieces: screenshots, each animation, the checks and the reviews can happen side by side. A new animation is small because they share their building blocks. A new admin screenshot is a re-run. People keep the judgment calls: what counts as customer information, and when to ship.
How the agents were organized
One main session coordinated, and subagents worked in parallel on capture, one explainer each, audits and reviews. Each had its own files and a rule that every claim needs a source. The hook, frame and stylesheet are shared across the explainers, so a new one is one component and one tag in a doc.
What it came to
More than forty screenshots refreshed or added, new analytics docs, corrections across the existing ones, animated explainers, and nine new automated tests. Everything passed the checks before it merged.
The next step is a narrated walkthrough. The script and storyboard are written, and an ElevenLabs voiceover and music come next, so the same clips can play as one short video.
See it live in the Swip Tools docs, or read the case study for the project side of the story.