Why hardware scale-ups fail between prototype and production
A working prototype proves the idea. It does not prove that the product can be built repeatably, to cost, at quality, by someone else. Most hardware businesses underestimate the distance between the two.
Written by Dr Gareth Mills. Practical field notes from operating roles in hardware and technology businesses.
A working prototype is an important milestone.
It is also one of the most dangerous points in the development of a hardware business.
Once a product works, there is a natural tendency to believe that the difficult part has been completed. The technology has been demonstrated, customers may be interested, investors can see something tangible and the organisation starts thinking about launch.
But a working prototype proves surprisingly little about the company's ability to manufacture and supply a commercial product.
It proves that the product can be made.
It does not prove that it can be made repeatedly, at the required quality, at the required cost, in the required quantities, by a production organisation rather than the engineering team that designed it.
That difference is where a great many hardware companies get into difficulty.
A prototype and a product are not the same thing
Prototype development is primarily concerned with functionality.
Can we make it work?
Industrialisation asks a very different set of questions:
Can somebody else build it?
Can they build the next one exactly the same way?
Can we test whether they have built it correctly?
Can we procure the components consistently?
Can we manufacture it within the target time?
Can we demonstrate regulatory compliance?
Can it survive shipping, installation and real-world use?
Can we service it?
Can we make enough of them?
And, critically, can we make money doing it?
Those questions require a different operational discipline from the one needed to create the original technology.
A prototype may contain hand modifications, engineering judgement, specially selected components, manually adjusted assemblies and parts bought in quantities of five or ten.
None of those things is necessarily a problem during development.
They become major problems when the company needs to build 100, 1,000 or 10,000 units.
The hidden knowledge problem
One of the first industrialisation problems is rarely visible on a drawing or BOM.
Knowledge sits inside people's heads.
The engineer who designed the product knows that a particular connector needs to be fitted in a certain sequence.
Someone else knows that a cable needs to be routed slightly differently from the drawing.
Another person knows which firmware version actually works.
A technician knows that a particular assembly needs adjusting before test.
The prototype works because the people closest to the development compensate for what is missing from the production system.
Then manufacturing is transferred to someone else and those compensations disappear.
This is why one of the most important tests of manufacturing readiness is simple:
Can somebody who did not design the product build it correctly from the released production information?
If the answer is no, the product is not production ready.
The production data pack therefore matters enormously. Drawings, BOMs, work instructions, test specifications, firmware, software, inspection criteria, approved components and configuration status need to describe the product sufficiently well that manufacture is repeatable without relying on tribal knowledge.
Design maturity gets exposed by volume
Small numbers conceal problems.
Volume amplifies them.
A component that takes an experienced technician two minutes to fit but a normal operator twelve minutes to fit may not matter when building five systems.
It matters enormously when building 1,000.
The same applies to:
- Components with unnecessarily tight tolerances
- Parts that require hand finishing
- Assemblies with poor access
- Difficult cable routing
- Excessive fastener counts
- Components with long or unstable lead times
- Parts available from only one supplier
- Designs requiring specialist assembly skills
- Excessive calibration
- Manual test processes
- Unclear workmanship standards
This is why Design for Manufacture and Design for Assembly should not be treated as a final manufacturing review.
They should be part of product development.
The objective is not simply to make the design easier for the factory.
It is to remove unnecessary cost, variability and risk before those problems become embedded in production.
The BOM is an operational document
Engineering teams understandably concentrate on whether a component performs correctly.
Operations has to ask additional questions.
Can we actually buy it?
From whom?
In what quantity?
At what lead time?
At what price?
What happens if it becomes unavailable?
Is it approaching end of life?
Do we have an approved alternative?
Does it have a minimum order quantity?
Is it affected by export controls or regulatory requirements?
Can our contract manufacturer source it?
Who owns the relationship with the supplier?
A prototype BOM can contain dozens of future supply-chain problems without anybody noticing.
This becomes particularly dangerous when a business starts forecasting production using the longest manufacturing lead time while ignoring the longest material lead time.
If a product takes four weeks to assemble but contains a component with a 40-week lead time, the effective production constraint is not four weeks.
It is 40 weeks.
Scaling hardware therefore requires a proper material strategy, including approved suppliers, long-lead identification, lifecycle monitoring, alternate sourcing, demand forecasting and appropriate risk buys.
Test becomes part of the manufacturing process
Prototype testing asks:
Does the design work?
Production testing asks:
Was this individual unit built correctly?
Those are not the same question.
A development engineer may be capable of spending several hours diagnosing a failed prototype.
A production line cannot operate that way.
The manufacturing test strategy must establish:
- What gets tested
- At which stage it gets tested
- What equipment is required
- What constitutes a pass
- What data is recorded
- How results are traceable
- What happens when something fails
- How test equipment itself is controlled
- How long each test takes
- Whether the test process can support planned production volumes
Companies frequently discover this too late.
They develop sophisticated products and then realise that the production test takes several hours, requires expensive laboratory equipment or depends on somebody interpreting results manually.
Testability needs to be designed into the product.
Quality cannot be inspected into the product
Another common transition problem is treating quality as a final inspection activity.
It is not.
Final inspection can identify some defects.
It cannot create a capable manufacturing process.
A scalable quality system begins much earlier.
Critical characteristics need to be identified. Incoming inspection needs to reflect supplier risk. Processes need defined controls. Workmanship standards need to be clear. Non-conformance needs a controlled process. Supplier issues need corrective action. Serial numbers, batches and software versions need traceability where appropriate.
Most importantly, failures need to create learning.
A mature production organisation does not simply fix defective units.
It asks why the defect occurred and changes the process so that it becomes less likely to happen again.
That feedback loop is one of the major differences between prototype building and production engineering.
The factory is part of the product system
Choosing a contract manufacturer is not simply a procurement exercise.
The manufacturing partner becomes part of the company's operating system.
The right manufacturer depends on the product, volume, complexity, regulatory environment, geography, supply chain and expected rate of growth.
The largest manufacturer is not automatically the best manufacturer.
Neither is the cheapest.
A hardware company moving from early builds into production needs to understand whether the manufacturing partner can support:
- New product introduction
- Engineering change
- Controlled documentation
- Supplier management
- Appropriate quality systems
- Production test
- Traceability
- Capacity growth
- Cost reduction
- Failure analysis
- Rework and repair
- Regulatory obligations
- Logistics
- Future product variants
The relationship also needs commercial clarity.
Who buys the components?
Who owns excess inventory?
Who pays when forecasts change?
Who owns tooling?
Who controls subcontractors?
What happens if there is a quality problem?
What capacity has actually been reserved?
Those questions become extremely important once meaningful money is being committed.
EVT, DVT and PVT should mean something
Hardware companies often use terms such as EVT, DVT and PVT, but sometimes without defining what passing each stage actually requires.
That defeats much of their purpose.
A development gate should represent a reduction in uncertainty.
For example, the organisation might need evidence that:
Engineering Validation Testing has demonstrated that the architecture and major technical functions perform as intended.
Design Validation Testing has demonstrated that the production-intent design meets the defined product requirements, including relevant reliability and compliance requirements.
Production Validation Testing has demonstrated that the production-intent product can be manufactured using the intended processes, tooling, test equipment, documentation and supply chain.
The exact terminology matters less than the discipline.
A gate should not be passed because the calendar says it is time to move on.
It should be passed because the evidence demonstrates that the organisation has reduced the relevant risks sufficiently to justify the next level of investment.
Production readiness is cross-functional
Industrialisation fails when it is treated as a manufacturing department activity.
It involves almost every part of the company.
Engineering owns design maturity.
Supply chain owns material availability.
Quality owns process assurance.
Regulatory owns compliance evidence.
Operations owns production capability.
Finance needs working-capital visibility.
Commercial teams create the demand signal.
Service teams need repair and support capability.
Leadership has to make the trade-offs.
If these functions operate separately, problems move downstream until somebody is forced to deal with them.
For example, sales increases the forecast.
Procurement buys material.
Engineering changes the design.
Old inventory becomes unusable.
Finance discovers the working-capital impact afterwards.
All four functions individually did something understandable.
The operating system failed.
The cash requirement is often underestimated
Hardware consumes cash before it generates revenue.
That sounds obvious, but growing businesses repeatedly underestimate how severe the effect can become.
Long-lead components may need to be purchased months before shipment.
Suppliers may require deposits.
Tooling requires upfront expenditure.
Contract manufacturers may require material commitments.
Finished goods may sit in transit.
Customers may pay 30, 60 or 90 days after delivery.
Growth can therefore create a working-capital problem even when gross margins look attractive.
A credible scale-up plan has to connect:
forecast -> procurement -> production -> inventory -> shipment -> customer payment
Without that model, a business can win orders and still run into serious cash constraints.
Reliability changes once the product reaches customers
Development teams often concentrate on whether a product passes its functional tests.
Customers experience something different.
They experience installation, transport, temperature, vibration, electrical disturbances, operator behaviour, software updates and thousands of hours of use.
Reliability therefore needs its own plan.
That may include environmental testing, accelerated testing, transport trials, component derating, life testing, failure-mode analysis and controlled field feedback.
Early field failures are particularly expensive.
There is the direct cost of repair, replacement and logistics, but the larger cost may be loss of customer confidence.
The first production units therefore need greater operational scrutiny, not less.
The stage between prototype and production needs to be managed deliberately
The central mistake is seeing industrialisation as a short bridge between development and manufacturing.
It is better understood as a major phase of product development in its own right.
Before committing to meaningful volume, leadership should be able to answer some very basic questions:
Can the product be built from controlled documentation?
Is the design sufficiently mature?
Are the critical suppliers known and capable?
Are long-lead materials understood?
Is there a production test strategy?
Is the quality system capable of supporting manufacture?
Are regulatory responsibilities clear?
Can the planned factory achieve the required output?
Are unit economics based on real production assumptions?
Is working capital understood?
Can the product be serviced and repaired?
Do we know what evidence is required before increasing the production rate?
If those questions do not have clear answers, scaling production will not solve the problem.
It will simply scale the uncertainty.
Industrialisation is where a hardware company becomes an operating business
Inventing something valuable is difficult.
Turning it into a product that can be supplied repeatedly, profitably and reliably is a different challenge.
The companies that manage this transition well do not wait until the prototype is finished before thinking about operations.
They progressively build the manufacturing system, supply chain, quality processes, test strategy, data, organisation and commercial controls alongside the product itself.
Because the real milestone is not when the first product works.
It is when the hundredth product can be built by somebody else, performs like the first one, arrives when the customer expects it and still generates the margin the business model promised.
That is the point at which a prototype has truly become a product.
If this is a live problem in your business rather than a reading topic, start a confidential conversation.
