Your Machine Prototype Works. What Should You Check Before Building 10 Units?
Prepare a working machine prototype for a 10-unit pilot with configuration control, sourcing, assembly instructions, test records, calibration, and field support.
Key Insights At A Glance
A working prototype demonstrates a function; the pilot must also examine repeatable build and test.
Freeze a documented build baseline and record deviations rather than silently mixing revisions.
Use the intended assembly process to expose missing information, fit problems, and rework.
Track each unit through parts, configuration, programming, test, and any corrective action.
A ten-unit batch provides learning; it does not automatically establish long-term reliability or compliance.
The prototype works. Now you want ten machines for trials, customers, or the next stage of the business. It is tempting to order ten sets of parts and call that a pilot. Before you do, check whether the first unit works because the design is repeatable or because the person who built it knows exactly which bracket needs persuading.
The first small batch should answer questions about manufacturing as well as function. Can the parts be sourced consistently? Can someone follow the instructions? Can each machine be configured and tested without improvisation? This guide focuses on those questions. It complements the prototype-to-production overview and NPI planning, but stays close to the practical decision to build your next ten units.
1. Define what the ten-unit batch is intended to prove
Write the purpose before ordering. A customer demonstration batch, an engineering validation build, a controlled field trial, and a production-process trial can require different configurations and evidence. If the main purpose is learning about assembly, use the intended process and record its limitations. If the main purpose is field behavior, define the installation conditions, support plan, and observations required.
Choose success criteria that match that purpose. You might need to demonstrate consistent assembly without hand-fitting, complete functional test coverage, or a documented service task. Do not assume that ten successful demonstrations establish every reliability claim. The batch is a sample under particular conditions. Its value comes from what you observe and resolve, not from attaching a production-ready label to the shipping box.
Use EVT, DVT, and PVT definitions to distinguish the questions, but agree on the actual exit evidence for your product. The letters alone do not define the build.
2. Freeze a build baseline that somebody else can identify
Create a release list covering mechanical drawings, BOM, PCB revision, firmware, display assets, configuration, harnesses, labels, and test procedure. Identify compatible revisions and any approved alternatives. The goal is not to prevent learning. It is to know what you built so observations can be connected to a configuration rather than to a description such as "the newer one with the different cable."
Record deviations deliberately. If the pilot uses printed parts while production will use molded parts, identify what that build can and cannot demonstrate. If a component substitute is used, record its approval and the tests affected. An undocumented exception may be harmless today and become very expensive when someone assumes it was the released design.
Unit identifier:
Build baseline and drawing revisions:
PCB and harness revisions:
Firmware and display release:
Configuration and calibration record:
Approved substitutions or deviations:
Assembly date and responsible operator:
Inspection and functional test results:
Rework and retest record:
Release decision and intended destination:3. Check sourcing and prepare controlled kits
Confirm parts for the planned quantity and the likely replacements needed during assembly. Review long-lead components, minimum purchase quantities, custom fabrication, and items selected opportunistically for the prototype. A component available once from an unknown source does not establish a repeatable supply route. Keep traceability proportionate to the product and purchasing requirements, and identify who approves substitutions.
Prepare a BOM that separates fitted parts, consumables, optional items, and tooling. Check part descriptions and manufacturer references where needed. A line saying "small connector" may have worked when one engineer did the shopping. It becomes less helpful when ten kits arrive with three visually similar connector families. Kit completeness should be checked before assembly, not discovered one missing fastener at a time.
For custom boards, review the PCB production workflow. For budgeting, custom PCB cost planning explains why a small batch still carries setup and test costs that are not visible in the bare-board price.
4. Test the assembly instructions with a fresh pair of hands
Ask a capable assembler who did not build the prototype to follow the draft instructions. Observe the work without immediately filling every gap verbally. Record unclear orientation, difficult access, excessive force, alignment adjustments, and missing tools. You are evaluating the information and design, not testing whether the assembler can read the original designer's mind.
Measure the operations you want to improve. Separate normal assembly from rework and troubleshooting. If a hole must be enlarged or a bracket bent by hand, record the reason and decide whether the drawing or process needs correction. A quick workaround can keep the pilot moving, but it should not silently become an instruction to keep making an avoidable defect.
Pilot assembly observations worth recording
| Observation | What to investigate | Possible controlled response |
|---|---|---|
| Repeated alignment adjustment | Tolerance chain, datums, or fixture access | Design review and revised locating method |
| Wrong orientation | Ambiguous features or instructions | Keying, clearer work instruction, or inspection |
| Damaged wiring | Routing, edges, strain relief, or assembly sequence | Harness and packaging correction |
| Variable completion time | Searching, tool changes, waiting, or rework | Process clarification and measured retest |
| Designer intervention | Undocumented knowledge or unresolved design dependency | Update the release package before the next build |
Design for assembly provides methods for improving handling and fastening. Tolerance stack-up analysis helps when the fit changes between units. Use the pilot evidence to decide which method is relevant rather than adding fixtures to compensate for a problem you have not understood.
5. Make programming, configuration, and calibration repeatable
Define the approved software image, tool version, programming steps, configuration values, and verification method. Separate unit-specific data from the common firmware release. Identify how machine identity is assigned and how a replacement board receives the correct settings. If secrets or service credentials are involved, handle them through an appropriate access process rather than copying a developer's private file into every unit.
Where calibration is required, specify the reference, procedure, recorded result, and acceptance limit. Distinguish calibration from a convenient adjustment made until the machine appears to work. Record what happens when the result is outside limits. A process that permits unlimited adjustment without preserving the values can hide manufacturing variation instead of explaining it.
Give recovery the same attention. A spare should be programmable and checkable using the delivered records. If only the original laptop contains the required tool settings, resolve that before the pilot is released. The hardware handover guide describes how to test this capability explicitly.
6. Build a test procedure that can fail a bad unit
A useful end-of-build test is repeatable and discriminating. It identifies the configuration, setup, action, expected result, measured result, and pass limit. Cover the functions and faults relevant to the pilot purpose. A sequence that always prints PASS because the software finished running is not a quality gate, however reassuring the green letters may look.
Separate inspection, basic electrical checks, firmware verification, subsystem function, and complete-machine behavior where that makes the procedure clearer. Define how test equipment is checked and which failures require investigation rather than immediate retest. Preserve failed results and rework records so a unit that passes after correction is not indistinguishable from one that passed first time.
- Link checks to requirements and known manufacturing failure modes.
- Record the board, firmware, configuration, and unit identifier.
- Define pass limits and required observations before the test.
- Retain initial failures, corrective actions, and retest results.
- Check the test arrangement with known expected outcomes.
- Identify limitations that require later validation or external assessment.
7. Read the pilot results without exaggerating the evidence
Track parts issues, assembly observations, time, first-pass test results, rework, and configuration differences. Analyze patterns rather than treating every failure as a separate anecdote. If three units need the same connector repair, investigate the connector, harness, drawing, and assembly sequence. Repeating the repair faster is not necessarily an improvement to the process.
Use small-sample results carefully. If nine of ten units pass the initial test, the observed first-pass result for that defined test is nine out of ten. It is not a prediction that every future production batch will behave the same way, and it says little about untested long-term conditions. Report the denominator, test, configuration, and limitations so the number supports a decision rather than a marketing claim.
Keep learning separate from release
8. Prepare installation, service, and feedback before shipment
Document the intended location, utilities, operating instructions, service contacts, spare assemblies, and fault-reporting process. For a customer trial, agree on what is being evaluated and which limitations apply. Arrange how observations return to the engineering team. Ten machines in ten locations can create ten different stories unless the feedback identifies configuration, operating conditions, and the event sequence.
If the machines are connected, define what remote monitoring records and who acts on the information. If they are not connected, provide a practical way to capture fault and service records. The point is not to collect everything. It is to preserve the evidence needed to distinguish an installation problem from an assembly or design problem.
9. Hold a release review before calling the batch complete
Review the build records, unresolved issues, corrective actions, updated documents, test evidence, and support arrangements. Decide whether to release, rework, restrict use, or build again. Assign owners and dates to the remaining work. Feed every approved correction into the baseline so the next batch starts from the improved design rather than rediscovering the same workaround.
SolveMpire can discuss pilot readiness across mechanical design, custom electronics, firmware, and manufacturing support through our engineering services. Bring the existing prototype, drawings, BOM, software, known issues, target quantity, and intended use of the pilot. A useful review should tell you what the ten-unit build needs to learn before more units make the lesson harder to ignore.
For repeatable electronics checks, production test fixtures for custom PCBs connects fault coverage to access, programming, measurements, limits, traceability, fixture validation, and invalid-test handling.
For incoming mechanical samples, first article inspection planning joins the approved release to sample identity, characteristic mapping, methods, actual results, deviations, and acceptance scope.
Preparing your first small machine batch?
Share the prototype state, available release files, intended build quantity, known adjustments, and pilot purpose. We can discuss the assembly, test, and documentation work needed before the build.