From prototype to production run: hardware design handoffs

By Marco Lopes · September 17, 2024 · Hardware & Gear

A prototype proves that an idea can work. A production handoff must explain how someone else can build it repeatedly, inspect it consistently, and recognize when something has gone wrong. Those are different achievements.

At Kordspace, we approach hardware as part of a connected system: electronics, mechanical parts, firmware, interfaces, and the software that supports them. As a remote collaborative studio, we also treat documentation as working infrastructure, not paperwork added after the interesting work is finished.

The transition becomes easier when we stop thinking of the handoff as a folder of files. We need a controlled agreement about what gets built, how it gets verified, and who can authorize changes. Here is how we structure that agreement.

Define what “ready for production” means

Before exporting drawings, we establish the intended production stage. An engineering build, a design-validation build, and a production-validation run answer different questions. We can use EVT, DVT, and PVT terminology if everyone understands it, but the labels matter less than the exit criteria.

For an engineering build, we might still be checking power behavior or radio performance. For design validation, we should be evaluating the intended design against functional, environmental, and usability requirements. Production validation should demonstrate that the proposed manufacturing process can produce acceptable units.

We write those expectations down. What must work? Under which conditions? Which defects block shipment? Which open issues are acceptable for this specific build?

We also identify the release owner, manufacturing contact, and decision-maker for exceptions. If a supplier finds an unavailable connector, we should already know who evaluates the alternative. Otherwise, schedule pressure becomes an informal change-control process.

Package a release, not a workspace

Our internal workspace can contain experiments, abandoned layouts, and half-finished alternatives. The manufacturing release cannot.

We create a clearly identified release package with a revision, date, manifest, and approval record. Each file should belong to that release, and the manifest should make missing or outdated deliverables obvious. We avoid filenames such as final-final-approved.zip; a stable product identifier and revision are more useful.

For electronics, the package normally includes schematics, fabrication outputs, drill files, board stack-up requirements, placement data, assembly drawings, and the bill of materials. We confirm the manufacturer’s preferred formats rather than assuming every shop accepts the same exports.

For mechanical parts, we include the agreed CAD exchange files and controlled drawings defining critical dimensions, tolerances, materials, finishes, and inspection requirements. A 3D model alone rarely communicates every manufacturing constraint.

We retain editable source files in our controlled repository. Whether we share them with a supplier depends on the contract and workflow, but we never leave ownership, access, or the right to modify them ambiguous.

Make the BOM an instruction, not a shopping list

A useful bill of materials tells procurement and assembly exactly what is allowed. We include manufacturer names, manufacturer part numbers, quantities, reference designators, and assembly variants. Distributor links can help purchasing, but they are not substitutes for part identity.

We explicitly mark do-not-populate positions and explain variant-specific differences. If one enclosure supports two board versions, we make that relationship visible rather than expecting the factory to infer it.

Approved alternatives need engineering review. A component with a matching headline specification can still differ in package dimensions, thermal behavior, startup characteristics, or firmware compatibility. We define whether substitutions are prohibited, pre-approved, or subject to written authorization.

We also review availability, lifecycle status, minimum order quantities, and realistic lead times before committing to a build. Where a single-source component is unavoidable, we record the risk and the response: securing inventory, qualifying an alternative, or accepting a redesign dependency.

Mechanical fasteners, adhesives, labels, cables, and packaging belong in the product definition too. Missing small items can stop assembly just as effectively as a missing processor.

Resolve manufacturing questions before the purchase order

We ask the manufacturing partner for design-for-manufacture and design-for-assembly feedback while changes are still manageable. That review should cover both fabrication limits and the practical sequence of putting the product together.

On a circuit board, we examine component spacing, panelization, tooling access, fiducials, soldering constraints, and test-point access. For an enclosure, we review the chosen process: an injection-molded part needs different decisions from a machined or printed one.

We pay particular attention to interfaces. Does the connector align with the opening across the tolerance stack? Can we install the battery without stressing its leads? Can we reach the final screw after the cable is routed?

We avoid applying tight tolerances everywhere. We identify dimensions that control fit or function and agree on achievable inspection methods. Unnecessary precision can add cost without improving the product.

Every supplier question and proposed adjustment goes into a tracked issue. We close it with a decision and, where necessary, a revised release, not a detached email that never reaches the assembly team.

Design the test process alongside the product

A prototype often works because its creator knows where to probe, when to reset it, and which warning can be ignored. Production testing cannot depend on that knowledge.

We turn requirements into explicit tests with defined inputs, procedures, limits, and recorded results. “Check that it powers on” is too vague. We specify the supply conditions, expected startup behavior, measurement points, and what constitutes a failure.

We separate board-level tests from final-assembly tests. A board can pass electrically and still fail after installation because of antenna placement, cable routing, thermal constraints, or a damaged connector.

We also define fixture requirements early. Programming contacts, accessible test points, and locating features are much easier to add before the design is frozen. Fixture software, wiring diagrams, and calibration instructions become controlled deliverables themselves.

A known-good reference unit can help validate a setup, but it does not replace measurable acceptance criteria. We document retest rules, failure handling, and authorized rework so that repeated attempts do not quietly turn a faulty unit into an apparent pass.

Treat firmware and provisioning as manufacturing steps

Hardware releases need an explicit relationship to firmware releases. We identify the bootloader, application image, configuration, flashing procedure, and compatibility requirements for each board revision. We record build identifiers and checksums so the factory can verify that it has the intended files.

For connected products, provisioning deserves a separate plan. We distinguish ordinary configuration from secrets and decide where device identities, credentials, and certificates are generated. We avoid placing production secrets in shared release folders or embedding one reusable credential across every unit.

We define the intended production state of debug interfaces and readout protection. Any locking step needs sequencing and verification: we should not permanently restrict access before programming and required tests are complete.

We also plan recovery. If flashing fails halfway through, what happens next? If a unit returns from the field, how can we identify its hardware and firmware safely?

Serial numbers, hardware revisions, firmware versions, and test outcomes should be linked. That traceability helps us investigate a problem without assuming every unit from a shipment is identical.

Coordinate the handoff across a remote team

Remote collaboration works best when decisions remain visible after the meeting ends. We maintain one authoritative release location, one issue tracker, and a clear approval path. Chat is useful for discussion; it should not be the only record of a manufacturing instruction.

We prefer Google Cloud when a project needs cloud-hosted provisioning services or test-result storage, while also working with AWS or Azure where the existing environment calls for them. The platform matters less than access control, auditability, and a workable factory integration.

Factory stations may have unreliable connectivity or restricted networks. We decide which operations can run offline, how records are queued, and how duplicate uploads are handled. We do not make essential quality checks depend on an unexamined internet connection.

A handoff review should include engineering, procurement, manufacturing, and quality representatives. We walk through the package together, assign unresolved questions, and request written acknowledgment of the exact revision accepted for the build.

Use the pilot build to challenge our assumptions

We treat the pilot as a rehearsal of the intended production process, not just another batch of prototypes. Wherever practical, we use the planned tooling, assembly instructions, operators, test fixtures, and packaging.

We watch for ambiguity as well as defects. A technician repeatedly asking which way a cable should face is evidence that the instructions need work. An assembly that requires unusual force may reveal a tolerance or sequencing problem, even if the finished unit passes testing.

We record failures and investigate their causes before increasing volume. We distinguish design defects, supplier issues, process errors, and test-system problems; they require different corrective actions.

We also review applicable market and product requirements with qualified specialists. Electrical safety, electromagnetic compatibility, radio approvals, battery transport, labeling, and material restrictions may affect the release. A prototype demonstration is not evidence of compliance.

After corrective changes, we decide what needs revalidation and issue a new controlled revision. We do not let a successful pilot excuse undocumented fixes.

Keep a short release checklist

Before authorizing the run, we confirm:

• The release revision, manifest, and approvals are complete.
• Fabrication, assembly, and mechanical files agree.
• The BOM defines variants and permitted substitutions.
• Manufacturing questions have documented resolutions.
• Test fixtures, procedures, and acceptance limits are ready.
• Firmware, provisioning, and recovery steps are verified.
• Compliance obligations and shipment blockers are understood.
• Traceability, rework, and change ownership are defined.

Any unchecked item needs an owner and a decision, not an assumption that the factory will handle it.

Make the next build easier, too

The handoff does not end when the purchase order is placed. We keep an engineering change process active through production, linking each change to affected files, validation evidence, inventory disposition, and the serial-number or lot boundary where it takes effect. That record supports repairs, repeat orders, and future redesigns.

Our goal is simple: we want the product’s build knowledge to live in a usable system, not in one person’s memory. If we can help move a prototype toward a controlled production run, start a project with Kordspace. To explore how we connect hardware, software, and design, read our related services pages.