A founder's guide to turning a product idea into a prototype: the fidelity levels, what each one proves, how many you really need, and what a first prototype costs.
Turning an idea into a prototype is the moment a product stops living in your head and starts telling you the truth. A drawing or a description can hide a hundred problems. A physical thing you can hold, switch on, or hand to someone else cannot. That is the real job of a prototype: it is the cheapest way to find out what you have got wrong while getting it wrong is still cheap.
The mistake I see most often is treating “the prototype” as a single object, as if there is one thing you build and then you are done. In practice a product moves through several prototypes, and each one is built to answer a different question. Getting clear on which question you are asking is what stops you spending money making the wrong thing look beautiful.
A prototype exists to reduce uncertainty. Early on, the biggest uncertainties are usually the crudest ones: does this shape sit in the hand the way I imagined, is there even room inside for the electronics, does the basic mechanism work at all. Later, the uncertainties get finer: does it survive being dropped, does it hold temperature, does the moulded part come out of the tool cleanly.
You do not answer all of those at once. You answer the biggest, cheapest-to-test question first, learn from it, and move on. A good prototype is one that answers its question clearly and then gets superseded without regret. If you find yourself reluctant to change a prototype because of how much it cost, you have probably over-invested in it too early.
It helps to think about prototypes along two separate axes: how much it looks like the finished product, and how much it works like it. Those two things are expensive in different ways, and you rarely need both at the same time.
Sketch models and rough mock-ups. Foam, card, 3D-printed blocks, parts from other products glued together. These cost almost nothing and answer questions about size, proportion, ergonomics and layout. Holding a rough block the size of your product tells you more in ten seconds than a week of staring at a screen. Do this embarrassingly early.
Looks-like prototypes. These capture the form, finish and feel, without necessarily working. They are what you photograph, put in front of potential customers, or use to gauge reactions. A looks-like model can be convincing while being completely hollow inside. That is fine, because its job is to test desirability and appearance, not function.
Works-like prototypes. These prove the function with little regard for looks. The mechanism, the electronics, the heating, the software, all doing their job, often in an ugly oversized box with wires hanging out. This is where the real engineering risk gets retired, because this is where you find out whether the thing actually does what you promised.
Looks-like-and-works-like prototypes. The expensive one, where form and function come together in something close to the real product. You build this once you are confident in both halves separately, usually to validate the integrated design, to demonstrate to investors, or as the last check before committing to tooling. Trying to jump straight to this stage is one of the most common and costly errors in hardware, because you end up paying to perfect details that later change anyway.
Start by writing down the single riskiest assumption in your idea. Not the whole product, just the one thing that, if it turned out to be false, would sink everything else. For one product that might be “people will actually pay to solve this”. For another it might be “this can hit the temperature we need without melting its own housing”. Your first prototype should be the cheapest possible object that tests that one assumption.
If your biggest risk is whether anyone wants it, a looks-like model and a conversation beats months of engineering. If your biggest risk is technical, an ugly works-like rig on the bench is worth far more than a pretty render. Spending money in the wrong place here is how founders burn through a budget and still do not know whether their product is viable.
More than one, and fewer than you fear. The number is driven by how many genuinely unknown things your product contains. A simple mechanical accessory with no electronics might be proven in two or three iterations. A connected device with firmware, a heating system and a moulded enclosure will go through more, because each subsystem needs its own answers before they can be trusted together.
The healthy pattern is lots of cheap, fast iterations early, then fewer, more expensive, more complete ones later. Each loop should teach you something specific and change the next version. If two prototypes in a row taught you nothing, you were building for the sake of it. If every prototype forces a redesign, you are learning exactly as you should be.
Honestly, it ranges enormously, and anyone who quotes you a single figure without understanding your product is guessing. A rough 3D-printed mock-up can cost the price of the filament and an afternoon. A working electronics-and-firmware prototype of a connected device is a different order of spend, because it carries real design and development time behind it. The useful question to ask is less “what does a prototype cost” and more “what is the cheapest prototype that answers my current question”, and then to keep that question as small as you can for as long as you can. I have written more on the wider numbers in the guide on how much it costs to develop a hardware product.
The first is polishing too early. Making an unproven idea beautiful is a way of feeling like progress while avoiding the hard questions. The second is the opposite: staying on the screen too long because a prototype feels like a commitment. It is the reverse, since a prototype is how you avoid committing to the wrong thing. The third is building one prototype and treating its verdict as final, when a single rough version rarely captures the real product. The fourth, and the most expensive, is skipping straight to a tooled, near-final prototype before the fundamentals are proven, then discovering a fundamental problem after you have already paid for the detail.
A prototype is one stage in the wider arc of taking an idea to a real, manufacturable product. Before it, a feasibility study can tell you whether the idea is worth prototyping at all. After it, once the concept is proven, the work turns towards verifying the design and preparing it for manufacture. The full picture of that path is laid out in the pillar guide, how to develop a physical product.
If you have an idea and you are not sure what the right first prototype is, that is exactly the kind of thing I help founders work out. My concept and MVP development service takes an idea, works out which questions to answer and in what order, and turns it into an evaluated concept and a working prototype you can test, show and build on. If you would rather just talk it through first, a Power Hour is the cheapest way to get an experienced view on where to start.
Part of How to develop a physical product: a founder's guide from idea to market · all guides