Prototyping in code means the designer builds the product instead of drawing it: the same person does discovery, interface and working software, so the prototype is real and the MVP is already started. This is the story of how I ended up working this way, what it buys a founder, and where the limits are.
Every designer knows the moment. You hand over a beautiful file. Weeks later something comes back that is technically your design and spiritually not. The hover states are gone. The empty state nobody drew is a gray rectangle. The animation that made the whole thing feel alive was "out of scope".
Nobody did anything wrong. That's the point. The handoff itself is the bug: the design lives in one person's head, gets flattened into pictures, and then a second person has to reconstruct not just what it looks like but what it was supposed to feel like. The details that fall off the truck are always the ones that made it good.
For a big company with a mature product, that's an acceptable tax. For a founder trying to learn whether anyone wants their idea, it's fatal: the tax is paid in months, and months are the one currency an early product doesn't have.
The project that settled this for me was Mhatzmihim. The question was simple: would people actually use a voice feature? The old way to answer it: brief, wireframes, screens, handoff, build, test. Months. We did it in 24 hours - from the idea to a working voice-feature prototype, tested with real people, because there was nothing to hand off. I designed it and I built it, and the prototype users touched was the actual thing.
That test taught us more than a quarter of meetings would have. And it taught us early, when changing direction was still free.
That's the real argument for a designer who codes. It's not speed for its own sake. It's that learning moves to the front of the project, where it's cheap.
A clickable mockup answers one question: what does it look like. A working prototype answers the questions that matter: does the flow make sense when the data is real? What happens on a slow phone, with a long name, with no results? Does a five-year-old find the button?
When I was designing the Hachi Eitan game for Hop! Channel, the important findings came from watching real kids use a real build: we removed whole parts of the flow, rewrote voice-overs, and added one deliberate extra tap at the moment a child chooses an emotion, so the choice couldn't happen by accident. None of that shows up in a mockup. All of it showed up in the first testing session.
There's a bonus at the end of this road: the prototype is not thrown away. It's the start of the MVP. The work compounds instead of restarting.
If you want one artifact that explains how I think, it's Pixel Poke: a Chrome extension I designed and built that turns any live web page into a design canvas. Click elements, move them, restyle them - and when you're done, it hands developers the real CSS. Not a screenshot with arrows. The actual values.
I built it because I lived on both sides of the wall it removes. Designers think in the medium; developers ship in code. Pixel Poke lets the design happen directly on the real thing, so the translation layer - the place where everything usually gets lost - simply isn't there.
This way of working is not the answer to everything, and pretending otherwise would make the rest of this article worthless.
One person who designs and builds is the fastest route from zero to a tested MVP. It is not how you run a forty-person product org, and it shouldn't be. The honest version: I get you to the point where you know the product deserves a team. Then the team inherits a running product, real user evidence and a working codebase - which is a much better inheritance than a folder of screens and a prayer.
And some products need deep engineering from day one: heavy infrastructure, strict compliance, native performance. A designer-builder is the wrong hire for those, and I'd say so in the first call.
You get one person for the messy early stage: discovery, UX, interface, prototype, MVP. You see something working in days, you test with real users while opinions are still cheap, and every iteration lands in the same artifact that becomes your product.
I build with AI every day, which is part of why one person can cover this much ground now. The details of how engagements run are on my hiring page. The projects that taught me all of this are on the projects page.
A product designer who codes designs the product and builds it: the same person does discovery, flows, interface design and the working software. Instead of a design file handed to a developer, the prototype itself is real code that users can touch.
A Figma prototype proves what a screen looks like. A code prototype proves what a product feels like: real data, real states, real edge cases, on a real device. For an early product trying to answer 'does anyone want this', the second answer is worth ten of the first.
For one static screen, drawing is faster. For a flow with real states, code wins quickly: there is no handoff, no redrawing after feedback, and the prototype is already the start of the MVP. With AI-assisted coding, the gap got much wider in code's favor.
Everything that lives between the screens: states, timing, the way an interaction feels, empty and error cases, and the hundred small decisions nobody drew. Each lost detail is either a bug, a meeting, or a compromise nobody chose on purpose.
At the 0 to 1 stage, one person who designs and builds is usually the fastest way to a tested MVP. As the product grows, scale it with specialists: the designer-builder hands over a running product and real user evidence, not a folder of screens.
A Chrome extension I designed and built that turns any live web page into a design canvas: click elements, move them, restyle them, and hand developers the real CSS instead of a screenshot with arrows.
My fastest end-to-end was Mhatzmihim: from an idea to a tested voice-feature prototype in 24 hours. A clickable first version of most ideas takes days, because the prototype and the product are the same artifact.