Most founders underestimate prototype cost because they count the first artifact and ignore the revision loop.
That is the mistake.
A hardware prototype is not one object. It is usually a sequence of decisions, parts, tests, failures, and refinements before the team reaches something stable enough to validate externally.
Start here: Use Haitch to shorten prototype loops before manufacturing
For most early teams, prototype cost before manufacturing includes:
The right question is not "what does one prototype cost?"
It is:
What will it cost to get to the first validation-ready prototype?
This guide is for:
| Cost bucket | What it covers |
| --- | --- |
| Product definition | concept direction, requirements, architecture, assumptions |
| Design work | CAD, system planning, firmware definition, revisions |
| Prototype materials | boards, components, printed parts, machined parts, enclosures |
| Fabrication | 3D printing, CNC, PCB fab, assembly services |
| Testing | fixtures, instruments, sample parts, destructive learning |
| Rework | redesign after fit, usability, or reliability failures |
This stage answers: does the core thing work at all?
Typical spend goes into:
This is where costs usually rise because the product must start becoming legible to customers, testers, or partners.
Typical spend goes into:
This stage answers: is this real enough to show, test, reserve, pre-sell, or hand to suppliers?
Typical spend goes into:
These are directional ranges, not universal rules:
| Prototype type | Typical early range | Notes |
| --- | --- | --- |
| Simple mechanical product | hundreds to low thousands | depends on material and geometry complexity |
| Electronics accessory | low thousands to mid-thousands | boards, enclosures, assembly, debugging |
| Connected hardware device | mid-thousands and up | firmware, integration, power, enclosure, test loops |
The variable that changes everything is not just product complexity.
It is how many iterations you need before the prototype becomes validation-ready.
If concept, CAD, firmware, and system decisions are disconnected, the team pays for the same learning more than once.
Founders often spend too much on finish before the product promise is validated.
Teams move into fabrication before architecture, fit assumptions, or validation goals are stable enough.
Custom everything is rarely the cheapest path to learning.
Use this model:
Prototype budget = artifact cost + iteration count + testing cost + coordination overhead
Then estimate:
1. what one build round costs
2. how many rounds are likely before external validation
3. what testing and failures will add
4. what coordination friction is costing the team in time
Haitch is useful here because prototype spend is not only about fabrication.
It is also about how expensive your learning loops are.
If the product context stays connected across:
then the team can often reduce rework caused by ambiguous decisions and poor handoffs.
That does not remove fabrication cost.
It reduces avoidable iteration cost.
Before manufacturing, do not budget only for "the prototype."
Budget for:
That is usually closer to reality.
It depends on product complexity and iteration count, but the real budget must include design, fabrication, testing, and rework, not just one build.
Treating the first prototype as the full cost instead of budgeting for multiple learning loops.
Usually learning speed. The cheapest prototype is not useful if it delays clear product decisions.
Because fit issues, firmware changes, assembly problems, and customer-facing readiness usually appear across multiple rounds.
When the team can show a clear product story, stable enough functionality, and believable outputs for the specific validation offer.
Prototype cost before manufacturing is not a line item. It is a sequence.
Budget for the prototype loop, not the prototype object.
Next step: Start building on Haitch