The fastest way to learn what a product should be is to build a draft of it. Not a wireframe. Not a deck. A clickable thing that runs in a browser, behaves the way the real product would behave, and forces every assumption to either harden or fall over.
We can do this in three days. Here is the shape of the work, what we cut to make it fit, and why we think fast first drafts almost always beat slow second drafts.
What we mean by prototype
A prototype, for us, is a running web app you can put on a screen and demo. It loads real-looking data, walks through the riskiest user flow, and feels close enough to a shippable product that the people watching it argue with the design instead of the medium.
It is not the final product. It usually has fake auth, no persistence, hand-curated content, and one or two flows that work end to end while the rest of the surface area is locked. That is fine. The job is to compress the time between having an idea and learning whether the idea is any good.
Day one: framing and skeleton
The first day is mostly conversation. We sit with the founder or product lead, walk the brief, and try to find the one user journey that, if it works, makes the rest of the product believable. Everything else gets parked.
By the end of day one, we usually have:
- A written one-page brief in our own words. If we cannot summarise the product in one page, the product is not yet a product.
- The single user journey we will build. Picked because it is the riskiest, not the easiest.
- A bare app skeleton on Vercel with routing, the design system primitives, and a deploy preview link the team can already click.
Day one ends with a deploy. Even if the deploy only renders a static homepage, the existence of a live URL changes the feel of the project. It is real now.
Day two: the spine
Day two is when the riskiest journey gets built. We pick the spine of the flow, write just enough state, and seed it with realistic data so the demo lands.
We are aggressive about cutting. If a screen does not move the demo forward, it does not get built. If a feature is interesting but not load-bearing, it gets a placeholder and a small flag so the team can see where it would go. If a piece of the product needs a real backend, we mock the backend with a flat file, a typed function, or an in-memory store. Real backends are a day-three problem.
By the end of day two, the spine works. Someone can sit down, run through the journey, and see the product behave like a product.
Day three: polish and pressure-testing
Day three is split between polish and stress. The morning is design polish: real copy, the actual brand, smooth transitions, real imagery, the small details that make the prototype feel inhabited rather than scaffolded. The afternoon is pressure-testing: we put the prototype in front of someone who has not seen it, watch them use it, and write down everything that confuses them.
Almost every time, the test reveals one or two assumptions we held that were wrong. That is the point. The prototype is a tool for surfacing wrongness early.
Why fast first drafts beat slow second drafts
Most teams over-invest in the second draft of a product before they have stress-tested the first. They polish a Figma mock, then refactor it, then refactor it again, all without ever putting the thing in a browser. The cost of being wrong about a Figma mock is low, so the discipline is low.
A live prototype changes that. The cost of being wrong is visible. People react to running software very differently from how they react to images of software. Three days of code is enough to expose almost every fatal flaw in a product idea.
What we ship at the end of three days
A live URL, a short Loom walking through the flow, a one-page summary of what we learned, and a written list of the next ten things we would build if the project continued. That is the deliverable. The point is not to keep the prototype. The point is to know whether to keep going.
Caveats
This works best on greenfield products with a single decision-maker. It does not work as well on enterprise integrations, regulated workflows, or anything where the riskiest assumption lives outside the user interface. For those, we run a different playbook. But for new SaaS, content tools, AI-flavoured products, and most consumer apps, three days is enough to know.