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. Not instead of design tools, but alongside them, and sometimes before them.

If you have a design system in place, you can prototype directly in code. The same code that becomes the product. No fidelity gaps, no rebuilding. The prototype is the thing.

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.

This is the bit people underestimate. The cost of prototyping in code isn't writing the code. It's making decisions about visual fundamentals while simultaneously trying to explore an idea. That's what makes it slow. That's why reaching for Figma feels more natural. But 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 the code prototype does things a Figma mock never will. It scrolls. It responds to real data. It handles edge cases you'd never think to draw. It runs on an actual phone. You're not imagining how something will feel, you're feeling it.

You don't need to build one yourself

Here's the thing that's changed in the last few years. You don't need to spend months building a bespoke design system before you can prototype in code. That used to be the barrier. Teams would look at this approach and think "great, but we'd need a design system first, and that's a six-month project."

Not anymore.

shadcn/ui exists. Radix exists. Headless component libraries give you accessible, well-structured primitives that you can style however you want. shadcn in particular has changed the game because it gives you the components as actual code in your project, not as an opaque dependency. You own it. You can modify it. You can rip bits out and replace them.

For most teams, especially smaller ones, this is more than enough. You don't need a design system team. You don't need a Storybook with 400 documented variants. You need a consistent set of building blocks that let you move quickly, and these tools give you 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. The important thing is that the structure is real from the start. You're not translating between tools. You're not losing information at handoff points. The prototype grows into the product through iteration, not through rebuilding.

The AI slop problem

There's a related issue worth mentioning. 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.

This is where having a design system, even a lightweight one, changes the equation. When you prototype in code against your own tokens, your own spacing, your own type choices, the AI is working within your taste, not its defaults. You're not asking it to design from scratch. You're asking it to compose within a system that already has a point of view. The output still needs editing, but it starts from a much better place.

The teams producing distinctive work right now aren't the ones generating UIs from blank prompts. They're the ones who've done the foundational thinking about how their product should look and feel, and then using these tools to move faster within those constraints.

Why this matters beyond speed

Speed is the obvious benefit, but it's not the most important one.

When you prototype in code, everyone on the team is working in the same medium. There's no "design phase" and "build phase." There's just the work. 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, not just the spec.

The best product work I've been part of has always had this quality. The boundaries between designing and building were blurry. People were thinking about the problem together, in the same material, at the same time.

The real question

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.

But for the vast majority of product work, where you're building features within an established product, within an established visual language? The fastest path from idea to validated prototype runs through your codebase, not through a mock.

The tools are there. The barrier isn't technical anymore. If you've been hesitant to try this, now's a good time to start.