Sorb — Figma-to-React design-token bridge

What I built

A design-token bridge between Figma and React: a Figma plugin, a React SDK, a bridge server, and a capture/resolver layer on a shared contract, plus a hosted, multi-tenant control plane. Edit a token in Figma and see it live in your running React app before you merge.

It runs two ways from one codebase: a free, local, single-tenant loop (`sorb dev`) and a paid, hosted, multi-tenant platform. The same binary flips modes.

• The connectivity layer: framework adapters for six UI stacks, one-click browser pairing for the plugin, live diagnostics that name the failing side, one-click GitHub pull requests, and hosted + local MCP servers for agents.

Where it came from

Sorb wasn't a cold start. It's the productized version of a pattern I'd already proven and a pain I'd already lived at BuzzFeed.

• The architecture, proven: for the Callout platform I designed a JSON contract where one data structure served four jobs: form generation, validation, live preview over browser events, and the production render. A teammate built the renderer's first pass against that contract, and it held across the team boundary. Sorb generalizes the same shape: a design surface pushes changes over an event channel, and you preview them in the real renderer.
• The gap, seen formally: I worked with our VP of technology, a senior engineer, and design leadership to evaluate how Figma could stay connected to our codebase, and we found the existing tooling lacking core features. On my own time I started building and evaluating ways to keep the two in sync. That work became Sorb.
• The pain, felt personally: shipping a shared-component change meant a version bump, a publish, then updating and deploying up to three consuming services just to see it (Foundation UI has the full story). Sorb's core promise erases my own old bottleneck: see a proposed token change in the running app with no publish and deploy cycle.

How it works

1. A designer opens the Sorb plugin in Figma and clicks sign in. The browser opens, a device pairing hands the plugin a scoped key, and it's connected. No servers, URLs, or keys to paste. (The free local bridge still works with zero account for self-hosted setups.)

2. The designer edits a token variable and clicks Preview. The plugin posts the proposed tokens to the bridge.

3. The React SDK's provider fetches them, applies them as CSS custom properties on `:root`, and live-polls for updates, so the running app re-themes in place. Framework adapters carry the same tokens into Tailwind, MUI, Mantine, PrimeVue, and Angular Material apps.

4. If the bridge isn't reachable it falls back silently to the committed tokens: preview never breaks production. And when a preview fails, diagnostics name which side owns it. The SDK answers a ping with a fingerprint, and a diagnosis panel points at plugin, bridge, app, or cloud.

5. A token version ships as a GitHub pull request with one click.

How I built it

Polyrepo, by design. A tree lifecycle (Seed, Juice, Leaf, Canopy) plus a shared Core contract and a Cloud control plane, each its own repo so any package can be public or private independently. JavaScript only (types are JSDoc typedefs), built with esbuild. Never TypeScript, with one deliberate exception: the hosted Cloud plane is a Next.js app.

• Juice is the bridge, a Hono server (bin `sorb`, port 7777) that's a dev-dependency only and never touches production. The same binary turns on auth, entitlements, and scoped CORS the moment a database URL is set.
• Seed captures Storybook via Playwright and resolves tokens through Style Dictionary (DTCG).
• Canopy is the Figma plugin (sandboxed `code.js` + iframe `ui.html`); Leaf is the React SDK (provider + hooks).
• MCP servers expose the whole thing so agents can drive it.

Questions this project answers

You describe yourself as working at the seam where design meets engineering. What does that look like in practice? Sorb is that seam made into a product. The problem it solves is that a token approved in Figma gets re-typed by hand in code and quietly drifts, and nobody notices until users do. So instead of anchoring on the design file, I anchored on the running app: a designer edits a token in Figma, the plugin posts it to a local bridge, and the React SDK applies it as CSS custom properties so the real components re-skin live before anyone merges. It gives design and engineering one shared source of truth they can both see moving.

When AI proposes a change, how do you tell a good one from a merely plausible one? By checking it against something that can't lie. In Sorb every AI feature rides the live binding graph and is verified against the actual running app, so a proposed token change is judged by what it does on real components, not by the model's confidence. For the first write feature, a contrast fixer, the judge is the deterministic WCAG contrast math, not the LLM. The running app and the math are the oracle; the model only proposes.

What does responsible AI look like when the model is confidently wrong? The loop is AI proposes, a human reviews, and the live app verifies, with no auto-apply anywhere. I was also careful not to overstate the guarantee: verify is a check-then-merge habit, not an enforced CI gate, and I keep the product copy honest about that distinction. On the reliability side the preview fails safe by design. If the bridge isn't running, the SDK silently falls back to the committed tokens, so an experiment can never break production.

Is Sorb actually shipped, or still a prototype? The core is shipped: four @sorb packages published to npm through OIDC trusted publishing, a React SDK and Figma plugin in real use, and a multi-tenant hosted platform running live with a public demo on self-hosted infrastructure. I'm honest about what's still branch-local: the deeper AI write features are built and gated, not merged, because I won't market a capability the product doesn't actually run yet. The bridge, the SDK, the plugin, and the hosted plane are real and deployed today.

Results

• Published to npm: @sorb/core, @sorb/seed, @sorb/leaf, @sorb/juice (via OIDC trusted publishing).
• A live multi-tenant hosted platform (app.sorbcloud.com) with a Token Explorer workbench, version compare, and token-version-to-PR shipping.
• try.sorbcloud.com: a no-install interactive tour with the real plugin and a real storefront, the bridge played by a service worker. Ninety seconds, no account.
• Six live demo storefronts (Bootstrap, Tailwind, MUI, Mantine, PrimeVue, Angular Material) re-themed by one token set.
• A hosted MCP server at mcp.sorbcloud.com so agents can read and propose tokens.
• A defined category and positioning distinct from Figma Code Connect: a 100% free, self-hostable core with a hosted moat.