A working IoT prototype is a milestone and a trap. The board on the bench reads a sensor, sends a value to a dashboard, and everyone in the room can see the product. What they cannot see is the distance between that board and ten thousand units in the field — units that have to be manufactured identically, survive shipping, connect to networks you do not control, be updated remotely, and keep working for years without anyone touching them. This is a field guide to crossing that distance: the design decisions, the testing, the manufacturing relationship and the launch plan that turn a prototype into a product.
Design for production before the prototype is finished
The prototype's job is to prove the idea. The production design's job is to be built ten thousand times, cheaply and consistently, by people who have never heard of your company. The two rarely share more than a schematic, and the earlier the production constraints enter the design, the less has to be thrown away.
Component selection is the first decision that matters. A development board with a chip that is easy to prototype on may be expensive, hard to source in volume or nearing end of life. Choose parts with a long lifecycle, multiple suppliers and a distributor stock history you can check. Design the enclosure alongside the board, not after it, because antenna placement, thermal behaviour and connector positions all depend on both. And think about certification early: radio modules that are pre-certified save months compared with certifying a custom radio design.
- Pick components for availability, lifecycle and cost at volume, not just for convenience on the bench
- Design for manufacture and assembly — fewer parts, one-sided placement where possible, test points on the board
- Plan the enclosure, antenna and thermals together
- Prefer pre-certified radio modules unless volume justifies a custom design
- Decide early what the device must do when the network is down
Firmware that can be fixed after it ships
Prototype firmware proves that the sensor reads and the radio transmits. Production firmware has to handle everything else: power management for battery life, watchdogs that recover from hangs, storage that survives power loss, and — above all — a secure over-the-air update mechanism. A device you cannot update is a device whose first serious bug is permanent, and whose first security flaw is an open door.
Provisioning is the other piece the prototype skips. Every unit needs a unique identity — a certificate or key generated or injected at manufacture — so the cloud can tell one device from another and reject a counterfeit. Build the provisioning step into the production process, not into a manual procedure someone runs on each unit after the fact.
Test the way the world will
Bench testing confirms the design works under ideal conditions. Production testing confirms it works under the conditions it will actually meet, and the difference is where most field failures come from.
- Environmental testing. Temperature extremes, humidity, vibration, drop. The device will be shipped in an unheated truck and installed by someone in a hurry.
- Network testing. Weak signal, intermittent connectivity, captive portals, IPv6-only networks, corporate firewalls, cellular roaming. The office Wi-Fi is the friendliest network the device will ever see.
- Power testing. Brownouts, unplugging mid-write, battery at the end of its life. Every one of these should leave the device recoverable.
- Long-duration soak testing. A hundred units running for weeks reveals memory leaks, clock drift and storage wear that a day on the bench never will.
- Security testing. Debug ports left open, credentials in firmware, unsigned updates accepted, cleartext traffic. Assume a device will end up in the hands of someone curious.
- Usability testing with real installers. The onboarding flow — powering on, joining a network, pairing with an app — is where customers give up. Watch people do it without help.
Certification and compliance
Any product with a radio needs regulatory approval in each market it ships to — FCC in the United States, CE and the Radio Equipment Directive in Europe, and equivalents elsewhere — plus safety and electromagnetic compatibility testing. Using a pre-certified module reduces the scope but does not remove it; the final product is still tested. Budget several weeks and a five-figure sum for a first product, and start the process as soon as the design is frozen, because a failed test means a board revision and a second visit to the lab.
Data regulations apply too. A device that collects personal data — location, health readings, audio — brings privacy law into scope, and the choices about what is stored, where and for how long have to be made in the design, not in the privacy policy.
Choosing and working with a manufacturer
The contract manufacturer relationship decides whether the tenth thousand unit is as good as the first. Evaluate candidates on their experience with similar products, their test and quality processes, their willingness to build small pilot batches, and how they communicate when something goes wrong. Visit the factory if you can. Ask to see their incoming inspection, their yield data and how they handle a defective batch.
Start with a pilot run — fifty to a few hundred units — before committing to volume. The pilot exposes assembly problems, test fixture gaps and documentation errors while they are cheap to fix. Provide the manufacturer with a complete package: board files, bill of materials with approved alternates, assembly drawings, a test procedure with pass criteria, firmware and provisioning tooling. Anything left ambiguous will be resolved on the line, and not always the way you would have chosen.
- Run a pilot batch and fix everything it reveals before volume
- Give the factory an automated end-of-line test that flashes firmware, provisions identity and verifies every function
- Agree on quality metrics and inspection sampling in writing
- Track yield and failure causes from the first batch and act on them
Unit economics decide whether it ships at all
A prototype costs whatever it costs. A product has to be sold for more than it costs to build, ship, connect and support — and the connection and support costs are the ones founders forget. Cellular data, cloud ingestion, storage and the share of a support engineer's time per device are recurring costs that a one-off hardware price has to cover, or a subscription has to fund. Model the full cost per unit over its expected life before the design is frozen, because the cheapest way to fix a bad margin is to change the design, and that option disappears at volume.
Supply chain and logistics
Component shortages, lead times of months for some parts, and shipping that can double in cost with little notice are normal conditions, not exceptions. Qualify alternates for every critical component before you need them. Order long-lead parts early. Design the packaging for the shipping method and the retail or installation context, and test it — a drop test on the boxed product is cheap insurance. Decide how returns and repairs will work, and who bears the cost, before the first unit leaves.
Launch is where the product starts
The final stage is not the end of engineering but the beginning of operations. Before launch, the cloud side needs to be ready for the real fleet: monitoring for device health and connectivity, alerts for anomalies, a support tool that lets a person see what a specific device has been doing, and a tested, staged update pipeline so a firmware release can go to one percent of devices before it goes to all of them.
Plan the support load. The first weeks after launch generate the most onboarding questions, and the answers feed back into firmware, the app and the documentation. Treat the field data as the most valuable test results you will ever get, and have a release cadence that lets you act on them quickly.
Frequently asked questions
How long does it take to go from prototype to production?
For a moderately complex connected device, nine to eighteen months is typical, with certification, tooling and the pilot build on the critical path. Products using pre-certified modules and off-the-shelf enclosures can be faster; anything with custom radio design or medical or automotive compliance takes longer.
What is the most common mistake?
Treating the prototype as a near-final design and skipping the redesign for manufacture, testing and updatability. The result is a product that is expensive to build, fails in the field in ways the bench never showed, and cannot be fixed remotely.
Do we need our own hardware team?
Not necessarily. Many successful products are built by a small core team working with specialist partners for electronics design, firmware, cloud and manufacturing. What you do need is one person or partner who owns the whole system and keeps the pieces coherent.
Inverge Tech builds IoT products end to end — firmware, cloud pipeline, dashboards and the production tooling in between — and we have carried products through pilot builds to volume. If you have a prototype that works and a plan that stops there, we can help you build the rest of the road.