From Prototype to Production: Scaling IoT Hardware Beyond 100 Units

The day the demo works on the desk is the easy day. The hard work is the next eighteen months — and the teams that survive them are the ones that planned for the gap, not the ones who assumed the prototype “just needs to be made cheaper.”

The prototype is not the product

A bench prototype optimizes for “does it work once, in this environment, for this engineer.” A production product optimizes for “does it work every time, in every customer’s environment, for ten years, without anyone touching it.”

Those are different artifacts. The transition has four pillars.

Design for manufacture (DFM)

The board layout that worked on a hand-soldered PCB is not the board layout your contract manufacturer wants. Test points, fiducials, panelization tabs, component orientation, and clearance for pick-and-place machinery all matter. Get a DFM review from your CM before the layout is finalized — they will return three pages of changes, every one of which saves you a respin.

Component selection matters more than performance optimization. Lifecycle status, single-source risk, MOQ, and lead time decide whether you can build 10,000 units next quarter. A part that is “perfect” but has a 26-week lead time is a worse choice than a part that is 90% as good but available from three distributors.

Design for test (DFT)

Every unit coming off the line gets tested. The fixtures, scripts, and pass-fail criteria for that test are infrastructure you build, not afterthoughts.

Plan for:

• A factory test fixture that connects to test points on the board and runs a known sequence (power rails in spec, peripherals respond, radio transmits at expected power, sensors return sane values).
• A factory provisioning step that writes per-device credentials, certificates, and serial number into secure storage.
• Test result logging to a system that can spot drift across batches before it becomes a customer-quality issue.

A unit that passes factory test and fails in the customer’s hands is a unit that left a gap in the test plan. Each one teaches you something to add.

Compliance is a long pole

Regulatory certification — FCC, CE, IC, BLE-SIG, Wi-Fi Alliance, RoHS, REACH, country-specific approvals — takes longer than every other engineering activity. Plan for at least three months from “design frozen” to “certificates in hand,” and budget the certification fees as a real line item.

Two principles that save time:

• Pre-scan early. Run a pre-compliance EMC scan as soon as you have functional hardware. Finding an EMI problem after design freeze is expensive. Finding it before is a one-week fix.
• Reuse certified modules where possible. A pre-certified Wi-Fi/BLE module costs more per unit than a discrete chip but saves months on FCC. The math usually works out for the first five thousand units; revisit when volume justifies bringing certification in-house.

Operations after the first build

The first 100 units teach you what your support burden will look like. Treat them as instrumentation:

• Capture device telemetry from day one of customer deployment. Battery, signal strength, error rates, reboot counts.
• Run a structured failure analysis on every returned unit. Most return to the lab with a vague “doesn’t work.” Tear them down, measure, write up a finding. Patterns emerge by unit 10.
• Build fleet dashboards that show you the cohort effects you cannot see from individual support tickets. “Devices manufactured in week 12 have 3x the BLE disconnect rate” is the kind of thing you only see on a dashboard.

The hidden cost: people

Scaling to a thousand units without scaling your people means burning out the founders. The roles that emerge by unit 100 and are essential by unit 1000:

• Operations engineer to own factory test, provisioning, and CM relationship.
• Field engineering to triage support tickets that escalate beyond the first-line team.
• Quality lead to own RMA analysis and feed findings back into the next revision.

You can outsource any of these. You cannot leave them empty.

What we do at this stage

Most teams do not need an internal hardware ops team — they need an experienced one for nine months while their internal team learns. We embed engineers who have shipped this transition before, walk the project from prototype to first thousand units, and hand it back documented.

If your prototype works and the next nine months feel intimidating, we have run this play more than once.