Prototype to Pilot Production

A pilot is not mass production either. It is allowed to find problems. It is not allowed to hide them in rework that never reaches the files. Entry criteria, what you record, and an exit disposition are the whole discipline. Figures below are hypothetical teaching maths, not BrahmWorks prices, yields, timelines or test results. The wider path from a one-off build to a repeatable product is set out in How to Take a Hardware Prototype to Production.

The bill of materials is the one you will buy, or every substitute is marked as a substitute with a reason. Drawings exist for the features that function. An assembly order exists that someone other than the designer can follow. A test has limits, not the phrase "check that it works". Firmware or configuration, if the product has any, has a version identity stored with the unit.

You do not need a perfect yield to enter, and entry is not "no open issues". You need known issues written down, so a pilot defect is distinct from an old one. Unwritten cheats will be rediscovered and called findings. That wastes the build.

The place matters as much as the files. A pilot on the engineer's bench, with the engineer fetching parts from a drawer, tests the engineer. A pilot at the builder who will run the next order, with their fixtures or an honest lack of fixtures, tests the process. If you cannot be at that builder yet, simulate the constraint: no verbal help, parts presented as a kit, time recorded. Label the simulation so nobody calls it a factory result.

It is for learning the distribution, not for admiring a hero unit. Time each station. Count defects by station, not as a single gloomy percentage. Note every question the assembler asks. A question is a missing sentence or a bad design, and it is cheaper than a scrap part. Note every part that does not match the bill: a resistor reel, a housing colour, a screw length. Those mismatches are the supply system telling you it is not the one you specified.

It is also for finding which checks catch defects and which checks only add time. A twelve-point visual list that nobody fails is not a quality system. A torque check that finds a cracked boss is a candidate to keep, and a candidate to design out. The pilot's job is to leave you with a shorter list that still catches the failures you saw, plus the failures you refuse to discover in the field.

Do not staff every station with the people who designed the product and then treat a clean run as evidence. Engineers repair without noticing. They recognise a half-seated connector by sound. A second shift will not. If engineers must stand on the line because the documentation is not ready, the pilot's finding is that the documentation is not ready. Ship that finding to the files before you ship units.

Every defect class leaves with one of three words: change the design, change the process instruction, or accept with a written limit. "Watch it next time" is not a disposition. A design change needs a revision. An instruction change needs to be in the pack the next assembler will see, not in a chat message. An accepted limit needs a number and a person.

Units from the pilot are not automatically saleable. They are saleable only if they match the revision you are willing to support, including firmware, and if any known defect is one you would tell a customer about. Mixing pilot revisions in the field, under one product name, makes the next failure impossible to diagnose. Mark them.

The teaching product is a desktop instrument. It is not a BrahmWorks product. The team books a twenty-five unit pilot because a customer asked for "production units". The housings are moulded in the intended resin. The board is the intended stack-up. The assembler is a technician who did not design it, which is already better than the prototype phase.

Three findings, invented for the lesson. The front overlay can be rotated and still stuck down, and two units leave that way. The test procedure says "calibrate" and does not say which fixture file, so the technician uses the one on a shared laptop. One connector batch is a stated alternate that nobody added to the bill. None of these require a new industrial design. All of them would have been invisible on a prototype the designer assembled while talking.

Teaching exit, not a factory report: the overlay gains a corner chamfer so the wrong rotation wrinkles, the calibration file gets a version in the procedure, and the alternate connector is either added to the bill or removed from the line. The twenty-five units already built are labelled with the old overlay orientation check. They are not quietly mixed with the next lot.

Hypothetical probability, to show a limit of the sample. Not a measured defect rate and not a BrahmWorks result.

Assume a defect that affects 1 unit in 100, independently, and that this rate is an assumption. The chance a single pilot unit misses it is 0.99. The chance all 25 miss it is 0.99 raised to 25.

0.99² = 0.9801. A useful approximation for small x is (1 − x)^n ≈ 1 − n x, so 1 − 25 × 0.01 = 0.75. The miss chance is about 0.78 if you compute it more tightly (0.99^25 is near 0.778). So the chance of seeing at least one such defect in 25 units is only about 22%.

A clean pilot therefore does not show that rare defects are absent. It shows that common ones, the kind that happen several times in 25, had a fair chance to appear. Design the pilot to catch the frequent process and instruction faults. Do not describe it as a statistical proof of field reliability. If a dangerous fault at 1 in 100 would be unacceptable, 25 units are the wrong tool for that question. You need a design control that makes the fault implausible, not a small sample that happened to miss it.

• The bill of materials is the buying list, with substitutes labelled.
• Someone who did not design the product can assemble and test from the pack.
• Known cheats are written before the first unit, so they are not "findings".
• Defects are counted by station and by type.
• Every assembler question becomes a document change or a design change.
• Engineers on the line are recorded as a crutch, not as a pass.
• Each defect class has a disposition: design, instruction, or accepted limit.
• Pilot units that do not match the released revision are marked and not mixed.
• A clean run is not described as a field-failure rate.
• The next order uses the revised pack, not the memory of the pilot.

Enough to exercise the real process and to see repeated mistakes, and not so many that you cannot afford to scrap the lot when the findings arrive. Twenty-five can be enough to expose instruction and assembly faults. It is a poor detector of a 1-in-100 defect, as the arithmetic shows. Choose the count from what you need to learn and from the cost of being wrong, not from a template.

Only when they are the revision you will support, and when known defects are disclosed or removed. Selling them to "get feedback" while also counting them as production confuses both the customer and the next failure analysis. If you sell them, serialise them and keep the build record. A unit with no revision history is not a pilot unit. It is a loose prototype.

Yes, if the change is versioned and the units that received it are identifiable. A binary copied from a laptop onto "most of them" is not a change. It is a split in the population. Freeze a version for the lot, record exceptions, and do not claim the lot validated a version it did not all run. Hardware findings and firmware findings need separate dispositions. One does not close the other.

The defects that engineers fix by habit: a connector pushed twice, a cable dressed around a boss, a calibration click they know to ignore. The line looks capable. The next operator, without those habits, builds a different product under the same revision. If the pilot cannot run without the designer within arm's reach, the exit criterion is not met, however many units passed.

Bring the build record, the questions the assembler asked, and the revision you intend to repeat. BrahmWorks can help separate a pilot finding from a prototype habit that the run happened to repeat.

Review the next stage with BrahmWorks