Statecraft

Depreciating images

Every team keeps a picture of how its product is meant to work: how you sign up, what checkout does, what happens when a card gets declined. The funny part is where it lives. A FigJam board nobody’s opened since March, a slide in an old deck, a Notion page, a photo of a whiteboard taken at a funny angle. More often than not, somebody’s memory.

It starts depreciating the minute you draw it, because the product keeps shipping and the map doesn’t move. So the questions that matter most (“what actually happens when this payment fails?”, “what did we change last release?”) get answered from memory, or not at all.

Lessons learned

The first version wasn’t Statecraft at all. It was “sync your design system, export clean code”, built on top of a little canvas tool I’d made for myself.

I put real prototypes in front of designers and PMs and got a polite shrug: for them it was the same job they already did, minus the odd afternoon syncing a button.

What changed my mind was a friend, a PM at a Series A, who wasn’t worried about how shipping change drifts the design system, she was worried about who ships. Engineers pushing their own “designs” to production, a CEO reviewing PRs, people merging 10,000-line pull requests that quietly broke a journey nobody was watching.

So the journey became the product, and the sync shrank to a clever implementation detail and little side-feature for designers.

The second wrong turn was subtler. If the journey is the point, import all of it! The first importer dropped your entire app onto one canvas. Genuinely impressive for about thirty seconds! Absolutely unreadable afterwards. the transitions tangled like wild telephone cords; near-identical states buried the differences that mattered; and 500 isolated iframes (one per state, so real modals and alerts behave properly) each running a frontend bundle almost melted my laptop.

The fix was to shrink the unit. One journey per project. Twenty iframes, and a graph you and anyone you’re working with can actually follow.

Onboarding was also full of lessons. My first release would ask you, a stranger, for your company’s GitHub repo about ninety seconds after you arrived. I replaced it with a playground of around thirty open-source design systems you can poke at straight away. Activation went from nobody doing basically anything to people genuinely creating projects.

It’s the real thing, not a mockup

This is the part I care about most. Statecraft renders your live React or Vue components, so what you poke at on the canvas is exactly what you’d ship, down to the tokens and variants the design system actually carries.

Select an element and its real props open in a panel; drop into the code and change it directly; wiring a transition is just saying what a thing does when it’s clicked, so a static layout quietly becomes a flow you can click through.

Edit in the browser, in your own editor through a synced folder, or by handing it to whatever coding agent you already use (Claude Code, Cursor, take your pick), and the canvas catches up within seconds. It’s multiplayer too: live cursors, comments pinned to a single button, and snapshots you can share as a link with no login.

One pair of hands

Every layer of this is mine: the research that found the problem, the brand and marketing site, the canvas and its editing model, real-time collaboration on a sync engine, a Rust daemon and a menu-bar app that watch a local repo, plus authentication, billing, email and analytics.

Including the bit I’m worst at. I hate outreach, the LinkedIn messages and the polite pestering of old colleagues. Still, it has to be done. So I’m doing it.

Where it stands now

Live, in beta, with real users and plenty of demos, but no full teams on it yet. I’m looking for design partners in my spare time.

---

Tools: React, Vue, TypeScript, Convex, Yjs, Rust, Tauri, the Anthropic API, Figma, Vercel and Fly.io.