1st Jul 2026
The right physical prototype at the right stage catches problems that no amount of digital modelling will surface. Here is why that matters more than most clients realise.
The prototype that saves a project is rarely the sophisticated one. It is usually the rough one, built quickly from foam and card at a stage when the design still feels provisional, that reveals the problem nobody had seen coming. A proportion that was wrong. An ergonomic detail that did not work in three dimensions. A mechanism that was theoretically sound but physically awkward. These things cannot be found on a screen.
The question is not whether a prototype will reveal problems. It always does. The question is when.
The cost of finding out late
In physical production, the cost of discovering a problem scales with how far into the process you are when you find it. A problem caught at the concept sketch stage costs a conversation. The same problem caught at the CAD stage costs a day of redraw. Caught at the prototype stage, it costs the prototype and a revised build. Caught after production tooling has been committed, it costs the tooling.
This is a well-understood principle that is routinely ignored in practice, because the early prototype always feels like an additional cost rather than an insurance policy. The brief has been agreed. The timeline is tight. The client wants to see progress. Building a rough foam model seems like a detour when there is a polished CAD render to present instead.
The renders always look better than the real thing at that stage. That is the problem. Renders do not reveal scale. They do not reveal weight or balance. They do not reveal the feeling of a handle in a hand or the way a mechanism operates under load. They are optimistic by nature, and they create confidence that has not yet been tested against physical reality.
What a prototype actually tests
The most useful prototypes are the ones built to test a specific question rather than to demonstrate a design. Does this form feel right at this scale? Does this mechanism operate smoothly? Does this surface treatment read correctly in the intended lighting environment? Can this be assembled by one person without tools?
When the question is clear before the prototype is built, the prototype produces a clear answer. When the prototype is built to show rather than test, the answer is usually “it looks fine,” which is not actually useful information at the development stage.
Fidelity is a design decision
Not every prototype needs to be production-equivalent. A rough appearance model in foam tells you about scale and proportion without costing the time or budget of a finished prototype. A functional model in machined plastic tells you about mechanism performance without matching the final material specification. A presentation prototype in the intended materials and finish tells your stakeholders everything they need to feel confident in the design.
Choosing the right fidelity for the purpose is a skill. Over-engineering a prototype wastes time and money. Under-engineering it produces the wrong information. We spend time at the start of a prototype brief understanding what question needs to be answered, because the answer determines what we build and how we build it.
The iteration question
Clients sometimes ask how many prototype rounds they should expect. The honest answer is that it depends on how well defined the requirements are at the start and how much the design changes in response to what the prototypes reveal. A well-specified brief with clear performance requirements typically needs fewer iterations than an open-ended exploration.
What we try to establish from the beginning of a prototype programme is what a successful outcome looks like. If we know what we are testing against, we can structure the iterations efficiently and recognise when the design has reached the point where further prototyping adds cost without adding information.
When to start
Earlier than you think. The prototype that saves a project is almost always built at the stage when the project team felt too busy, too early, or too confident in the render to commission one. Build the rough model before the brief is locked. Put it in the room and look at it. The conversation that follows will be more useful than another week of screen-based development.
→ Download this article as PDF
Start a Project
Tell us what you need to build. We will take it from there.