Figma Prototype or Coded MVP?
A Figma prototype costs SEK 50,000–150,000 and tests experience, flow, and willingness to pay in interviews. A coded MVP costs from around SEK 300,000 and tests real behavior: whether users return and actually pay. Choose based on your biggest uncertainty – design means the prototype is enough; business or technology requires an MVP.
Both the prototype and the MVP get called “testing the idea” – but they prove completely different things. Choosing the wrong tool is costly either way: an MVP built to answer a question a prototype could have handled wastes a quarter million kronor, and a prototype used where an MVP was actually needed gives false confidence. Here’s what each tool can actually prove.
What a Figma prototype can prove
A clickable Figma prototype looks and feels like a real product, but it’s a series of linked screens. It costs SEK 50,000–150,000, takes a couple of weeks to produce, and can be redrawn between two interviews.
It proves what can be seen and experienced: do users understand what the service does? Do they find their way through the flow? Do they react to the pricing page with interest or hesitation? In interviews, it gives strong signals about experience, clarity, and stated willingness to pay. What it can’t prove is behavior over time – no one truly “uses” a prototype, and no one pays real money in it.
What a coded MVP can prove
An MVP is a real, live product scoped down to a single core flow. It costs from around SEK 300,000 and up, and takes eight weeks or more to build.
It proves what the prototype can’t reach: real behavior. Do users come back next week without anyone interviewing them? Do they complete the flow when no one’s watching? Do they pay with their own card? Does the technology hold up against real data? That’s the difference between what people say and what they do – and for business decisions, only the latter counts.
The comparison at a glance
| Question | Figma Prototype | Coded MVP |
|---|---|---|
| Cost | SEK 50,000–150,000 | From around SEK 300,000 |
| Time to build | 2–4 weeks | 8–14 weeks |
| Proves | Experience, flow, stated willingness to pay | Real behavior, repeat use, actual payment |
| Test environment | Interviews and demos | Real use in production |
| Cost to change | Hours | Days to weeks |
The decision rule: where does your biggest uncertainty sit?
Ask yourself which uncertainty would sink the venture if it fell the wrong way – design, business, or technology:
- Design and clarity. “Will users understand and want this?” Start with the prototype. It answers the question for a tenth of the cost and can be iterated until the answer is clear.
- The business. “Will people pay and come back?” The prototype gives an initial signal through interviews, but the proof requires an MVP – repeat use and real payments can’t be simulated.
- The technology. “Can it be built – can we handle the data, the performance, the integration?” No amount of Figma helps here; it requires code. A technical proof of concept or an MVP is the right tool.
For most new services, the order is therefore: prototype first to get the experience right cheaply, then an MVP on the validated flow to test the business for real.
A worked example: two paths to the same answer
A founder wants to launch a subscription service. Path A: build the MVP directly for SEK 500,000. After launch, it turns out the onboarding is misunderstood – a rebuild costs SEK 150,000 and two months of lost time. Total: SEK 650,000. Path B: a prototype for SEK 100,000, ten interviews, two redraws that catch and fix the onboarding problem – then an MVP on the validated flow for SEK 450,000. Total: SEK 550,000, faster to a working product, and with significantly lower risk along the way.
So the prototype didn’t “cost” SEK 100,000 – it saved SEK 100,000 and two months. That’s how the math works out in most cases where design uncertainty is high.
The trap in both directions
Prototypes can become an escape route: a service demoed forever but never confronted with reality ends up testing nothing at all. And MVPs built too early test the wrong things expensively. The tools are steps on the same staircase – at Weapp we normally use both in sequence as part of our services, with a clear decision in between. Not sure where your idea stands? Get in touch and we’ll help you identify the biggest uncertainty first.
Frequently asked questions
Can the design from the Figma prototype be reused when building the MVP?
Yes, that's one of the prototype's big advantages. Flows, screens, and components become a direct foundation for development, which significantly shortens the MVP's design phase. No code carries over, though – the prototype is a series of images that feels real, not a product.
Can a prototype really test willingness to pay?
It can test stated willingness to pay: show a pricing page in the interview and ask the person to reason through it, or ask for a statement of intent. That's a strong signal but not proof – people overestimate their own willingness to pay in conversation. Real willingness to pay requires actual money changing hands, and only the MVP tests that.
How many user tests does a prototype need?
Five to eight interviews per round is usually enough for clear patterns to emerge – beyond that, more interviews quickly yield diminishing new information. The prototype's strength is that it can be redrawn between rounds, so two or three short rounds almost always beat one big one.
What's the difference from a proof of concept?
A proof of concept tests technology: can this even be built – does the API hold up, is performance sufficient, does the algorithm work? It usually has no interface to show users. The prototype tests the experience, the MVP tests the business in real use – three tools for three different uncertainties.
Does the MVP have to be built in the same technology as the finished product?
Ideally, yes. An MVP built on a stack that carries forward can be developed further into the product, while an MVP in throwaway technology has to be rewritten after validation – meaning you pay for the same thing twice. The exception is pure one-off experiments deliberately meant to be discarded.