Figma is the floor, not the ceiling. It is excellent for the first eighty per cent of a design conversation. It is bad at the last twenty — the part where the product has to actually move, fetch data, behave under load, survive a real keyboard and a real device. Enterprise prototyping is about being honest about which part of the conversation you are in, and reaching for the right tool at the right moment.
This note is about the workflow we have settled on at Two Words for getting from a brief to a clickable, deployed prototype in days rather than weeks. It works because we stopped pretending that a Figma file is a product, and started shipping prototypes in the same language the eventual product will be written in.
The fidelity ladder
Every project moves up a ladder of fidelity. The rungs are not equal in cost and they are not equal in what they prove.
- Sketch on paper. Free. Proves you can articulate the idea.
- Wireframe. Cheap. Proves the structure has a logic.
- Visual comp. Moderate. Proves the look-and-feel is on direction.
- Clickable Figma prototype. Moderate. Proves the flow is intelligible.
- Working code prototype. The frontier. Proves the thing actually works.
- Shipped product. Expensive. Proves it survives users.
Most enterprise teams stop at rung four. They make beautiful Figma flows, present them, and only learn what is wrong with the design once an engineering team has spent six weeks building it. The cost of that mistake is enormous — both in money and in trust.
Where Figma breaks down
Figma is brilliant for some things and quietly fails at others. The places where it lies:
- Real data. A Figma table with twelve perfect rows is a fiction. The real table will have variable-length text, missing fields, three-line wrap, and that one cell with an entry from 2009 nobody cleaned up.
- Loading and empty states. The version you forget to design is the version users see most.
- Keyboard navigation. Tab order, focus rings, escape behaviour — invisible in a Figma file, painful in a real product.
- Performance. A page that paints in 200ms feels different from one that paints in 2 seconds, no matter how identical the comp.
- Cross-device. Responsive breakpoints in Figma are a polite suggestion. In a browser they are the difference between a usable mobile flow and an unusable one.
None of these are reasons to stop using Figma. They are reasons to also use something else, earlier than most teams think.
The production-grade prototype
Our default move now: as soon as a Figma direction is approved, a designer-engineer builds a working prototype in Next.js with the actual design tokens, the actual fonts, the actual component library. It is hosted on a real URL. The client clicks it on their phone.
The trick is that this is no longer expensive. With design tokens as a contract between Figma and the codebase, the prototype starts most of the way there. With AI-assisted coding (Cursor, v0, Claude Code), a designer can go from a static comp to a working interactive in hours, not days. With Vercel deploying every push, the prototype is always live and always shareable.
The version of design you forget to design is the version users see most.
Design tokens are the bridge
A design system that lives only in Figma is a museum. A design system that lives in code is a factory. The bridge between them is design tokens — a single source of truth for colours, type, spacing, motion, radii, shadows, breakpoints.
Stored as a typed JS or JSON file, tokens get consumed simultaneously by the Figma plugin, the codebase, and (importantly) the AI assistants that generate variants. Change one value and it propagates everywhere. The day the founder asks for the body text to be a touch larger, you change one number and the entire product responds.
The studios that have a real token system can prototype at production fidelity. The studios that don't, can't. There is no shortcut.
The Klay anecdote
For Klay Securities we needed to prove a complete onboarding flow worked end-to-end in time for a board meeting. Historical scope: six weeks. We had ten days.
Days one through three: Figma. Information architecture, copy, screens. Days four and five: built the prototype in Next.js using the existing token system, vibe-coded with our internal Co-Pilot for boilerplate. Days six through nine: refined, added real-feeling data, wired form validation, made it responsive. Day ten: deployed to klay-protoype.vercel.app and shipped the link.
The client clicked it on their phone in the back of a cab on the way to the board meeting. The board approved the direction. The full build started two weeks later — using the prototype as the starting codebase, not throwing it away.
When to ship code vs. mockups
Not every prototype needs to be code. A clear rule of thumb:
- Ship code when: the decision being made depends on real interaction (forms, data, navigation, performance). When the audience is engineering or operations and needs to feel the thing. When the prototype will become the starting point for the build.
- Ship mockups when: the decision is about look-and-feel, brand direction, or layout. When the audience is brand stakeholders or marketing. When you are pre-direction and you don't yet know which thing to prototype.
The mistake we used to make was to ship code prototypes too late and Figma prototypes too long. The current rhythm: Figma fast, code prototype the moment the direction is locked, never look back at the Figma after that.
Speed without ceremony
A few practical principles that make this workable inside a real studio:
One stack, well known. We use Next.js, Tailwind, and our design tokens for every prototype. Familiar. Boring. Fast. Switching stacks per project is a luxury we pay for in days lost to setup.
Deploy on the first day. Even if it's a single page that says hello. The prototype gets a URL on day one. Every push from then on is visible to the client. There is no "demo day" — the demo is always.
Real data, even if fake. Generate fixture data that looks like the real thing, including edge cases. Long names, empty states, four-line wraps, the row from 2009.
Accessibility from day one. Tab order, focus rings, alt text. Retrofitting these is twice as expensive.
The prototype is the start of the build. Don't write throwaway code. The prototype's codebase should be the seed of the production codebase. This forces discipline — every prototype hour also reduces production hours later.
Closing
Enterprise prototyping is a way of being honest sooner. The flows that look fine in Figma and break in browsers will break. The earlier you find that out, the cheaper it is to fix. The prototype is not a deliverable. It is a test rig for the assumptions in the brief — and the studios that run that test rig early are the ones whose work survives the journey from comp to ship.