Why we design in code.

Picture a Figma file a team shares for review. One screen, three frames side by side, desktop, tablet, and mobile, the same content poured into three different widths, and every one slightly out of sync with the other two. A button got renamed on desktop and nobody told mobile. The tablet frame has a card that doesn't exist anywhere else. Somebody spent days on this, and not one pixel of it will survive the trip to production.

The common belief is that this is just how design works. You draw it first, you hand it over, and engineering rebuilds it in code. The drawing is the safe place to decide things, and the code comes after.

We used to believe that too, and this is not said by people who never learned the tool. We built the libraries. At CEMEX we lived in Sketch, maintaining the symbol libraries that kept a lot of designers drawing the same button the same way. At BigCommerce we owned BigDesign, which meant the whole package: the React component library, the pattern library, and the Figma library that mirrored all of it. We know the variants, the auto layout, and the endless negotiation of keeping a drawing of a component in step with the actual component.

The point where code got cheaper than drawing

Once a design system lives in code, as a real component and pattern library with the page types already solved, the list page, the detail page, the settings page with its forms, something flips. Composing a new screen out of those real pieces in code is faster than composing a picture of those pieces in a design tool. Not a little faster. And what you get at the end is not a picture, it is the thing.

The framework is not the point. It happened to be React for us, and the same holds for Vue, for Web Components, for SwiftUI on native. The library is the sledgehammer here. The catch is honest: you need people who know how to code, and a system worth coding against.

We tried to close that gap for everybody else too. At BigCommerce we built a Figma plugin, jokingly named FigCommerce, that read the structure of a Figma file and generated a React app from it, mapping the frames to our components, so the only things left were the logic and the wiring. It worked within limits, and it showed us where this was going: once the drawing is only an input to code, you start asking why you need it at all.

Then AI finished the job

Early AI prototyping tools were built almost entirely on shadcn. If your company had its own component library, and any company big enough to care about design does, you got a very pretty prototype that looked like everybody else's shadcn app, and then spent the afternoon translating it into your real components.

That gap is gone. Today you can build directly against a custom design system, even a poorly documented one, and oh boy, there are some poorly documented ones out there, because the tools read the component code themselves and figure out the props, the events, and the composition patterns the authors never wrote down. The documentation stopped being the bottleneck.

What changes for the people hiring us

This is the part that matters most to a client, because it changes what you receive and when.

• You review the real thing. A working artifact you open from a link, or on an actual phone, instead of a clickable picture with hotspots and a fake scroll.
• Responsive comes along for free. A canvas of fixed frames means designing everything two or three times. In code you design one format, and the library already knows how its grid collapses and its navigation becomes a drawer.
• Real data shows up early. Mockups always faked the data, perfect every time. Real sources return errors, half-empty responses, and the dataset missing exactly the field the design leaned on. Better to meet those in week two than in production.
• The prototype can live inside your product. With a small browser extension, the new idea can run on your actual page, with the real header and the real customer data around it. Nothing ends a design debate faster.

Figma still has a place for thinking out loud, the big boxes and arrows of a flow, a whiteboard with better typography. Excalidraw does that beautifully for free, with the hand-drawn look that tells everybody in the room it is a sketch and not a promise. After that, we go straight to something that runs.

The tool didn't get worse. The medium it was simulating became cheaper to use directly than to simulate. If you are attached to the canvas, that is understandable, a lot of us learned the craft there. In our experience, though, once you see your first idea running on a real phone in the same afternoon you had it, you don't really want to go back to drawing it.