Screenshots Rot. Ours Regenerate.
How mockups built from your app's real compiled CSS keep documentation screenshots accurate through redesigns, without anyone opening a screen recorder.
A designer moves the primary button from the top right of the settings panel to a sticky footer. It is a good change, it takes an afternoon, and it ships on a Thursday. On Friday, every screenshot in your help centre that shows a settings panel is wrong. Not deleted, not broken, not flagged - just quietly, confidently wrong, sitting under step three of eleven different articles telling people to look somewhere the button no longer is.
Nobody will fix them, and everybody knows nobody will fix them. That is why most help centres are text.
The maintenance cost is the whole story
Screenshots are not hard to make. They are hard to keep, and the difference is what determines whether a help centre has any.
Taking one is a couple of minutes: set up the state, get the window to the right size, capture, crop, annotate, upload. Doing that once for forty articles is a bad week. Doing it again after every visual change is a permanent tax nobody has budgeted for, so what actually happens is that a team screenshots everything at launch, ships, and then never again. The images decay from asset to liability at whatever rate the product moves.
The perverse outcome is that the teams shipping fastest end up with the worst documentation. Their screenshots go stale quickest.
Rendering instead of capturing
So we do not capture screenshots. We render them.
During project detection, the analyzer compiles your project's actual stylesheet and extracts its design tokens - the real colour variables, the real type scale, the real spacing and radii, whether they come from Tailwind config, CSS custom properties, or a framework theme. That bundle is cached for the project. When an article needs an illustration of a settings panel, the skill builds an HTML mockup of that panel using your tokens and renders it with Chromium.
The result is not a photograph of your app. It is a reconstruction, drawn with your app's own design system, of the specific screen the step describes.
Two things follow from that, and they are the point of the whole approach. First, the mockup is grounded in source rather than memory - the button label comes from reading the template, not from guessing what a save button is usually called. Second, and more importantly, it is cheap to redo. Regenerating an image costs a render, not a human afternoon, so "the design changed" stops being a catastrophe and becomes a job.
What this doesn't get you
It is a reconstruction, and reconstructions have limits I would rather state than have you discover.
A mockup will not show your actual data, your actual account, or the particular empty state a real user hits on day one. It shows the structure of the screen with plausible content in it. For a step that says "click Update in the top right", that is exactly right. For an article whose whole point is what a specific chart looks like when it has three months of real data in it, a reconstruction is the wrong tool and you should upload a real screenshot. The editor lets you, and we have not tried to make that hard.
Fidelity also tracks how conventionally your app is built. A project with a compiled Tailwind config and a clear component structure reconstructs beautifully. A twelve-year-old codebase with four generations of styling and inline overrides reconstructs approximately, and the output looks like your app in the way a good sketch does rather than the way a photograph does. That gap is narrowing but it is real, and it is worth checking the first few before trusting the rest.
Highly dynamic canvas-rendered interfaces - a map, a video editor, a game - are outside this entirely. We vendor frame stylesheets for a few of those cases, but the honest answer is that a render cannot show you what a canvas draws at runtime.
What changes when images are cheap
The interesting effect is not on quality. It is on coverage.
When each screenshot costs twenty minutes of a person's day, "which steps deserve an image?" is a rationing question, and the answer is always "the first three". When it costs a render, the question dissolves. Every step that benefits from a picture gets one, including the boring ones in the middle of long flows where people actually get lost.
Look at your five oldest help articles and check whether the screenshots still match the product. Whatever that ratio is, it is the tax you have been paying quietly.
About the Author
Simon Moxon has been building SaaS companies since 2009. He's scaled teams to 20+ people, hit £2m ARR, and learned most of the lessons the hard way. Now he's building SupportPages.io - help docs that write themselves when you ship code. He writes about what's changed in SaaS and what hasn't.