I’ve been around long enough to see the rise of design tooling that promised speed, alignment and closer collaboration. Figma has become the default in most places. It’s visual, collaborative and powerful. But for me, it and all the others never really delivered what mattered most — real understanding.

Because here’s the truth. A Figma prototype isn’t real.

It might look good. It might be polished. But it’s not usable. It doesn’t behave like the real thing. It doesn’t exist in the real world and it doesn’t help you truly understand what a user is going to go through.

You can’t fake interaction.

When someone’s using a Figma prototype on a shared screen or in a controlled test, they’re not using it in their kitchen on their phone. Or on the move. Or with limited connectivity or access needs. They’re using it in a vacuum. And in my experience, that’s where insights go to die. I’d go as far to say that when communicating with stakeholders on a design in figma, the conversations can get stuck in the minutia of UI and visual design and too far away from the usability or user needs being met.

A code prototype changes that.

When you prototype in code, the thing you’re testing is real. It works in the browser. It works on any device. It responds to real-world variables. It lets people use it in the environments they’re actually in. At home. On the train. On a slow connection. With screen readers. With one hand.

And that’s where the learning happens.

The moment you see someone interact with something real, something that responds, moves and feels like ‘the thing’, you see what’s working and what’s not. You don’t need to guess. You don’t need to interpret. You just observe.

This isn’t about writing production-level code. It’s about creating something functional or ‘just enough’ to generate real feedback. To test assumptions. To validate or invalidate user needs. To find the sharp edges before you iterate and move onto the next thing.

And the best part? It’s faster now.

With agentic coding and mature design systems, you can build a code prototype in less time than it takes to wire up an advanced Figma prototype. You can reuse components, scale layouts and get something interactive in front of someone in days if not hours.

Yes, someone will say, “It’s not about the tool or type, it’s about the learnings you gain.” And I agree. But let’s be honest. The speed at which you get to something real matters. The sooner you’re testing the thing that’s close to what users will have, the more useful that learning will be.

And yes, I’ve heard you too. “It was never about the prototype tool, it was always about the assumptions.” Absolutely. Assumptions are at the core of all of this. But how you test them matters. A code prototype lets you test assumptions in a real environment with real users. It lets you see how those assumptions hold up when the conditions aren’t controlled. That’s what makes the insight richer. That’s what makes the feedback useful.

I’ve done this multiple times. I’ve had my teams do it. Sometimes what is built is rough, that’s fine. Sometimes it needs a reset, that’s fine too. But we always learn more than we would from a static prototype. Every time.

There’s a tiny amount of folks doing this in comparison to the whole and if you’re serious about building good products and services and you want to learn faster, test wider and build more confidence into your delivery, code prototypes are the way forward.

They’re not perfect. But they’re real. And real beats pretty every time.