From Prototype to Production

Most hardware programs do not fail at the idea. They fail in the transition from a prototype that works to a product that can be built. This is the part of the program where decisions are expensive, timelines are opaque, and external help is most often brought in too late.

This is what the market calls the “Valley of Death.” The number most often quoted is that ninety percent of hardware startups die crossing it. The phrase is accurate. The explanation is usually not. Teams do not die here because manufacturing is hard. They die here because they treat the production transition as a continuation of the prototype, when it is a different project.

This page is the decision framework we use on every program we own — whether we are leading a new product from zero, rescuing a prototype that was built by someone else, or hardening an engineering build for its first real factory run. It is not a phase chart. Phase charts do not tell you what decisions to make. This does.

What “production” actually means

Most teams we meet use the word “production” to mean “more prototypes.” It does not. Production is the point at which a product is produced by people who did not design it, on equipment that does not belong to you, using components you cannot hand-select, at a cost that has to clear a margin, at a variance narrow enough that your support team does not get destroyed.

Concretely, for a hardware product, “production-ready” means:

• Yield is predictable. You know what first-pass yield looks like at the CM, what drops it out of spec, and what the rework loop costs.
• Unit cost is locked. Your BOM is priced at real volume, not MOQ minimums. Your second-source list is real. You know what parts will be expensive in Q4 and why.
• Variance is bounded. The difference between the tenth unit off the line and the ten-thousandth is inside your spec, not your hope.
• Supply chain has been stress-tested. You know what happens if your primary supplier misses a delivery. You have a second source qualified or a plan to qualify one. No critical part is single-sourced from a component you have not audited.
• Test strategy produces the data you need. End-of-line test catches the defects that actually occur. It runs at line speed. It does not require the original engineer to interpret the results.
• Calibration, serialization, and firmware provisioning work without a laptop. The line technician can assemble, program, and ship a unit without needing the design team.
• Service, warranty, and field update paths exist. You can patch a unit in the field. You can diagnose a failure without shipping it back. You know what your warranty reserve should be.

None of these are test phases. They are commitments. The program has to converge on every one of them before first real production. Prototypes almost never do.

The four structural reasons hardware dies in the transition

After twenty-plus programs across industrial robotics, medical devices, power electronics, consumer hardware, and life-safety systems, we see the same four failure modes.

1. The architecture was optimized for the prototype

A prototype is a demonstration. A product is a fleet. The architecture that makes a demo work is often exactly the architecture that makes the fleet unscalable.

The most common version of this: a working prototype runs its control loop on a consumer single-board computer — a Raspberry Pi, an off-the-shelf NUC, a dev-kit with a serial number on a sticker. For a demo, this is fine. For a fleet of ten thousand units deployed outdoors, in industrial environments, serviced over ten years, it is a liability. Consumer SBCs are not designed for thermal extremes, vibration, radiated-emissions compliance, deterministic timing, or component availability beyond a two-year horizon.

We have done this migration inside a scaling company. At Aerones, the existing robot fleet ran critical subsystems — motor control, sensor fusion, safety interlocks — on Raspberry Pi boards. It worked for early commercial operations. It did not work for a fleet servicing ten thousand turbines a year across twenty-seven countries. The migration to Beckhoff industrial controllers was not a component swap. It was a complete rearchitecture: separating hard real-time control from supervisory functions, selecting the right industrial fieldbus, defining what fails gracefully versus what stops the operation, and doing it without pausing the business.

That kind of migration is what the transition looks like when it is done late. The lesson is the earlier one: do not put anything into a prototype that cannot be the answer in production. If the architecture will change before ship, the prototype is teaching you nothing about the product you are building.

2. The components cannot scale

Prototyping uses the parts that were easy to buy. Production uses the parts that will be buildable in three years.

The failure mode here is quiet. The BOM you used to build ten prototypes includes a connector with a sixteen-week lead time, a microcontroller that is near end-of-life, a sensor with a minimum order quantity of twenty-five thousand units, and a power management IC that is allocated for automotive in your run window. You did not choose these parts. Your engineer chose them because they were in the drawer.

A disciplined BOM review at the transition asks, for every line item:

• What is the real lead time at the volume we need?
• What is the EOL status? What is the last-time-buy horizon?
• Is there a second source? Is the second source pin-compatible and electrically equivalent, or just a datasheet near-match?
• What is the MOQ? Does that MOQ map to a run size the business can commit to?
• What is the part’s price trajectory? Is it in the supply-shock path of any current geopolitics?

Most prototype BOMs fail most of these questions. The teams that get across the transition do the BOM review twice: once at DVT for a systematic scrub, and again at PVT with the contract manufacturer in the room, because the CM will see sourcing risks the design team cannot.

3. Yield is extrapolated from a sample size of five

A prototype run of five to twenty units, assembled by the engineer who designed them, has no predictive value for what a production run of five hundred will yield. None. The person assembling the prototypes is tuning their technique as they go. They are solving problems silently. They know which solder joints need a second look. They know which firmware flash sequence is flaky. That knowledge does not ship to the CM.

We have watched programs get blindsided when their first real pilot run — five hundred units, external line, real operators — produced a forty percent first-pass yield on something the team was sure was production-ready. That outcome is not a CM failure. It is a program that skipped the steps where prototype-stage process parameters get translated into line parameters.

The bridging work is unglamorous and specific: tolerance stack analysis against actual measured parts, not datasheets. Test jig design that a line operator can use without training. Firmware provisioning and calibration flows that do not require a laptop in the clean room. End-of-line test coverage that catches the defects that actually occur in volume, not the ones the team worried about in design review.

4. Firmware and hardware diverge silently

In a prototype, the firmware is written against the board in front of the engineer. In production, firmware is written against a part number, a board revision, a calibration file, and a serialization scheme — none of which exist as artifacts on most prototype programs.

The failure mode: the DVT units work. The PVT units mostly work. The first factory run has a ten percent failure rate and nobody can tell whether it is a hardware issue, a firmware issue, a calibration issue, or a line-process issue. The feedback loop closes after three weeks of triage, and the trust between the design team and the CM never fully recovers.

The cure is a firmware and calibration workflow that treats the production line as a first-class deployment target. Bootloader strategy. Signed firmware. Per-unit calibration persisted in a traceable way. Serial number allocation from a single source of truth. End-of-line test that writes calibration and verifies it in one pass. These decisions have to be made at EVT at the latest. Making them at PVT means they will not be ready at first run.

The decision framework: five calls that define the transition

A prototype-to-production transition is not a linear phase. It is a convergence on five decisions. If any one of them is still open when the program commits to tooling and first production, the program will slip. Every time.

Five convergence points. Miss one, the transition is a coin flip.

Decision 1 — Architecture freeze

What is decided: The architecture of the product is frozen. No further changes to which board handles which subsystem, which bus connects them, which processor owns real-time control, or which memory and storage footprint the firmware is allowed to use.

How to know you are ready: You can describe the full product as a single diagram with every major component and every interface. You can justify each one against production, not demo. You can show why a change to any one of them would ripple into the schedule, and quantify that ripple.

How teams get it wrong: They freeze the mechanical architecture but leave the electronics open. Or they freeze the electronics but leave the firmware architecture in active refactor. The freeze has to be across layers or it is not a freeze.

Decision 2 — BOM maturity

What is decided: Every line on the BOM has a primary source, a qualified secondary source where critical, a price at real volume, a lead time, an EOL horizon, and a package and footprint that match the PCB design that will go to tooling.

How to know you are ready: You can hand the BOM to a CM and ask for a quote without providing any additional context, and the quote comes back without twenty questions attached. You can survive a primary supplier missing a delivery on any one critical part without stopping the line.

How teams get it wrong: The BOM is frozen for the design team but not for procurement. A part that works for DVT has a three-month lead time at production volume, which nobody checks until the CM does.

Decision 3 — Test strategy

What is decided: What gets tested at the CM, on what equipment, at what line position, with what pass/fail criteria, feeding what data into what system of record.

How to know you are ready: The test plan specifies end-of-line test, burn-in if applicable, sample-based reliability testing, and any functional test that gates shipment. Test equipment is sourced or built. Test fixture design is complete. A line technician — not the design engineer — can run the test and interpret the result.

How teams get it wrong: Test is “the engineer plugs it in and checks.” It does not scale past a pilot run. Or test is over-designed, covering failure modes that never occur, while missing the ones that do.

Decision 4 — DFM sign-off

What is decided: The mechanical, PCB, and assembly designs are reviewed and accepted by the people who will actually build the product. Tolerances are buildable. Assembly sequences are economical. Panelization is efficient. Test access is in place. Fasteners, connectors, and interfaces match the CM’s standard tooling where possible.

How to know you are ready: The CM signs off on the design package. The tolerance analysis has been run against real parts. First-article inspection data is available and in spec. No open issues remain that would require rework on the line.

How teams get it wrong: DFM is treated as a review gate on a completed design, rather than a continuous dialogue with the CM throughout DVT. Design decisions get made without knowing what they will cost to build.

Decision 5 — Supplier commitment

What is decided: The CM relationship is real — a signed manufacturing agreement, committed capacity in a specific window, agreed pricing at real volume, clear quality terms, and a clear escalation path for the first real issue.

How to know you are ready: Both parties have signed the MSA and the first PO. The CM understands what product they are building, has reviewed the full BOM and package, and has committed to the first production window. Your logistics, warranty, and support paths are defined downstream of the CM.

How teams get it wrong: The CM relationship is informal or quote-based through pilot. When the first run has a problem, there is no agreed framework for who owns it, who pays, and how the issue is resolved. The program loses a month to re-negotiation.

When these five decisions are converged, the transition is de-risked. When any one is still open, first production is a coin flip.

EVT, DVT, and PVT — as decision gates, not test phases

Every hardware blog on the internet defines these acronyms. Most miss the point. EVT, DVT, and PVT are not types of tests. They are decision gates where specific questions have to be answered before the program moves forward.

EVT — Engineering Validation Test

The question being answered: Does the design as built match the design as intended? Does the architecture actually work when reduced to hardware?

What is on the line: Typically three to ten hand-built units. The unit under test is the first physical manifestation of the full system. Enclosures may be machined or 3D-printed. PCBs are typically fab-and-assemble runs done quickly. Firmware is functional but not yet hardened.

What must be decided here: The architecture decision. At the end of EVT, the architecture is either validated — the system works, the interfaces behave, the thermal envelope is survivable, the firmware can hit its timing — or it is not, and you go back one step. You do not pass EVT with “it mostly works.” You pass by knowing, with measured data, that the system meets its performance, thermal, power, and timing requirements in hardware.

What to defer: Cosmetic finish, labeling, final BOM locking, packaging, certification submissions. EVT is not where these are closed.

Where teams get this wrong: They treat EVT as a demo run. They build three units, show them working, pass the gate, and leave known issues unresolved because they are cosmetic or edge-case. The issues resurface at DVT where they are five times more expensive.

DVT — Design Validation Test

The question being answered: Is the design robust enough, across units and across environments, to be handed to a manufacturer?

What is on the line: Twenty to a hundred units, built with production-intent parts, on production-intent tooling where possible. Injection-molded parts if the program uses them. Final-rev PCBs. Firmware hardened and frozen for the DVT window.

What must be decided here: Environmental, reliability, and regulatory performance. Units are subjected to temperature and humidity cycling, vibration, drop, ESD, conducted and radiated emissions, and whatever environmental exposure the product will face. Certification submissions are prepared from this unit set. The BOM is fully locked. DFM review is complete. Test strategy is proven.

What to defer: Line yield tuning, volume-scale supply chain commitment, end-of-line test fixture final integration.

Where teams get this wrong: They treat DVT as “bigger EVT.” The same hand-builders, the same loose tolerances, the same firmware-under-refactor. They then hit PVT and discover that the variance between units is enormous — because the units were not built under production-intent discipline.

PVT — Production Validation Test

The question being answered: Can the product be built at production scale, at production yield, at production cost, on the CM’s line, by the CM’s operators?

What is on the line: A real production run — often several hundred to a thousand units — built on the line that will build the product in volume, by the team that will build it.

What must be decided here: Yield. Line balance. End-of-line test coverage. Final-revision tooling. Any remaining DFM issue is resolved or consciously accepted with a rework plan. The CM commits to ramp.

What to defer: Nothing. PVT is the last gate before first production. Anything unresolved here becomes a production problem.

Where teams get this wrong: They compress the window. They treat PVT as a rubber-stamp on DVT. They skip the end-to-end test-fixture validation. They then discover at first production that a piece of line equipment does not match the firmware provisioning flow, and they have to pull the line down to fix it.

These three gates are three questions. Each one is a separate and more expensive commitment. The discipline is in knowing which question you are answering, what has to be true to pass, and what has to be deferred rather than smuggled across.

The component trap — and the migration decision

The single most common cause of prototype-to-production failure in systems we are brought in to rescue is a prototype architecture built on components that cannot be in the final product. Consumer single-board computers are the emblematic case. Development kits are the second. Third-party modules with opaque long-term support are the third.

The question is not “is this part good enough for the prototype.” The question is “if this part has to stay, can it still be true in three years across every unit we plan to ship?” If the answer is no — thermal, lead time, EOL, price, certification, anything — then the part is a migration problem. The migration can happen now, when it is cheap, or it can happen later under schedule pressure, when it will cost a quarter of engineering time and defer the transition by six months.

We have written the full breakdown of this decision at When Raspberry Pi Strands Production (And When It Doesn’t). It is not an anti-SBC essay. It is a decision framework. Some products ship on Raspberry Pi Compute Modules and are the better for it. Most don’t.

DFM: the calls that don’t show up on drawings

Design for manufacturing is not a checklist. It is a set of design decisions, made continuously from EVT onward, that determine whether the product can be built predictably. The teams that own DFM well tend to own a few specific things:

• Tolerance philosophy. The decision about how tight to specify a tolerance is a cost decision. Every extra digit of precision on a drawing is a real cost at the factory. The teams that ship at margin know which tolerances actually matter and loosen the rest.
• Second sources by design. Every critical part has at least one pin-compatible alternate. Every critical mechanical feature is machinable on more than one process. Nothing depends on one vendor being in business on your run window.
• Line-operable test fixtures. The test rig is designed from day one to be operated by a line technician with two hours of training, not the engineer who built the prototype. It uses industrial connectors. It fails safely. It writes its results to a traceable record.
• Assembly sequence economy. The product can be assembled in an order that is fast, buildable, and error-resistant. Fasteners are standardized. Screw counts are minimized. No assembly step requires more than one operator.
• Calibration and provisioning as part of the line. End-of-line test calibrates the unit, programs serialization, flashes firmware, and verifies — all in one station, at line speed, without engineering intervention.

We cover the DFM gate in more depth at DFM: The Decisions That Don’t Show Up on Drawings. It is the call that most determines first-run yield.

What first-run yield looks like when the transition is done right

For a well-managed hardware transition, first-pass yield on first real production should be in the mid-to-high nineties on a straightforward electromechanical product, and above eighty-five percent on a complex system with mechanical, electronic, and optical elements. First-pass yield in the sixties or below on first PVT is a signal that the transition was not done — regardless of what passed on paper.

The second signal is process stability. The tenth unit off the line and the five-hundredth unit off the line should land in the same spec window. If the line needs to be re-tuned every hundred units, the transition has pushed a variance problem into production. The fix is not faster operators. It is design iteration that never happened before commitment.

The third signal is CM confidence. Contract manufacturers know within the first fifty units of a first run whether the program is ready or not. The good ones will tell you. They are right.

At Rheo Dive, we took a consumer hardware product through POC, EVT, DVT, PVT, and mass production — custom optics, custom PCBA, silicone over-molded tooling, an iOS app, and a dive computer under twenty meters of saltwater. Every one of the five decisions above had to be converged before first tooling. The result was a first production run that met yield on first pass.

This is what the work looks like when the transition is treated as its own program, not as an extension of prototyping.

When to bring external leadership in

The production transition is the part of a hardware program where a senior external technical lead — an ad-hoc CTO, an embedded product engineering team, or both — is most economical. Not because engineering talent is scarce. Usually it is not. Because direction is.

A good external lead at this stage does three things:

1. Forces the five decisions above into explicit convergence on a known schedule — architecture freeze, BOM maturity, test strategy, DFM sign-off, supplier commitment — rather than letting them drift in parallel.
2. Brings pattern recognition from other hardware programs. Most in-house teams go through the production transition once or twice in a career. An external lead who has been through it ten times spots failure modes the internal team cannot.
3. Owns the CM relationship with authority equal to the CM’s technical counterpart. A founder with a strong background in industrial design or software will not negotiate tooling amortization effectively. A senior production-biased engineering lead will.

The rule we give every founder we talk to: if you are within six months of first production and you are not sure every one of the five decisions above is converged, bring help in now. The cost of fixing a wrong architecture at production is not linearly higher than fixing it at EVT. It is ten to twenty times higher, and it is measured in months of lost market position as well as in euros.

Related reading

• The Hardware Product Development Process, Reframed
• Why Hardware MVPs Fail (And What to Build Instead)
• EVT, DVT, PVT: What Each Gate Actually Decides
• DFM: The Decisions That Don’t Show Up on Drawings
• Choosing a Contract Manufacturer (From the Inside)
• When Raspberry Pi Strands Production (And When It Doesn’t)
• Why Hardware Projects Overrun by 12+ Months