Every product manager has felt the gap: the idea is clear, the engineers are (rightly) busy shipping the roadmap, and the fastest way to kill a good idea is to put it in a queue. The way out is to build the prototype yourself — and in 2026 that's genuinely realistic, not a euphemism for drawing rectangles.
But "prototype without engineers" covers three very different jobs, and most bad tool choices come from mixing them up. This guide is a decision framework: figure out which job you're doing, then pick from the tools that are honestly good at it.
Key takeaways:
- Match the tool to the question you're testing, not to what's trendy — mockup tools, app generators, and product-capture tools answer different questions.
- Figma remains the right choice when a clickable sequence of screens settles the discussion.
- AI app builders like Lovable, Bolt, and v0 shine for brand-new ideas that don't need to match an existing product.
- When stakeholders or users need to react to your product, prototype on the real interface instead of a rebuilt approximation.
- Whatever the tool, share a link and collect feedback in context — a prototype no one interacts with validates nothing.
The framework: what does the prototype need to prove?
Before comparing tools, answer one question: who has to believe what?
- "The flow makes sense." You need screens in a sequence that stakeholders can click through. Fidelity of behavior barely matters. → Clickable mockups.
- "This new product could work." You need a working thing — real inputs, real state, maybe real data — but it doesn't resemble any existing product because it is new. → From-scratch builders.
- "This change belongs in our product." You need the prototype to look and behave like the product your users already know, or the feedback you get will be about the differences, not the idea. → Prototyping on the real product.
Most PM prototyping frustration comes from using a tier-1 tool for a tier-3 job — or paying tier-3 effort for a tier-1 question.
When clickable mockups are enough: Figma
If the question is about flow, layout, or direction, Figma is still the default for good reason. You wire existing designs (or quick copies of them) into a clickable sequence, present it, and get alignment. If your design team works in Figma, you inherit their components and stay in a tool the whole org can open. Balsamiq and similar wireframing tools play the same role at lower fidelity, earlier.
Honest limits: a Figma prototype is a film of the product, not the product. Nothing computes, nothing persists, and every state you want to show is another artboard to maintain. Usability findings are limited to navigation and comprehension — you can't learn how something feels to use from linked frames. When the question graduates from "is this the right flow?" to "does this actually work?", it's time to move tiers.
When you're building from scratch: Lovable, Bolt, v0 — and no-code
For a genuinely new product or feature with no existing interface to honor, AI app builders are the fastest route to something real. Lovable generates full working apps from natural-language descriptions, Bolt does the same with more control over the underlying code, and v0 excels at generating polished React UI you can iterate on conversationally. A PM with no coding background can get a functioning prototype — forms that submit, lists that filter, state that persists — in an afternoon.
The older no-code generation still has its niches: Bubble for data-heavy internal tools with logic and user accounts, Glide for turning spreadsheets into usable apps, Framer for marketing-site-quality landing pages, and Replit when you want an AI agent plus a real development environment to grow into. Our comparison of AI prototyping tools goes deeper on the individual tools.
Honest limits: every from-scratch builder starts from a blank page, so its output looks like its design system, not yours. For a new venture, that's fine. But if you're prototyping a change to an existing product, the generated version will differ in a hundred small ways — navigation, fonts, spacing, component behavior — and your stakeholders will spend the review noticing the differences instead of evaluating the idea.
When it has to look like your product: Alloy
The third tier is the one PMs hit most often in practice: the idea isn't a new product, it's a change to this product — a redesigned settings page, a new step in onboarding, a different dashboard layout. Here, resemblance isn't polish; it's the substance of the test.
Alloy is built for exactly this. Instead of generating an approximation, it starts from the real thing, two ways:
- Browser capture. The Chrome extension captures any page you can see in your browser — including logged-in screens — as a pixel-perfect, editable prototype with your actual layout, fonts, and components.
- Codebase connection. Connect a GitHub repository and prototypes are grounded in your real components and styling, with a path to open a pull request when a direction is validated — engineering enters at review time, with working evidence attached, rather than build time.
Either way, you edit by describing changes in chat, share the result as an interactive link, and collect feedback in place.
A worked example
Say you're a PM who thinks the billing page needs a plan-comparison view. Without touching a ticket queue:
- Capture the live billing page with the Chrome extension — logged in, real data visible, exactly as customers see it.
- Prompt three changes: "add a side-by-side plan comparison above the invoice history," "collapse the payment-method card into a single row," "add an annual-billing toggle with a 20% discount badge." Each lands on the real interface, so the result still looks like your product.
- Share the link with your designer, your engineering lead, and two stakeholders. They open it in a browser, click through it, and leave inline comments pinned to the exact elements they mean — the toggle, the badge, the collapsed card.
- By the next planning session you're not pitching an idea; you're discussing a clickable version of it with feedback already attached. If the direction holds, the validated prototype — or its pull request — is the handoff.
Total engineering time consumed: zero, until there was something worth engineering. For what happens next, see our guide to testing prototypes with users.
Choosing in one glance
| The prototype must prove... | Reach for | Because |
|---|---|---|
| The flow makes sense | Figma | Fast clickable sequences from existing designs |
| A new product idea works | Lovable, Bolt, v0 | Working apps from a description, no code needed |
| An internal tool is viable | Bubble, Glide | Logic, data, and accounts without engineers |
| A marketing page converts | Framer | Production-quality sites from a visual canvas |
| A change fits your product | Alloy | Prototypes on the real interface, shared as a link |
None of these tools is a subset of another — plenty of teams use Figma for early flows, Alloy for product changes, and an app builder for the occasional greenfield experiment. The failure mode isn't picking a "wrong" tool; it's defaulting to one tier for every question. PMs who master this stack tend to expand it further — our guide to AI for product managers covers the broader toolkit.
The deeper shift is that "I need engineers to build a prototype" is simply no longer true, for any of the three jobs. What engineers still own — rightly — is production. The best prototype is the one that arrives at their door already validated, already commented on, and already looking like the product it wants to become.
