Prototyping tools in 2026: the best options for product teams, from Figma to code

Prototyping tools in 2026 split into three kinds. Design tools such as Figma and ProtoPie make click-throughs. AI generators such as v0, Lovable, Bolt and Figma Make build a fresh app from a prompt. Codebase tools such as Cursor, Claude Code and Modeinspect work in your existing repo. The right pick depends on the question the prototype has to answer, and on whether that answer needs the real product.

Key takeaways

• Low-fidelity prototypes surface "substantially the same sets of usability problems" as high-fidelity ones across two experiments (Virzi, Sokolov and Karis, CHI 1996). Match fidelity to the question, not to the deadline.
• Five users find about 85% of the usability problems in a design, so three rounds of five beat one round of fifteen (NN/g, March 2000).
• 66% of developers name AI output that is "almost right, but not quite" as a frustration (Stack Overflow, 2025). A generated demo in a throwaway repo is not the feature.
• Over half of Figma's paid customers paying more than $100,000 a year were building in Figma Make weekly by the end of 2025 (Figma, February 2026).

What a prototype is for

A prototype exists to answer a question before anyone commits to building the product. The question decides the fidelity, the tool, and how long the prototype should live.

Definition

A prototype is a model of a product built to answer a question before the product is built.

Three questions are worth a prototype:

• Concept. Is this the right thing to build? A rough model shows whether the idea makes sense to its users.
• Usability. Can people use it? A model with real tasks shows where they get stuck.
• Feasibility. Can we build it this way? A model built with the real components and data shows whether the approach holds up.

Most requests arrive without an answer to any of the three. In the NaPiRE survey of 228 companies in 10 countries, 48% of respondents named incomplete or hidden requirements, the most cited problem (Méndez Fernández et al., Empirical Software Engineering, 2017).

A prototype turns that vague request into something people can react to. A stakeholder who reads a spec nods. A stakeholder who clicks through a prototype tells you the third screen is wrong. More on prototyping before the spec exists in why prototypes should be your first move.

Low fidelity vs high fidelity: which to build

Low fidelity finds most of the same usability problems as high fidelity. High fidelity earns its cost when the question is about workflow, timing, or stakeholder buy-in.

The research is old and still holds. Virzi, Sokolov and Karis ran two experiments comparing low- and high-fidelity prototypes and found "substantially the same sets of usability problems" in both conditions (CHI 1996). Walker, Takayama and Landay found low and high fidelity "equally good at uncovering usability issues", whether on paper or on a computer (HFES 2002).

The substitute is reasonable, not perfect. Jeff Sauro's review of the fidelity literature finds low fidelity a fair stand-in for finding problems, and a worse one for task times and aesthetic ratings (MeasuringU, August 2017). The full comparison is in low fidelity vs high fidelity prototypes.

High fidelity answers a different set of questions. NN/g's guidance is that a high-fidelity prototype lets you test workflow and specific UI components because it looks and behaves like live software (NN/g, December 2016). It is also what a stakeholder needs to see before funding a build. What high fidelity means in practice, and where polish stops paying for itself, is covered in high fidelity design.

The practical rule of prototype design is to match fidelity to the question. Concept questions want low fidelity, because polish invites feedback on the polish. Workflow, timing, and buy-in questions want high fidelity, and in 2026 that increasingly means real components.

Click-through vs coded interactive prototypes

A click-through prototype links static screens with hotspots. A coded prototype runs logic, holds state, and reads data. One shows what the product looks like. The other shows what it does.

For a concept test, a click-through is usually enough. Its limits show up as soon as the question involves behaviour. Every state is a separate screen, so a form with five validation cases becomes five artboards. Data is typed in by hand, so every user sees the same three tidy rows. Edge cases and empty states get skipped. And when the test is over, nothing carries into the build.

Coded prototypes remove those limits and add two costs. The first is setup: a repo, a dev environment, a place to deploy. The second is temptation. Once an interactive prototype runs real logic, polishing it feels like progress, and the question it was built to answer drifts out of view.

One request on Figma's forum shows the seam. A February 2026 feature request asks for Figma Make output to become a Figma prototype, because the two artifacts do not connect (Figma Forum, February 2026). The request wants the behaviour of code with the shareability of a design file, and today those are two separate artifacts.

For an app prototype that has to answer a usability or feasibility question, coded wins, provided setup does not land on the designer. A step-by-step walkthrough of both routes is in how to create a software prototype.

The best prototyping tools, compared

The best tools for prototyping a new product and for changing an existing one are different, so the table below is a map rather than a ranking. It sorts eleven tools by where the output lives and whether it touches real data.

Sources:

• Figma: pricing, prototyping guide
• Figma Make: product page, backend docs, Config 2026 recap
• Framer: pricing
• ProtoPie: pricing
• Play: AppleInsider
• v0: pricing, docs, Git Import
• Lovable: plans, GitHub
• Bolt: pricing, Git
• Cursor: pricing
• Claude Code: pricing, overview
• Modeinspect: pricing

Design-tool prototyping (Figma, ProtoPie, Framer)

Figma remains the default for click-through prototypes. Its prototyping features cover variables, conditional logic and Smart Animate (Figma Help Center, Guide to prototyping in Figma). ProtoPie is the dedicated interactive prototype tool of the three, with formulas, sensors and, through Connect, real API input. Framer is a website builder and belongs here only for marketing sites. All three share one boundary: the output lives in the tool, not in your repo.

AI app generators (Figma Make, v0, Lovable, Bolt)

These tools turn a prompt into a running app, and adoption is broad. Figma reported that over half of its paid customers paying more than $100,000 a year were building in Figma Make weekly (Figma). They differ in where the app lives. Lovable creates a new GitHub repo and does not import an existing one. Bolt turns an imported repo into a new Bolt project. v0's Git Import builds against an existing repo on an isolated branch and publishes a pull request. Figma Make runs on its own Supabase backend, and Code Layers, its codebase connection announced at Config in June 2026, is not yet generally available.

Coding agents (Cursor, Claude Code)

Cursor and Claude Code work in the existing repo with whatever data the codebase already reaches, so a prototype built with them is as high fidelity as the product. Both are engineers' environments: there is no canvas and no share link, so a designer sees the result by reading a diff or running the app. For a designer who is comfortable in a terminal, they are a cheap route to the real product.

Prototyping on the real product (Modeinspect)

Modeinspect opens the team's existing codebase as a design canvas. It uses the design system one-to-one, runs on live data, has an interactive demo mode and live preview links, and ends in a pull request that engineers review. The fit is a change to an existing product with its real components and data: a new settings flow, a redesigned table, a checkout step. A new product from scratch, a mobile-native app, or a marketing site needs one of the other kinds.

AI prototyping on a new project vs on your codebase

AI prototyping makes the first working version cheap. It does not make that version mergeable, and it does not connect it to the product it is meant to change.

Adoption numbers say the first part is settled. In Stack Overflow's 2025 developer survey, 84% of developers use or plan to use AI tools (Stack Overflow, 2025). In Figma's 2025 AI report, a survey of 2,500 users, 78% agreed that AI significantly enhances their efficiency (Figma, April 2025).

Trust numbers say the second part is not. Only 33% of developers in the same Stack Overflow survey trust the accuracy of AI output, and 46% distrust it. The most cited frustration, at 66%, is "AI solutions that are almost right, but not quite" (Stack Overflow, 2025). In Figma's report, 32% of respondents said they can rely on AI output (Figma, April 2025). Roughly a third trust the output, on both sides.

GitClear's analysis of 623 million changed lines found that refactored ("moved") code fell from 21% of changed lines in 2022 to 3.8% year-to-date in 2026. Duplicated blocks rose 81% since 2023 (GitClear, January 2026). The 2025 DORA report, from about 5,000 respondents, found that AI adoption relates positively to throughput and negatively to delivery stability (Google Cloud, September 2025). More code, less reuse, more breakage.

For a prototype, this is the difference between a demo and the feature. A generated app that ignores the design system, hardcodes values instead of tokens, and lives in a throwaway repo can answer a concept question. It cannot answer a feasibility question, because it was not built the way the product is built. And it cannot become the feature without engineers rebuilding it inside the real codebase.

What AI solves is still worth having. The blank-canvas cost is gone: a first version of a flow now takes less time than drawing it. States and copy variations are cheap, so the empty state and the error state get built instead of skipped. The full picture is in AI prototyping and the problems it is actually solving.

Why prototype with real components and data

Most product work is a change to something that already exists. A prototype of that change is only convincing when it uses the real components, the real tokens, and the real data.

Four reasons:

• Stakeholders react to their own data. A mockup with "Acme Corp" in every row gets a shrug. Last week's real accounts get a decision.
• Edge cases appear without being drawn. Long names, empty states, missing permissions.
• The design system is already the answer to "what should this look like". A prototype that reinvents the button answers a question nobody asked.
• The prototype can become the pull request. The same branch that answered the question is the one engineers review.

Modeinspect is one way to do this, on the team's own codebase and live data. Demo mode and live preview links let a designer share a working flow without a screen recording. The result is a pull request in the codebase's own conventions, the kind of code engineers want to merge. When the reviewer asks for a spacing change, the designer makes it in the same pull request, which is design QA in the pull request.

Prelude's team went from about 31 days to 13 from idea to merged pull request, and from five-plus handoffs per feature to one (Prelude case study). The prototype and the feature were the same artifact.

The scope is web front ends on a product that already exists. A new product or a native mobile app still needs one of the other kinds of tool.

When to skip the prototype and go straight to code

Skip the prototype when the question is already answered and building the real thing costs about as much as faking it. On a codebase with a mature design system, that describes a lot of changes.

Go straight to code when:

• The change is small and reversible. A relabelled button, a new column in an existing table. If it is wrong, the fix is another small pull request.
• The components already exist. Composing existing components takes about as long as drawing them, and the result is closer to the truth.
• The reviewer is the engineer anyway. If sign-off comes from whoever reads the pull request, a mockup adds a step without adding information.
• The data is what makes it convincing. A prototype with fake data would not answer the question, so build on the real data from the start.
• The prototype would be thrown away. If nobody will build on it, the effort is better spent on the real change.

Do not skip when the question is still open. That means a new concept with no existing flow, a flow the team cannot describe in one sentence, or more than one plausible direction. It also means any change in a regulated or high-risk part of the product.

When a designer can change the real product with design controls and a preview, "go straight to code" no longer means "wait for an engineer". Which route fits which change is compared in every route from a design to a shipped change.

How to demo and test a prototype

Test with a few users on real tasks, then demo to stakeholders in the state they will remember. The order matters.

Five users are enough for one round. Jakob Nielsen's analysis found that five users uncover about 85% of the usability problems in a design (NN/g, March 2000). His recommendation is three rounds of five rather than one round of fifteen, fixing between rounds.

Five steps that hold up regardless of tool:

1. Write the question. One sentence, before the prototype exists. "Can a workspace admin find and change the billing owner without help" is a question. "Test the settings page" is not.
2. Pick tasks, not features. Give each user a goal and watch. Do not tour the interface.
3. Use real or realistic data. Long names, empty lists, an account with 400 items. Tidy sample data hides the problems you are looking for.
4. Share a link, not a screen recording. A recording shows the path the presenter chose. A link lets the stakeholder take their own path.
5. Capture the decision. Write down what changed and why, next to the prototype, so the build starts from the decision rather than from memory.

Example

Imagine a team that wants to move billing ownership from a modal into a settings tab. They write the question on Monday, build the tab on the real components with live data on Tuesday, and share a preview link with five customers on Wednesday and Thursday. Three of five look for the control under "Members" first. The tab gets a cross-link from Members on Friday, and the same branch becomes the pull request.

The decision is the fragile part. When the prototype is thrown away and the build starts from zero, the reasoning lives in someone's head.

How to choose between prototyping tools

Choose by the question and by where the answer has to live.

Before adopting any tool, check that it:

1. uses your components and tokens rather than generating look-alikes.
2. runs your data, or at least reaches your APIs.
3. produces something a teammate can open and build on.
4. has a share link, so feedback comes from people using the prototype.
5. ends in code your engineers accept, or is honest that it does not.

A tool can fail the last two and still be the right choice for a concept test. It cannot fail them for a change to the product you already ship. To see prototyping on a real codebase with your own components and data, book a demo.

Frequently asked questions

What is the best prototyping tool in 2026?

There is no single best prototyping tool in 2026, because the right one depends on the question the prototype has to answer. Figma suits click-through concept tests. AI generators such as v0, Lovable and Bolt suit fresh apps, and codebase tools such as Cursor, Claude Code and Modeinspect suit changes to a product that already exists.

Can AI generate a prototype automatically?

Yes, tools such as v0, Lovable, Bolt and Figma Make build a running app from a text prompt in minutes. By default the output is a new project on the tool's own backend. It answers concept questions well but does not use your design system or data unless the tool works inside your codebase.

What is the difference between a click-through and a code-based prototype?

A click-through prototype links static screens with hotspots, while a code-based prototype runs real logic, holds state and can read real data. In a click-through every state is a separate screen and the data is typed in by hand. A code-based prototype can carry over into the build instead of being redrawn by an engineer.

Which prototyping tools produce production-ready code?

Tools that work in your existing repository, such as Cursor, Claude Code and Modeinspect, produce code in your codebase that engineers review as a pull request. Lovable and Bolt produce real code too, but in a new project that has to be rebuilt inside your product before it can ship. v0 can build on an existing repo through Git Import.

How many users do you need to test a prototype?

Five users per round find about 85% of usability problems, according to Nielsen Norman Group's 2000 analysis. Run three rounds of five, fixing between rounds, rather than one round of fifteen.