Proof of Concept vs Looks-Like vs Works-Like Prototype

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

Quick Answer

Build:

Most serious hardware products eventually need both looks-like and works-like evidence. The key is building them in the right order.

Definitions

| 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? |

When to Start With Proof of Concept

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.

When to Start With Looks-Like

Start here if:

This is common for consumer products, creator-led products, and hardware where desirability strongly affects demand.

When to Start With Works-Like

Start here if:

That often applies to connected devices, automation tools, and utility-driven hardware.

The Better Founder Question

Do not ask:

"Which prototype is best?"

Ask:

"What does this product need to prove next?"

That answer tells you what to build first.

How Haitch Supports These Stages

Use:

The point is not to force one sequence.

It is to make each prototype stage legible and connected.

A Simple Decision Table

| 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 |

Common Mistakes

Mistake 1: Polishing too early

Teams spend money making something beautiful before the core thing works.

Mistake 2: Staying ugly too long

Teams prove technical function but never create enough form credibility to validate demand.

Mistake 3: Treating all prototype stages as one

Each stage has a different job. Confusing them creates wasted effort.

Related Reading

FAQ

What should a hardware startup build first?

Build the prototype type that proves the biggest unanswered question next.

Is a proof of concept the same as a prototype?

It is a type of prototype, but its job is narrower: proving feasibility.

Do you need both looks-like and works-like prototypes?

Often yes, especially when buyers must trust both product form and product behavior.

Can one prototype do both jobs?

Sometimes, but early teams often move faster by separating proof stages before combining them.

When should you combine them?

When the product is mature enough that customer-facing validation requires both functional and visual credibility.

References

Final Recommendation

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