From Prototype to Production: A Practical EVT/DVT/PVT Readiness Checklist

Boris Kaganovich — takefi — Tue, 28 Jul 2026 14:11:44 +0000

Most connected-device projects can produce a convincing prototype. The expensive question is whether they can produce 1,000 repeatable units, update them safely, test them quickly, and support them in the field.

The usual failure is not a single dramatic mistake. It is a chain of assumptions that survived because prototype success was mistaken for production readiness.

Before committing to tooling or the next build, I use eight evidence gates.

1. Product requirements and architecture

A requirement is useful only when two independent people can agree whether the product passed it.

Before EVT, verify that:

critical requirements are measurable and have acceptance criteria;
power, latency, acoustic, optical, thermal, lifetime, and reliability targets are quantified where relevant;
every hardware, firmware, cloud, mobile, AI, and manufacturing interface has an owner;
high-risk assumptions have been turned into experiments;
safety, privacy, security, radio, and market-specific regulatory requirements are visible.

A polished PRD is not evidence by itself. The evidence is traceability from a requirement to an architecture decision and eventually to a test result.

2. Electronics and component strategy

Prototype BOMs often contain parts that were convenient to buy, not parts suitable for volume production.

Check that:

schematics have passed an independent formal review;
PCB layout has been reviewed for power integrity, signal integrity, RF, EMC, thermal behavior, and manufacturability;
the power tree covers startup, peak load, battery limits, brownouts, and recovery;
supply-critical components have lifecycle, lead-time, and alternate strategies;
derating and tolerance analysis cover real operating limits.

An alternate component is not validated because it fits the footprint. It must work electrically, mechanically, thermally, and in firmware.

3. Firmware, connectivity, AI, and security

Field failures frequently live in paths that demos never exercise: interrupted updates, corrupted configuration, lost credentials, unstable networks, or recovery after power loss.

Verify:

boot, recovery, provisioning, factory reset, and failure paths;
authenticated, rollback-safe, interruption-safe OTA;
the lifecycle of keys, credentials, debug interfaces, logs, and personal data;
BLE, Wi-Fi, Matter, Zigbee, cellular, mmWave, audio, and camera behavior in realistic conditions;
AI, voice, and vision performance on representative field data, including failure cases and resource limits.

For an AI-enabled device, model accuracy is only one requirement. Memory, latency, thermals, power, observability, updateability, and graceful failure matter just as much.

4. Mechanical, thermal, and DFM/DFA readiness

A design can be manufacturable in CAD and still be painful on the actual line.

Before DVT, confirm that:

tolerance stacks include manufacturing variation, assembly loads, and aging;
thermal performance was measured at worst-case ambient and duty cycle;
the intended manufacturer reviewed the design;
assembly order, fastening, adhesives, cables, connectors, and service operations are documented;
cosmetic requirements have objective defect standards.

The manufacturer review matters because a prototype vendor optimizes for making a few units. A production partner must optimize for repeatability, yield, cycle time, and controlled change.

5. BOM, COGS, and supply chain

A unit price is not COGS.

A realistic model includes:

yield loss and rework;
production test time and fixtures;
packaging, logistics, duties, and warehousing;
tooling and non-recurring engineering;
warranty and field-service assumptions;
MOQ, payment terms, and capacity risk.

The production BOM should be revision-controlled and separate from the prototype BOM. Long-lead, sole-source, allocation-prone, and end-of-life parts should be visible before a purchase order forces the decision.

6. Verification and regulatory readiness

Test plans should cover more than nominal behavior.

Useful coverage includes:

boundary conditions;
misuse and fault injection;
recovery paths;
long-duration behavior;
environmental and shipping stress;
pre-compliance testing early enough to change the design.

Every result should identify the unit, hardware revision, firmware version, configuration, raw data, failure, and corrective action. Otherwise the team has observations, not traceable evidence.

7. Production test and quality system

Production test is part of product architecture, not a factory detail.

Ask:

Which critical defects can occur at each assembly step?
Where will each defect be detected?
What are the test limits, cycle time, calibration method, and golden-unit policy?
How are false passes and false failures measured?
Can serial number, hardware revision, firmware, calibration, test results, and rework history be traced?

A test fixture that arrives after the build starts is already late.

8. EVT, DVT, PVT, and launch governance

Each build needs explicit objectives, entry criteria, sample size, configurations, and exit criteria.

Every issue needs:

severity and containment;
an owner;
root cause;
corrective action;
verification that the correction worked.

Engineering changes must update the BOM, documentation, firmware, test system, and supplier revision together. Ramp decisions should use yield and evidence, not schedule pressure alone.

A simple scoring method

Mark every checkpoint:

Green: complete, reviewed, and supported by evidence.
Amber: partially complete, with an owner and dated closure plan.
Red: missing, untested, or based only on an assumption.

Do not average away a critical red item. A single red in safety, regulatory compliance, power integrity, security, component availability, or production testing can block a build.

I published the complete 40-point checklist and a reusable CSV assessment template as an open-source resource:

Hardware Production Readiness Checklist on GitHub

If you are preparing an AI hardware or connected-device product for EVT, DVT, PVT, or manufacturing, I would be interested to hear which gate creates the most surprises for your team.

I co-founded takefi, an end-to-end R&D partner for AI hardware and connected devices. We work across electronics, embedded firmware, backend and OTA, voice and computer vision, industrial design, DFM/DFA, BOM/COGS optimization, testing, supplier qualification, and manufacturing support.

DEV Community: Boris Kaganovich — takefi