How long does building a prototype this way take?

About 30 minutes from spec to clickable page — a few minutes to plan the screens, a few minutes for Claude to write the file, then the rest clicking around and iterating. The point is that the whole loop is faster than a Figma frame anyone has to explain.

Do I need to know how to code to do this?

No. You describe what you want in plain language and Claude writes the self-contained HTML file. You only need to be able to open a file in a browser by double-clicking it — no install, no build step, no terminal.

Can I send the prototype to a real customer to click?

Yes, but only if it contains invented data — never seed a prototype with real customer names, emails, or account details. A single HTML file with live PII is easy to forward accidentally; use fake article titles and made-up user names, then pair the reaction with your feedback synthesis for context.

Should I hand the prototype file to engineering as a starting point?

No. The prototype is fake data and throwaway code by design — handing it to engineering as a head start ships exactly the shortcuts you took to move fast. The output you carry forward is the 5-line decision note, not the HTML file.

Build a clickable prototype to decide

when to reach for this

Specs and Figma frames let people nod along without ever feeling the thing. The moment you can actually click a flow, real reactions show up — "oh, the Saved tab should be next to the article, not buried in a menu." This system has Claude build a single self-contained web page you open in your browser and click around, so you can react to a real artifact before a single engineer touches it. You drive the whole thing from the Claude Desktop chat — describe what you want, double-click the file Claude writes, click around. The whole point is to learn and decide cheaply. A prototype is to decide, not to ship — it's a throwaway, and treating it as a head start on production is how you end up shipping fake-data spaghetti.

gather this first

The v1 spec from Pressure-test an idea into a v1 spec — or at least the core flow and screens, pasted into the chat in Claude Desktop or dropped in as a spec.md.
The one decision this prototype has to settle — "does the save-then-find flow feel obvious?" — so you build toward a question, not toward polish.
A few realistic example items (3-5 fake article titles, a couple of fake user names) so the screen feels real, not Lorem ipsum.

the workflow

State the decision, then have Claude plan the screens

Build toward a question, not toward a finished product. Naming the decision up front keeps the prototype small — you only build what's needed to answer it.

you ask

I want a clickable prototype to answer ONE question: does the save-article-then-find-it-in-Saved flow feel obvious to a first-time reader? From spec.md, list the minimum screens and clicks needed to test that — nothing more. Don't write any code yet.

what you get back A tiny screen plan — "a list view with 5 articles each having a Save button, and a Saved tab that shows what you saved; clicking Save moves it, clicking the article opens a stub." If it's proposing login screens and settings, pull it back to the one flow.

A prototype that tries to show everything proves nothing. One question, the fewest screens that answer it.
Have Claude build a single openable page

Ask for one self-contained file with everything inline, so opening it is a double-click — no install, no build step, no server. That's what makes it a throwaway you can hand to anyone.

you ask

Build a single self-contained `prototype.html` with all the HTML, CSS, and JavaScript inline — no external files, no frameworks to install. A list of these 5 fake articles, each with a Save button; clicking Save moves the article into a 'Saved' tab; the Saved tab can remove a save. Make it openable by double-clicking the file.

what you get back One prototype.html you can open straight in your browser and actually click. Save moves an article to the Saved tab, remove takes it back — the real flow, running locally, built from fake data.

If you'd rather build this yourself step by step, the Recipes tab walks through making a clickable page from scratch — same idea, more hand-holding.
Click it like a confused first-timer

Use it the way a real user would, not the way you designed it. The friction you hit clicking around is exactly the feedback you came for — and it's free now, expensive later.

you ask

I clicked through it. Here's what felt off: [the Saved tab was hard to find / saving gave no confirmation / I couldn't tell what was already saved]. Update prototype.html to try a fix for each, and tell me what you changed and why.

what you get back A revised prototype.html plus a short list of the changes — "added a 'Saved ✓' state on the button so you can see what's already saved; moved the Saved tab up next to Articles." You iterate on a real artifact in minutes.
Write the decision the prototype produced

The deliverable isn't the page — it's the call you can now make. Capture what you learned so the prototype can be deleted without losing the lesson.

you ask

Based on how this prototype felt, write a 5-line decision note: does the flow work as-is, what needs to change before we build it for real, and is this still worth eng time? Be honest if the answer is 'not yet.'

what you get back A short, defensible note — "flow works once Save shows a confirmed state; the Saved tab needs to be top-level; worth building, est. small. Open risk: what happens to saves when an article is unpublished." That note, not the HTML, is what you carry forward.

make it your own

Compare two flows: build two prototypes of the same feature and click both, then ask Claude to summarize which felt clearer and why — a cheap A/B before committing a direction.
Hand it to a real user: the single-file page can be sent to one trusting customer to click; pair it with Synthesize feedback into a roadmap signal to fold their reaction into the wider pattern.
Take it to eng: once you've decided, feed the prototype and decision note into Read your codebase in plain English to scope where the real version would live.

watch out for

A prototype is to decide, not to ship. This is fake data and throwaway code by design — handing it to eng as a starting point ships exactly the shortcuts you took to move fast. The output is the decision, then you delete the page.
Don't seed it with real customer data to make it feel real — invent example articles and names. A prototype with live PII in a single HTML file is a leak waiting to be forwarded.
Claude builds the prototype; you make the call. "It runs" is not "we should build it" — the human still owns whether the flow is worth real engineering time.

you'll end up with A clickable, openable prototype you used to feel the flow and a 5-line decision note that captures the call — so you commit eng time on a reaction to something real, not a guess about a mockup.

Questions people ask

How long does building a prototype this way take?: About 30 minutes from spec to clickable page — a few minutes to plan the screens, a few minutes for Claude to write the file, then the rest clicking around and iterating. The point is that the whole loop is faster than a Figma frame anyone has to explain.
Do I need to know how to code to do this?: No. You describe what you want in plain language and Claude writes the self-contained HTML file. You only need to be able to open a file in a browser by double-clicking it — no install, no build step, no terminal.
Can I send the prototype to a real customer to click?: Yes, but only if it contains invented data — never seed a prototype with real customer names, emails, or account details. A single HTML file with live PII is easy to forward accidentally; use fake article titles and made-up user names, then pair the reaction with your feedback synthesis for context.
Should I hand the prototype file to engineering as a starting point?: No. The prototype is fake data and throwaway code by design — handing it to engineering as a head start ships exactly the shortcuts you took to move fast. The output you carry forward is the 5-line decision note, not the HTML file.