The Design Engineering Transformation
Rebuilt RockWallet's design-to-code pipeline from "Figma as reference" to a versioned npm package — 12 components, Code Connect mapped, ~80% less UI rework.
One component. 14 tickets.
For ten months the same pattern repeated inside RockWallet's product builds. A designer would finish a screen in Figma, hand it to engineering, and the screen would come back wrong. Not catastrophically — a few pixels of spacing, the wrong font weight, a color one step off the token. Each miss generated a ticket. The ticket bounced between design, dev, QA, UAT, and back. By the time the screen was "correct," we'd burned weeks of cycle time on work that should have been done once.
The Jira archaeology was painful — for example, RPB-12707, lifted verbatim: "Asset UI in 'Your assets' widget in the homescreen is not matching with the figma." That's not a bug. That's a system failure.
Why discipline can't fix it
The pipeline assumed engineers could interpret Figma. Every screen handed off to a developer triggered hundreds of micro-decisions per render — which spacing token, which exact color value, which font weight, which border-radius variable. Each interpretation was a chance to drift. Multiplied across screens, builds, and platforms, drift compounded into UI inconsistency, QA noise, and an endless backlog of "doesn't match the figma" tickets.
The temptation is to blame execution — to ask engineers to be more careful, or to add a visual QA gate. I rejected both. The shape of the problem said something else: it's not the team, it's the system. When the cheapest path through the workflow produces the wrong outcome, no amount of discipline fixes it. You have to change the path.
The thesis I kept coming back to: a design system isn't a style guide; it's a contract. A style guide says here is the right spacing. A contract says the only spacing you can use is the right one. If the developer has no choice, the drift can't happen.
The first move was to make the component the spec, not the reference. I built @mnee-ui/ui as a real, versioned npm package authored in Tailwind v4, with vanilla utility classes and a small set of conventions (cn() for class merging, Record<Variant, string> for variants — no switch statements, no abstractions that obscure the markup). The same repo doubles as the publishing source and the Next.js docs site, so the artifact a developer installs is the artifact a designer can preview on the web.
Twelve components shipped at v0.1.1 — Button, Badge, Card, Input, Toast, Icons, Banner, Table, Drawer, Modal, Alert, CodeBlock. Each one is QA'd by design before it leaves the repo. Engineering doesn't QA visuals on first integration — the component is already correct.
The second move was to close the Figma-to-code loop. Code Connect mappings let a developer one-click from a Figma node into the exact code usage — <Button variant="primary" size="large">Label</Button>, with the right props pre-filled. No searching, no asking, no interpretation.
The Figma library file (named "ShadCN" for its primitive vocabulary — though the code uses zero ShadCN runtime) is the source of design truth; the npm package is its code mirror. Mappings aren't a "later" — they're shipped alongside each component, which is what makes the system non-optional in practice.
When engineering didn't have bandwidth to migrate the consuming product (merchant-portal-frontend) from Tailwind v3.4.18 to v4, I refused to let adoption block. I stood up a product-owned dogfooding harness: a local clone of the portal on a working branch, upgraded with a single migration commit. The harness proved the system worked in a real consumer codebase before asking engineering to commit upstream.
Key decisions
- Design owns publishing. I publish
@mnee-ui/uipersonally. The team that designs the contract is the team that ships it — there's no handoff where drift can enter. - Vanilla Tailwind v4, no ShadCN runtime. The Figma file is called "ShadCN" because the primitives draw from that vocabulary, but the code has zero ShadCN dependencies. Simpler, lighter, easier to maintain.
- Skip app-specific components. The published package explicitly excludes Redux-bound things (auth, merchant, BalanceCard, TransactionRow). Those belong in the app. The system stays primitive; products compose on top.
- Code Connect from day one. Mappings ship alongside each component, not as a follow-up. The Figma → code link is what makes the contract enforceable.
- Product-led dogfooding via a local v4 fork. Rather than wait for engineering's roadmap, I stood up a private validation harness. It removed the "but does it actually work in the portal?" objection from every leadership conversation.
- Two design systems, same model. MNEE UI for MNEE Pay (live, twelve components). Prometheus for RockWallet 2.0 (Figma + native mirrors live, web package gated on Whiteboard graduation). Same playbook, two products.
- Pitch the model, not the work. The 25-slide executive deck doesn't ask leadership to admire components. It asks them to acknowledge a strategic shift in how the company ships UI — and to remove the one remaining unlock (the upstream Tailwind v4 migration).
What shipped
Inside the system
Reflection — the system only works as a product
The non-obvious lesson was that the design system only works as a product. The moment we treated it as a sibling deliverable to the apps that consume it — with a version number, a docs site, a publishing cadence, and an owner — most of the political friction dissolved. The technical work was the easy part. The harder part was building the artifact that lets a CEO see why this is strategic, not aesthetic.
The next phase is operationalizing the deck's ask: getting the Tailwind v4 migration onto an engineering roadmap, formalizing design ownership of the system, and graduating the first Prometheus component out of the Whiteboard into a published @rockwallet/ui consumed by the native apps via WebView.