Lovable crossed roughly $400 million in annual recurring revenue selling one capability: a way to build a working app without writing code. That number is the clearest signal yet that the cost of producing a clickable product just collapsed. A product manager can now ship a real interface in an afternoon, no engineer in the loop.
So the question stops being "can a PM build a prototype" and becomes "when should a PM build one instead of writing it up." Those are different skills. The tools are not the hard part anymore. The judgment is.
This guide covers the four tools worth knowing, a rule for choosing between a prototype and a doc, and the trap senior PMs warn about: the afternoon mockup that quietly becomes production.
The four tools and what each is good for
The market settled into four serious options in 2026. They overlap, but each has a center of gravity.
- Bolt: the all-rounder for speed and full-stack iteration. Reach for it when you want a working flow fast and don't care which framework it lands on.
- v0: front-end polish, especially for teams already on Vercel. Strongest when the output needs to look close to shippable.
- Lovable: built for non-technical PMs who want a finished page, not a code editor. The least intimidating starting point if you've never touched a repo.
- Replit: internal tools with persistent data. The one with a real built-in database and auth, so it fits prototypes that need to store and read state.
Pick on the shape of what you're testing, not on brand loyalty. A pricing-page concept wants v0 or Lovable. An internal approval tool that remembers submissions wants Replit. A messy end-to-end flow you'll throw away next week wants Bolt.
Prototype, spec, or wireframe: how to choose
Building is cheap now, so the temptation is to prototype everything. Resist it. Each format answers a different question, and using the wrong one wastes the week.
A prototype answers "does this feel right when a person uses it." Build one when the risk lives in the interaction: a flow you can't picture, a layout you keep arguing about, an idea stakeholders nod at but clearly don't see the same way. Showing beats describing here.
A spec answers "do we agree on what to build and why." Write one when the risk lives in alignment, edge cases, or scope: a feature touching billing, permissions, or data you can't fake in a demo. A clickable page won't settle whether a refund over a threshold needs approval. Prose will.
A wireframe answers "is the structure roughly correct." Sketch one when you need to align on layout in minutes and a working build is overkill.
A prototype is an argument you can click. A spec is an argument you can audit. Reach for the one that matches the disagreement you're trying to end.
The honest test: name the riskiest assumption before you start. If it's about feel, prototype. If it's about agreement or correctness, write. If you can't name the assumption, that's the real problem, and no tool fixes it.
What a prototype proves, and what it can't
A PM prototype is strong evidence about one thing and silent about most others. Knowing the line keeps you from overclaiming in the next review.
A working demo proves desirability and usability. It shows whether people understand the flow, whether the value lands in the first thirty seconds, and where they get stuck. Those are the questions a minimum viable product is meant to answer, and a clickable demo gets you there faster than a slide deck ever did.
A demo does not prove feasibility, scale, or economics. The AI-generated code behind it often skips error handling, security, and the data model your real system needs. It can't tell you whether the feature holds up at ten thousand users or what it costs to run. Treating "it worked in the demo" as "it's basically built" is how teams ship six weeks of surprise engineering debt.
State the claim precisely when you present. "Eight of ten users completed the flow without help" is a finding. "The feature is ready" is not, and a senior engineer in the room will know the difference instantly.
Keep the throwaway from becoming production
Here's the trap nobody warns junior PMs about. You build a sharp prototype, a stakeholder loves it, and someone says "ship it." The throwaway becomes the foundation, and the shortcuts you took to move fast become permanent liabilities.
This is the operator blind spot in the vibe-coding story. The risk isn't that PMs can't build. It's that a prototype built to answer one question gets pressed into a job it was never engineered for. The code has no tests, the data model is a sketch, and now it's in front of customers.
Protect against it with three habits:
- Label it on day one. Say "throwaway prototype" out loud and in writing. Set the expectation before anyone falls in love with it.
- Keep prototypes out of production repos. A separate space signals the work is disposable and stops it from drifting into the real codebase by accident.
- Hand off the learning, not the code. When a prototype validates an idea, write the short spec it earned and let engineering build the real version. The prototype did its job the moment it taught you something.
The point of moving fast is to learn fast, then build the durable version deliberately. Speed at the prototype stage only pays off if you don't let it set the quality bar for what ships.
A one-week loop from idea to clickable
Put it together and the loop is short. Five days, idea to evidence.
- Monday: name the riskiest assumption and confirm it's about feel, not alignment. If it's alignment, stop and write instead.
- Tuesday: pick the tool by shape and build the smallest version that tests the assumption. One flow, not a product.
- Wednesday: put it in front of five users. Watch where they hesitate. Don't explain; let them struggle.
- Thursday: revise once based on what you saw, not what you hoped.
- Friday: write up the finding, the claim it supports, and the next decision. If it validated, draft the spec engineering needs.
The discipline isn't in the building. It's in starting with a question worth answering and ending with a decision you can defend. The tool gives you a week of speed. What you do with it is still the job.
