The standard process is sacred: research, wireframe, design in Figma, hand off, build. We've stopped following it. For a growing share of our work, we now prototype directly in code, building real, interactive features first, and only go into Figma to refine once we know the thing actually works.
This isn't a rejection of design. It's a recognition that a static mockup hides the most important question: how does this feel when it's real?
The Problem With Mockup-First
A Figma file is a beautiful lie. It looks finished, but it can't tell you:
- How the interaction feels with real latency and real data
- Whether the empty state, the error state, and the loading state hold up
- What happens when the content is twice as long as the placeholder
- Whether the idea is even technically sensible
So you design something gorgeous, hand it off, and discover in build that it doesn't work, or doesn't feel right, and now you're redesigning with sunk cost pulling against you. The mockup looked done, so changing it feels like failure rather than learning.
What Changed
The reason mockup-first made sense was simple: building was slow and expensive, so you de-risked on cheap pixels first. That math has changed. With tools like Claude Code, we can stand up a working, interactive feature in the time it used to take to make a clickable prototype.
So we build the real thing: rough, but real. We click through it. We feel the latency. We see how it breaks. We learn in an hour what a mockup would have hidden for a week. Then we take that knowledge into Figma and design with confidence, because we already know what's true.
When Figma Still Wins
We're not zealots about this. Figma-first is still the right call when:
- The visual direction is unsettled. If we're exploring brand, mood, and aesthetic, Figma is faster for divergent thinking.
- We need stakeholder buy-in before building. A polished mockup communicates intent to non-technical clients better than a rough prototype.
- The work is primarily visual, like a landing page or a brand system, where there's little interaction to discover.
The point isn't "never use Figma." It's "stop using it to answer questions only a working build can answer."
How We Actually Work Now
In practice it's a loop. We prototype the risky, interaction-heavy parts in code to learn how they behave. We design the visual and brand-heavy parts in Figma. And the two inform each other constantly: what we learn in the prototype reshapes the design, and the design pulls the prototype toward polish.
The old process treated design and build as a relay race with a clean handoff. We treat them as a conversation. The result is fewer expensive surprises, less rework, and products that feel right because we felt them long before we called them done.
