Many hardware teams waste months because they build the wrong kind of prototype first.
They jump into enclosure polish before function is proven, or they stay in rough proof-of-concept mode long after the product needs to become customer-legible.
Start here: Use Haitch to move from concept to the right prototype stage faster
Build:
Most serious hardware products eventually need both looks-like and works-like evidence. The key is building them in the right order.
| Prototype type | Main question it answers |
| --- | --- |
| Proof of concept | Can the core mechanism or behavior work at all? |
| Looks-like prototype | Can people understand and believe the product form? |
| Works-like prototype | Can the product behave credibly in real usage? |
Start here if the team still does not know whether the core idea is technically feasible.
Examples:
This stage is about de-risking the core idea, not making the product presentable.
Start here if:
This is common for consumer products, creator-led products, and hardware where desirability strongly affects demand.
Start here if:
That often applies to connected devices, automation tools, and utility-driven hardware.
Do not ask:
"Which prototype is best?"
Ask:
"What does this product need to prove next?"
That answer tells you what to build first.
Use:
The point is not to force one sequence.
It is to make each prototype stage legible and connected.
| If your biggest uncertainty is... | Build first... |
| --- | --- |
| technical feasibility | proof of concept |
| buyer reaction to form | looks-like prototype |
| trust in product behavior | works-like prototype |
| both desirability and functionality | a staged combination of looks-like and works-like proof |
Teams spend money making something beautiful before the core thing works.
Teams prove technical function but never create enough form credibility to validate demand.
Each stage has a different job. Confusing them creates wasted effort.
Build the prototype type that proves the biggest unanswered question next.
It is a type of prototype, but its job is narrower: proving feasibility.
Often yes, especially when buyers must trust both product form and product behavior.
Sometimes, but early teams often move faster by separating proof stages before combining them.
When the product is mature enough that customer-facing validation requires both functional and visual credibility.
The best first prototype is the one that proves the next critical truth.
Build for the next decision, not for generic completeness.
Next step: Start building on Haitch