The tools finally caught up

Most product teams still follow the same prototyping loop: design a mockup, present it, get feedback, iterate in Figma, then hand it off to engineering to rebuild in code. It works, but there's a lot of translation happening between tools. Context gets lost, fidelity shifts, and the thing you shipped doesn't always match the thing you explored.

I've started to think the tooling has caught up to the point where code prototyping is a genuinely viable alternative for a lot of product work. It belongs alongside design tools, and sometimes earlier in the process.

If you have a design system in place, you can prototype directly in the same code that becomes the product, reducing fidelity gaps and the need to rebuild it.

Most teams still don't do it, and I think it's because they've conflated two separate problems: the problem of exploring ideas quickly, and the problem of not having shared building blocks. Solve the second one and the first one gets dramatically easier.

The design system unlocks it

When your team has a design system, even a modest one, prototyping in code becomes fast. You're not starting from nothing. You've got your typography, your spacing scale, your colour tokens, your core components. A button looks like a button. A card looks like a card. You're composing, not crafting from raw materials.

Prototyping in code becomes slow when you're making decisions about visual fundamentals while simultaneously trying to explore an idea, which is why reaching for Figma feels more natural. If those decisions are already made and encoded in reusable components, the speed gap between a Figma frame and a React component shrinks to almost nothing.

I'd argue it inverts because a code prototype does things a Figma mock never will: it scrolls, responds to real data, handles edge cases you'd never think to draw and runs on an actual phone. You can feel how it works instead of imagining it.

You don't need to build one yourself

Until recently, prototyping this way often meant spending months building a bespoke design system first. Teams would look at the approach and think "great, but we'd need a design system first, and that's a six-month project."

shadcn/ui and Radix now provide accessible, well-structured primitives that you can style however you want. shadcn in particular gives you the components as actual code in your project rather than as an opaque dependency, so you can modify or replace any part of them.

For most teams, especially smaller ones, a consistent set of building blocks is enough to move quickly without a design system team or a Storybook with 400 documented variants. These tools provide that on day one.

You might not even need those

I'll go further. For a lot of prototyping work, you don't even need shadcn or Radix. Tailwind CSS on its own, with a sensible set of colour and spacing tokens, gets you surprisingly far. You're not building a component library for a 200-person engineering team. You're exploring whether an idea works.

A div with some padding, a text size, a background colour, and a border radius. That's a card. A flex container with gap spacing. That's a layout. You're not going to win a design award with it, but you're going to learn whether the concept holds up, whether the information hierarchy makes sense, whether the interaction model feels right. And you're going to learn it in an hour, not a week.

The fidelity comes later, but the structure is real from the start. Keeping the work in one medium means the prototype can grow into the product through iteration, without losing information at handoff points or rebuilding it elsewhere.

The AI slop problem

Tools like v0, Bolt, and Lovable have made it trivially easy to generate a UI from a prompt. That's impressive, and genuinely useful for getting started. But if you've browsed Product Hunt lately, you've probably noticed that everything is starting to look the same. The same card layouts, the same gradient backgrounds, the same rounded corners and shadowed containers. It's slop. Competent, functional slop, but slop.

That's what happens when you generate a UI with no constraints. The model reaches for the average of everything it's seen, and the average is bland.

Even a lightweight design system changes the equation by giving the AI your tokens, spacing and type choices. It composes within a system that already has a point of view instead of designing from scratch, so the output starts from a much better place even though it still needs editing.

Teams producing distinctive work do the foundational thinking about how their product should look and feel, then use these tools to move faster within those constraints.

Why this matters beyond speed

Working in the same medium also changes how a team collaborates. Designing and building become one continuous process, so designers who can read and adjust code, even if they're not writing it from scratch, get tighter feedback loops. Engineers who are involved earlier make better architectural decisions because they understand the intent as well as the spec.

I've seen this work best when the boundaries between designing and building were blurry and people thought about the problem together, in the same material, at the same time.

Where Figma still fits

Figma is still brilliant for visual exploration, for trying out wild directions, for communicating concepts to people who aren't technical. If you're redesigning a brand or exploring a completely new visual language, a design tool is absolutely the right call.

For most product work within an established product and visual language, the fastest path from idea to validated prototype runs through your codebase rather than through a mock.