Paper: designing without a handoff

Paper↗↗ is the clearest attempt yet to make the handoff problem not a problem, by eliminating the handoff entirely. Every element on its canvas is HTML and CSS. Actual markup, rendered live. Not an approximation, not a vector layer that gets converted. What you see when you drag a box is what a browser would render. There is no translation step when you are done, because there is nothing to translate.

Stephen Haney built it. He is the person who made Radix UI at Modulz before WorkOS acquired the company, which means he spent years thinking about how design systems actually touch code in production. That background matters here. Paper↗↗ does not feel like a tool built by people who observed designers from a distance. It feels like one built by someone who got annoyed enough by the same friction you have and decided to fix it at the root.

The friction, specifically, is this: Figma is a design tool that outputs code via translation. You make decisions in Figma↗↗'s proprietary format and then something (a developer, a plugin, an AI agent) converts those decisions into code and hopefully gets them right. Paper↗↗ skips that. If you change the padding on a card in Paper↗↗, the padding changes in the HTML. There is no version of events where a developer implements it differently, because there is no separate implementation.

For AI workflows this distinction is more significant than it sounds. Figma↗↗'s MCP server gives AI agents three tools: they can read layout data, pull images, and get variable definitions. Paper↗↗'s MCP exposes 24 tools, and crucially, they go in both directions. Figma↗↗'s MCP gives an agent a window into your file. Paper↗↗'s gives it a steering wheel. An agent working in Paper↗↗ can sync tokens from your codebase to the canvas, populate UI with live API data, generate responsive variations, or convert the design to React and commit to GitHub, without you touching it.

None of which is useful if you are doing design work that has nothing to do with shipping code. Paper↗↗ is not Figma↗↗. It does not yet have the component management depth, collaboration features, or design system maturity that Figma↗↗ has accumulated over a decade. There is no world-class pen tool. Haney has been public about that being on the roadmap, not yet in the product. If your workflow involves large teams, complex shared libraries, or handoffs to developers who want precise specs rather than direct code, Paper↗↗ will frustrate you. The alpha constraints are real, not just a disclaimer.

Where it does work is for the designer who is also, functionally, the developer, or who works closely enough with one that the boundary has already blurred. Solo product designers building their own tools. Small teams where the designer opens PRs. Anyone fatigued by the same Figma↗↗-to-developer-to-"that's not quite what I meant" loop who has enough code literacy to appreciate what it means when the canvas is the source of truth. Pencil.dev is working a similar seam, as an IDE extension rather than a standalone canvas — worth looking at both if this problem resonates.

The creative side is the part that does not fit the pitch neatly. Paper↗↗ ships animated shader support, GPU-accelerated effects that would require raw WebGL to replicate anywhere else. It is a different category of visual tool than you would expect from something positioned around code fidelity. Whether that means it becomes the go-to canvas for motion and brand work alongside its development features, or whether it ends up being two half-tools, depends entirely on how Haney evolves it. Based on his public build log, he is aware of the tension.

Free tier exists with 100 MCP calls per week — enough to understand what the tool actually is. Pro is $16 a month on annual billing.