5 Questions to Ask Before You Build a Prototype

A prototype is a question made physical. Build one without knowing the question, and you get expensive learning — weeks lost, cash spent, and a tangible object that still hasn’t told you whether the product is worth making. Most founders rush this. They go from “I have an idea” to “let’s build something” because building feels like progress. It often isn’t.

Answer five questions first. They cost a day of thinking and routinely save weeks of building.

1. Does this actually solve a real problem?

This is the foundation, and no amount of building moves it. If the product solves a problem nobody has — or solves it for a market too small to matter — you’re done. A prototype won’t change that.

The honest test: have you spoken to enough potential users to confirm they hit this problem often enough to pay for a fix? Or are you building something you simply think is clever? A prototype validates the solution to a problem you’ve already confirmed exists. If you haven’t done that confirmation, do it first — it costs nothing but time, and a prototype built without it is premature.

2. What are you actually testing?

This is where most prototyping goes wrong. Founders build something “pretty close” to the finished product and hope it answers everything at once: does it work, will people buy it, can we make it, can we make it profitably? That’s four or five different questions crammed into one costly build.

Be specific. The kind of prototype you need depends entirely on the assumption you’re testing:

• Concept: does the core mechanism work as the theory suggests? A rough functional model is enough — it needn’t be pretty or durable.
• Usability: can people understand and use it without training? A realistic mock-up will do, even if the internals are faked.
• Manufacturing: can it be made at the cost and volume you need? Often you don’t build at all — you send the design to a factory for quotes.
• Material: does the chosen material hold up under real conditions? Test small samples under realistic load and environment, not a whole unit.
• Integration: do the components work together? A benchtop assembly answers it; it needn’t fit inside the final housing.

Each demands a different prototype. Trying to answer all of them at once means you’re either overbuilding or underbuilding. Name the one thing you’re testing, then build the cheapest thing that tests it.

3. What’s the cheapest way to test this assumption?

Once you know what you’re testing, there are usually three routes, in rising order of cost and slowness:

• Simulation or CAD analysis — structural, thermal or dynamic. Rules out bad ideas before anything is built.
• Benchtop or mock-up prototype — 3D-printed, laser-cut or hand-assembled. Rough, not production-like, but answers the core question.
• Production-intent prototype — built in the real process with real materials and tolerances. Answers almost everything, but is slow and expensive.

The rule is simple: use the cheapest method that genuinely answers your question. If a simulation settles it, don’t print. If a print settles it, don’t cut tooling. Most founders jump straight to production-intent because it feels thorough — and that’s how you spend a fortune learning something a far cheaper test would have told you.

4. What does success look like?

Define success before you build — and not as “the prototype works,” which is too vague to act on. Set measurable criteria:

• Mechanical: “The joint holds under a 50 kg load with less than 2 mm deflection at the tip,” or “the mechanism engages one-handed in under half a second.”
• Usability: “Five of five test users assemble it without instructions,” or “four in five find the right setting within 20 seconds.”
• Manufacturing: “Unit cost at the target volume comes in under our ceiling,” or “lead time is under 12 weeks.”

Write the criteria down before you start. When the test is finished you’ll know immediately whether you passed or need to iterate — and you’ll stop the “let’s just tweak it a bit more” spiral that quietly eats time and money.

5. What happens after the prototype?

A prototype is a waypoint, not a destination. Decide your next move before you build, for all three outcomes:

• If it passes: what’s the next milestone — customer trials, a cost-down round, a manufacturing quote? Name it now.
• If it fails: is it the concept that’s wrong, or your execution of it? Decide whether you iterate or stop — ideally before you’re emotionally attached to the build.
• If it’s inconclusive: what extra information would actually settle it? A second test, a variant, more user feedback? Be honest, and don’t iterate forever because you’re unsure.

“Build something and see what happens” is not a plan. Map the validation path first.

The decision framework, in practice

Most founders skip the first five steps and jump straight to building. That’s precisely why they iterate forever. Spend a day on the questions above and you’ll clarify the next two or three months of work — and avoid building the wrong thing well.

In the 10-stage process this sits at: Stage 08 · Develop  —  see the full process →