Run it yourself.
Stage1 is free to install from npm. Follow the guide to your first capture. It needs Node 22 (22.15 or later) or Node 24.
Read the guideStage1
See what your product actually ships.
Your design system says one thing. Production says another. Stage1 captures the live product and measures it against your Figma library, your tokens and your source, so the team argues from evidence, not just screenshots.
Free on npm · v0.5.1
The drift is already in production.
Every design system drifts. A token gets overridden to hit a deadline. A component gets forked in one product area. A spacing value gets hard-coded because the right one wasn’t obvious. Nobody decides it. It accumulates.
By the time someone notices, the Figma library, the token file and the shipped CSS describe three different products. The only way to know which one is true is to go and look.
Stage1 goes and looks.
How it works
-
Capture the live product.
Stage1 drives a real browser through the pages you choose, including signed-in journeys, and records the structure, computed styles, tokens in use and accessibility findings for each page, and runs Lighthouse on up to five of them.
-
Measure it against what you declared.
Compare the captured values with your exported Figma file: colour, type size and weight, radius, spacing, border colour and shadows. Library components are checked against the markup that actually ships. Add the source repository and Stage1 reads its routes, components and token patterns beside what rendered. Type sizes are compared per typeface, against the sizes your file declares for each.
-
Share the evidence.
Every value-drift finding links to example pages and identifies the elements that produced it, and every comparison records the exact rule it used. Values the browser supplied, elements that aren’t painted and third-party widgets are reported on their own, never counted as drift. Anything Stage1 couldn’t measure is listed as missing, never counted as a pass. Export a self-contained report the whole team can open without installing anything.
Or look at the whole category.
Give Stage1 a list of sites and it captures each one under the same rules, then lays the results side by side: the style values, structure, structured data and accessibility results each product actually ships. It’s how we research a market before a redesign, and how we write our public drift reports, starting with USWDS.
Evidence an agent can read.
Pixels are not the source.
A screenshot makes an AI assistant reconstruct what the software already knew. Stage1 hands it the page structure, the computed styles and the accessibility findings instead.
It runs as a command-line tool, a local viewer and an MCP server, so Claude, Cursor or any MCP client can start a capture, read the evidence and answer questions about it. Captures run on your machine by default.
Who uses it
- Design system teams checking what actually got adopted.
- Front-end engineers reconciling a codebase with the file it was supposedly built from.
- Product teams that want a measured baseline before a redesign or a migration.
Two ways to start
Or have us run it.
The Drift Audit: we capture your product, compare it with your design files and source, and walk your team through what we found and what to fix first. About two weeks.
Talk to usStage1 reports what it measured and says what it couldn’t. It doesn’t score design quality or certify accessibility. That’s still your team’s judgment, now with better evidence.