The Prototype Is the Proposal: Using Code Layers in MVP Discovery Without Overpromising

Until recently, a discovery prototype was obviously a prototype. You clicked a button, a new frame slid in, and everyone understood it was a picture of a product. Now it can be a running thing. With Figma's code layers in public beta since October, designers can put working, code-backed prototypes straight on the canvas: real inputs, real state, sometimes real data.

That's a big win for discovery. A running prototype tests assumptions far better than a clickable one, and it wins work. But it has created a new question in client meetings, usually asked with a smile: "So it's almost done?" It isn't. Here's how we use running prototypes in MVP discovery at Breem without overpromising.

From clickable to running: what changed

As Tenet's summary explains, code layers let you place code-backed elements on the Figma canvas next to regular design layers. The Design Systems Collective's Config recap describes it as the shrinking distance between drawing an interface and building it. That's exactly what it feels like in practice.

For discovery, the difference matters. A clickable prototype shows a flow. A running prototype lets a user type their own phone number, see validation behave, filter a real list, or watch a total update as they change quantities. Users react to it as a product, which is what you want when you're testing whether an idea works.

What a discovery prototype should prove

In my 4-week MVP process, discovery comes before any serious design work. Its job is to answer a small number of questions before the client commits a real budget. A discovery prototype should prove things like:

• Users understand the core idea without explanation.
• The main flow is completable by real people in the target market, in their language.
• The riskiest assumption holds up, for example that users will trust paying inside the app, or that a merchant can set up a store in one sitting.
• The scope is right: which features users actually reach for, and which ones they ignore.

What it should not try to prove:

• That the architecture works at scale
• That the code is production-ready
• That every edge case is handled
• That the visual design is final

If the prototype starts trying to prove those things, it has stopped being discovery and turned into a slow, unplanned build.

The "it looks done" trap

The better the prototype, the bigger the trap. A founder sees a working flow on Tuesday and starts telling investors it will launch next month. Then the real estimate arrives and it feels like the agency is inflating the work.

We now frame every demo with three short lists, said out loud and written on the first frame:

1. What's real: the flow, the interactions, the layout, the copy we've tested.
2. What's faked: the data, the payments, the login, any back-end response.
3. What's missing: security, error handling, admin tools, integrations, performance, accessibility and RTL QA across devices.

It takes two minutes and prevents weeks of awkward conversations. It also builds trust, because clients can see we're not hiding the hard parts.

Visual cues help too. We keep a small, visible "Prototype" label on running prototypes and avoid using the final brand polish everywhere. If it looks 100% finished, people believe it's 100% finished.

[Waleed: add how a client reacted to a running prototype in discovery and how the framing helped, anonymized if needed.]

Handing over the prototype: reuse, rebuild or throw away

Running prototypes contain code, and clients naturally ask whether their developers can just keep going from it. Sometimes yes, often no. NN/g's article The New Big Ball of Mud describes how cheaply built AI-era systems become fragile and hard to understand. A discovery prototype built quickly is a prime candidate. I've written about what happens when those get shipped anyway in Rescuing the Vibe-Coded MVP.

We decide at the start of discovery which of three paths the prototype is on, and write it in the proposal:

• Throwaway: built only to learn. The design decisions carry forward; the code doesn't. This is the default.
• Reference: developers can read it to understand intended behavior, but they build the product fresh.
• Foundation: built with production in mind from the start, using the real component library and code standards. Slower and more expensive, and only worth it when the client's dev team is involved from day one.

Being explicit protects everyone. The client knows what they're getting, and developers don't inherit code that was never meant to last.

Pricing discovery when prototypes are cheap

If a running prototype now takes days instead of weeks, should discovery cost less? Partly. But the prototype was never the valuable part. The value is in what discovery decides: which idea to build, for whom, in what scope, and what to leave out.

So we price discovery on its outputs:

• A tested core flow, with findings from real users in the target market
• A prioritized MVP scope with clear cuts
• The riskiest assumptions, tested or flagged
• A realistic build estimate based on what we learned

Cheaper prototypes let us test more ideas in the same time, which makes discovery more valuable, not less. My post on pricing design when the first draft costs nothing goes deeper into this.

Closing thoughts

Running prototypes are the best discovery tool we've had in years. Clients understand ideas faster, users react more honestly, and we win work by showing instead of describing. The risk is letting a convincing demo make promises the project can't keep. Say what's real, what's faked and what's missing. Decide the prototype's fate up front. And price the decisions, not the pixels. Then the prototype really can be the proposal, without becoming the product by accident.

Sources: Figma Specs and code layers for AI agents (Tenet), Figma Config 2026: the shrinking distance between drawing an interface and building it (Design Systems Collective), The New Big Ball of Mud (NN/g).

FAQs