PoC, EVT, DVT, PVT: What Each Hardware Gate Actually Decides

Every hardware program puts the same four acronyms on a Gantt chart: PoC, EVT, DVT, PVT. Most teams treat them as testing phases — build-and-check cycles that get progressively bigger. That framing is wrong. It is why programs slip at the last gate.

PoC, EVT, DVT, and PVT are decision gates. Each answers exactly one question. Each commits the program to something harder to reverse than the last. Treat them as test phases and you smuggle unresolved issues across each gate, then discover them when they cost ten or twenty times more to fix.

This is the field guide we use on every program — what each gate decides, what to defer, the typical unit counts, the typical tooling, and the cost of getting any one wrong.

The lifecycle in one paragraph

A hardware program moves through five stages. PoC answers whether the core mechanism can work at all — bench experiments on a dev kit, one to three units. EVT validates that the architecture works in real hardware — three to ten engineering units, quick-turn PCBs, soft tooling. DVT proves the design is robust across units, environments, and operators — twenty to two hundred units, production-intent tooling, certification submitted. PVT proves the line can build it at yield, cost, and scale — several hundred to a thousand units on the real CM line. MP1 is first volume production — a thousand and up, the program shifts from building the product to running it.

Each stage is a different kind of question, with a categorically different cost of failure. A program that loses sight of which question it is answering — or worse, treats every gate as “more units, more tests” — slips at PVT or in the field, where the bill is largest.

Five gates. Five questions. Five commitments — each harder to reverse than the last.

The common mistake: treating gates as test types

The default mental model: PoC is a “demo,” EVT is “first full test,” DVT is “more units more environments,” PVT is “dress rehearsal for the factory.” Build bigger, test more, stamp the gate, move on.

It is wrong in a specific way. It treats each gate as additive. Each gate answers a categorically different question. Unit counts go up, but that is incidental. What changes is what the program is willing to commit to. At PoC, you commit to nothing — you are buying information cheaply. At EVT, you commit to an architecture. At DVT, to a design. At PVT, to a factory and a yield. At MP1, to customers in the field.

A program that treats EVT as a demo leaves architectural questions for DVT to inherit. DVT pretends to answer them while running environmental tests, and certification begins on a design that is not actually frozen. PVT arrives and the CM finds the BOM has three placeholder parts and a footprint change nobody costed. First production: forty percent first-pass yield on a product that shipped on paper.

PoC — the feasibility gate

The question PoC answers: Can the core mechanism work at all?

PoC sits before the engineering program. It is the cheapest information-buying you can do. Bench experiments. Hand-wired breadboards. Off-the-shelf development kits — Arduino, Raspberry Pi, evaluation boards from semiconductor vendors. Mock-ups, simulations, paper analysis where a physical experiment is unnecessary.

Typical unit count: 1–3.

What must be decided at PoC:

• Whether the fundamental mechanism (the optical path, the actuator topology, the algorithm, the electrochemistry) actually works under the conditions the product will face.
• Whether the technical risks the program is taking are within the team’s competence — and within budget to retire.
• Whether to start the engineering program at all.

What to defer: Everything else. Industrial design, BOM, cost modeling, manufacturability — none of these belong at PoC. They will move when the architecture moves at EVT.

The common failure: confusing PoC with MVP. A PoC is “we proved the mechanism works.” An MVP is “we built the smallest unit a real customer can deploy.” A PoC dressed up as an MVP — a dev board in a 3D-printed enclosure shown to crowdfunding backers — produces signal about enthusiasm, not signal about commercial deployability. See Why Hardware MVPs Fail for the full deconstruction.

PoC passes when the technical risks the program is prepared to take are bounded. If you cannot articulate, in one sentence, what risk PoC retired and how, the gate did not close.

EVT — the architecture-validation gate

The question EVT answers: Does this architecture work in hardware?

Not “does the unit power on.” Does the system meet its thermal, power, timing, and performance targets when reduced to physical parts on a physical board in a physical enclosure? And if not, where does it break?

Typical unit count: 3–10 hand-built units.

Typical tooling: Quick-turn PCBs, machined or 3D-printed enclosures, soft silicone molds where geometry needs validation. Firmware functional but not hardened.

What must be decided at EVT:

• Processor, real-time split, and memory footprint survive under real load.
• Power architecture closes — every rail stable under worst-case draw.
• Thermal envelope is measured, not simulated. Validated against the real board in the real housing.
• Interfaces between subsystems work — bus topology, sensor-to-MCU path, display driver timing — under realistic load.
• Firmware hits its hard deadlines on hardware, not on a dev board.

What to defer: Cosmetic finish. Final BOM locking (a few placeholder parts are allowed, provided you know which ones). Packaging. Regulatory submissions.

The common failure: teams build three units, demo them, call it a pass. The engineer knows there’s a thermal margin problem at the voltage regulator, a display-driver timing edge case, and a connector that requires a wiggle. None of it is logged. All of it shows up at DVT — where the PCB is re-spun, the enclosure is injection-molded, and fixing the thermal margin costs a board stackup change.

EVT passes when every architecture-level assumption has measured data behind it. A demo is not validation.

DVT — the robustness-and-reliability gate

The question DVT answers: Is this design robust enough — across units, environments, and operators — to be handed to a manufacturer?

DVT is where the design stops being an engineering build and starts being a product.

Typical unit count: 20–200.

Typical tooling: Production-intent where economics allow — final-rev PCBs, injection-molded plastics from quick (aluminium) molds, real connectors and fasteners. Firmware hardened and frozen. Mechanical parts measured against drawings, not inspected by eye.

What must be decided at DVT:

• BOM is locked. Every line has a primary source, a priced quote at real volume, a lead time, and a second source where critical. Placeholder parts are done.
• Environmental performance is proven — temperature, humidity, vibration, drop, ESD, conducted and radiated emissions — across the envelope the product will see.
• Certification is submitted from DVT units. You do not certify a design that is still moving.
• DFM review is complete. The CM has signed off on the full package. Tolerance stacks are run against real parts, not datasheets. See DFM: The Decisions That Don’t Show Up on Drawings.
• Test strategy is proven. The end-of-line fixture works at line speed, and a technician can operate it.

What to defer: Line-yield tuning, final fixture integration at the CM, volume-commit supply moves.

The common failure: teams treat DVT as “bigger EVT.” Hand-builders, loose tolerances, firmware in active refactor. Environmental testing runs on units that are not representative. Certification gets submitted on a design that will change. The program then discovers at PVT that the line can’t hold the tolerances the lab units implied — because those tolerances were achieved by hand-selection, not process.

DVT passes when you can hand the full design package to a CM and get a production quote back without twenty open questions.

PVT — the line-readiness gate

The question PVT answers: Can the line actually build this — at scale, yield, and cost, with the CM’s operators?

PVT is the last gate before production. Not a rehearsal — a real production run where the program stress-tests the factory as much as the product.

Typical unit count: 200–1,000, built on the real line, by the real team, with the real fixtures.

Typical tooling: Final-revision production tooling — second-generation steel injection molds, final PCB stencils, full assembly-line fixtures, calibration and provisioning stations.

What must be decided at PVT:

• First-pass yield meets target. Mid-to-high nineties on a straightforward electromechanical product. Eighty-five percent and up on a complex system with optics, mechanics, and electronics. Below that, the transition was not done.
• Line is balanced. No station is the bottleneck beyond program tolerance.
• End-of-line test runs at line speed, catches the defects that occur, writes to a traceable record, and does not require the design engineer to interpret.
• Firmware provisioning, calibration, and serialization happen on the line without a laptop. A line technician, two hours of training, ships a unit.
• Final-revision tooling is cut. No tooling is “we’ll update it after PVT.” If tooling moves after PVT, the program is still in DVT.
• The CM commits to ramp. Capacity booked, MSA signed, escalation paths agreed.

What to defer: Nothing. PVT is the last stop.

The common failure: the window is compressed. PVT is treated as a rubber stamp on DVT, first production is booked before PVT data is in, test-fixture integration is skipped because “it worked at the vendor.” First fifty units have a ten percent failure rate on a test no one ran end-to-end. The line goes down for debug. Three weeks of CM time, lost. Trust never fully comes back.

PVT passes when the factory can build the product and the program can stop touching it. If the design team is still at the CM at PVT exit, PVT did not pass.

MP1 — the first volume run

The question MP1 answers: Can the program hold yield, cost, and reliability in the field?

MP1 is technically not a gate — it is the first real production. But the program is still a program at MP1, because the field starts surfacing things the lab and the line cannot.

Typical unit count: 1,000+, ramping into steady-state production over the following quarters.

What must hold at MP1:

• Yield does not regress as the line cools off. Operators, fixtures, and CM processes hold the spec week over week.
• Field telemetry comes online. Every unit reports calibration, firmware version, and operating health into a system of record.
• The support workflow runs without engineering. Field issues route through first-line support, escalate to engineering only when escalation is justified.
• The warranty reserve absorbs the actual failure rate. Per-unit accrual matches measured failures, not the launch guess.
• Firmware update path works on real production units. Signed, rollback-capable, exercised on a unit off the line — not the bench.

The common failure: the program declares victory at PVT, dissolves the engineering team, and discovers at MP1 that the support workflow does not exist, the warranty reserve was a placeholder, and the firmware update path was tested on EVT boards that no longer match the production stack. Six months of retrofitting under field pressure. See How to Launch a Hardware Product for the launch-readiness checklist.

The cost of compressing any one

Every gate has a cost of failure. The numbers are not linear. They are super-linear, and the curve gets steeper at every step.

An architecture issue caught at EVT costs a board spin and a week of firmware. The same issue at DVT costs a board spin, a firmware refactor, a re-run of environmental testing, a re-drafted certification submission, and a delayed DFM review — four to six weeks and a BOM reprice. At PVT, all of that plus tooling modification, re-quoted CM capacity, and whatever market window the program was defending. In the field: warranty reserve, support load, worst case a recall.

Every week saved at PoC or EVT tends to add three to six at DVT or PVT. Compressing PVT is the most expensive thing a hardware program can do — the factory is involved, and the factory does not absorb your schedule slip for free. The discipline is the opposite: make the gate painful enough that issues surface as early as possible, where the program can still afford them.

What “passing” should require — and what it usually does

Gate passage is where programs drift furthest from what the schedule claims. A PVT that passed on paper and a PVT that passed for real look identical in a status review and diverge completely at first production. The difference is in what “pass” was allowed to mean.

A strong pass: PoC — the technical risk is bounded with measured data, and the architecture sketch is good enough to start engineering. EVT — every architecture assumption has measured data, every unresolved issue has a decision attached (fix in DVT, accept with workaround, or redesign). DVT — CM signed off, certification submitted, BOM locked, test strategy proven on a full-count build. PVT — a real production run hit yield without design-team intervention, line balanced, CM committed to first production. MP1 — yield holds, the support workflow runs without engineering, warranty reserve matches measured failures.

A weak pass sounds like “most of it works, we’ll catch the rest in the next phase.” That phrasing is the signal. The gate did not pass. It deferred.

How a well-run gate looks in practice

At Rheo Dive, we took a smart dive mask — custom optics, custom PCBA, silicone over-molded tooling, an iOS app, and a full dive computer running under twenty meters of saltwater — through PoC, EVT, DVT, and into PVT without skipping a gate. The sequence was not faster because we hurried. It was faster because each gate closed cleanly.

PoC retired the optics question — could a curved underwater HUD render legible at the working distance, in the depth-light environment of a dive. Bench rig, no enclosure, no firmware beyond what was needed to drive the display.

EVT answered the architecture question: the custom optical path worked underwater, the low-SWaP PCBA hit its power budget, the micro-display pipeline held frame timing on the main MCU without a separate GPU. Measured data, not a demo. Architecture frozen, move on.

DVT answered the robustness question. Integrated prototypes in real dive conditions. Pressure cycling to forty meters, thermal cycling from four to thirty-two degrees Celsius, silicone skirt geometry iterated against actual face shapes. BOM locked with second sources on every critical part. Certification started on DVT units because those units would not change.

PVT is the gate currently executing — on-line build, final tooling, end-of-line test validated, CM operators running the fixture. Everything upstream is locked, so the PVT data is about the line, not the design.

The same sequence run badly — PoC dressed up as MVP, EVT as demo, DVT as bigger EVT, PVT as a rubber stamp — produces factory returns and six months of slip. The gates are not overhead. They are what makes a one-year program one year long instead of two and a half. See From Prototype to Production for the full decision framework, and The Hardware Product Development Process, Reframed for context.

Use this infographic

The diagram above is free to use, embed, and share — with attribution. Engineering teams, hardware founders, and content writers welcome.