A prototype and a pilot build answer different questions
A functional prototype helps test the core connection, interaction and wearing experience. A pilot batch puts more attention on repeatability: component versions, assembly order, software loading and outgoing checks.
These do not need to become isolated stages. Prototype feedback should inform design changes, and a pilot build can also reveal issues that lead back to mechanical, electronic or software design.
Agree on the version used for this batch
Before a pilot build, confirm which hardware, mechanical and software versions are being used and which changes have been checked. Keep an explicit list of unresolved questions rather than letting different people work from their own idea of the latest version.
Batch size and timing depend on the project. The purpose is to answer concrete questions, rather than simply make a larger number of prototypes.
Turn inspection into steps someone can follow
“Check that it works” is too broad. Break it into observable actions such as power-on, button operation, display, connection, charging and other agreed checks. The conditions and results should be traceable to the device being checked.
If a judgement relies entirely on individual experience, ask whether the design, test conditions or device feedback can make that judgement clearer. These details affect consistency in later deliveries.
Bring field feedback into the next build
Record the context, manner of use and software version alongside a reported problem. This helps distinguish an unusual action, a poor fit for the use case and a design issue that needs to change.
After reviewing the batch, agree on the changes for the next one, the checks still needed and the delivery plan. Flexible production works best when product decisions can develop without losing track of versions and inspection.
