Once a team decides it needs a prototype, a second question arrives that nobody plans for: does it get built in Figma or in code? The answer changes the cost by an order of magnitude and changes what you can learn by more than that. Whether you need a prototype at all is a separate question; this is about which kind, once you do.
What each one can genuinely test
A Figma prototype tests flow and comprehension. Does a person understand what this screen is for, can they find the next step, does the sequence match how they think about the task. For those questions it is excellent, and it is fast enough to revise between two user sessions on the same afternoon.
What it cannot test is anything involving real data, real timing, or real input. Typing into a field, filtering a list, waiting for something to load, an error arriving at the wrong moment, or how a layout behaves at a width you did not draw. Every one of those is faked or absent, and they are exactly where products fail.
A coded prototype tests the experience. Real interaction, real responsiveness, real performance, real edge cases when a name is forty characters long. It is the only way to answer questions about feel, because feel is a function of timing and response rather than of appearance.
Cost, and the honest ratio
A Figma prototype of a meaningful flow is hours. A coded prototype of the same flow is days, and if it needs a backend, longer.
That gap is why the default should be Figma, and why teams that prototype everything in code move slowly for no additional insight. If the question is “is this the right sequence”, paying ten times more to answer it in a browser is waste.
The ratio flips when the question is one Figma cannot answer at all. Then a cheap prototype that produces a confident wrong answer is the more expensive option.
Choose Figma when
The question is about structure, flow, or comprehension. You are testing with users who need to see a realistic surface but will not be entering real data. You are iterating quickly and expect to change it after every session. You need to align stakeholders on direction, where a clickable file is far more persuasive than static screens and far cheaper than a build.
It is also the right choice for anything you expect to throw away, which early exploration usually is.
Choose code when
The interaction is the product. Anything with drag and drop, canvas behaviour, complex filtering, live search, or a node based editor cannot be honestly evaluated in Figma, because the difficulty lives in the responsiveness rather than the layout.
Real data changes the answer. Dashboards and tables look tidy with invented numbers and chaotic with real ones, which is why a chart that works in a mockup can mislead in production.
Responsive behaviour matters. A Figma prototype shows the widths you drew, and the gaps between artboards are where layouts break.
Performance is part of the question, or you need to test with people on their own devices in their own context rather than over a screen share.
The trap: the prototype that becomes the product
The strongest argument for coding a prototype is that it can become the real thing. The strongest argument against is that it usually does anyway, whether or not it was built to.
A coded prototype written to answer a question is not production software. It has no error handling, no tests, no accessibility, and none of the states a real product needs. When it ships because it looked finished, that shortcut becomes the foundation everything else is built on, and the team pays for it for years as design and technical debt.
So decide up front which you are building. Either it is disposable, and you say so, and you delete it. Or it is the first slice of the product, in which case it deserves the standards of production work and should be scoped accordingly, which is a legitimate way to start an MVP.
The failure is the middle: a throwaway built carelessly and then shipped by accident.
What we do in practice
Figma for flow and comprehension, early and often, because it is cheap enough to be wrong with. Code as soon as the question becomes about feel, data, or responsiveness, and always before committing to an interaction nobody has touched.
The handover between the two is where a design system earns its keep, since components drawn once and built once mean the coded version is assembly rather than reinvention, which is how a design becomes a real product instead of a file somebody admires.
Deciding which one your next piece of work needs? Tell us what question you are trying to answer and we will tell you the cheapest way to answer it: hello@beconfidency.agency.
If you want the design and the built version handled by one team, that is exactly what our product design service is for.