How we cut our frontend codebase by reusing the UX team's code directly

Mrinal Trivedi3 min read

Every screen used to go through the same relay: design shipped a Figma file, engineering read it, then spent real time figuring out what was actually feasible in production before writing a single line. Anything Figma couldn't represent, like a loading state, an edge case, real data instead of placeholder text, got decided by engineering after the fact, often differently than design would have chosen.

Asking design to annotate every edge case more thoroughly was the obvious fix, and it didn't hold. A spec can describe a static state precisely. It can't tell engineering how a layout should behave once real data, real latency, and real errors are in it. The gap wasn't documentation. It was that design was designing for a medium, Figma, that stops at the pixel.

The approach

The UX team started building the frontend for their own designs directly, using Cursor to write the component code instead of only producing static mockups. That changed what crossed the handoff:

  • Design's output became a working component with real states (loading, empty, error), not a picture of one state.
  • Engineering's job shifted from interpreting a static file to reviewing and hardening real code: performance, accessibility, integration with existing data layers.
  • Feasibility questions got resolved by design while building, since Cursor surfaced constraints, like a layout that couldn't handle dynamic content or a component with no accessible state, at build time instead of at review time.
We stopped guessing what design meant and started reviewing what design actually built.
Mrinal Trivedi

What it got us, and what it didn't

Seventy percent of the frontend components shipped this quarter started as UX-authored code from Cursor, with engineering reviewing and hardening rather than rebuilding from a spec, measured by component count across the shared package.

It wasn't a clean win everywhere:

  • Components with heavy client-side state, like the task board and the calendar view, still needed engineering to lead. Design-authored code handled layout and interaction well; it didn't model complex state management on its own.
  • Code quality varied. Some UX-authored components needed real refactoring before they were production-ready, not just a review pass.
  • Review load shifted, it didn't disappear. Engineering now reviews more code from more people, which is a different job than writing it, not a smaller one.

Design writing real code closed the feasibility gap. It didn't close the ownership question: who's accountable for a production bug in a component design wrote. That's the harder problem to solve next.

Share this

Sign up for early access to Neo