IoT Prototype to Shippable Product

A prototype only has to work once, on a bench, with someone nearby to notice if it doesn't. A product has to work continuously, in the field, unattended, for years. That gap is where most of product development engineering actually happens.

This article walks through the four biggest differences between an IoT prototype and a shippable product, then closes with a practical checklist you can use on your own work before calling something "product-ready." It is written from the perspective of someone who has shipped industrial IoT units to remote sites where the cost of a failed field visit is real, not hypothetical.

What changes between prototype and product

The same circuit, the same firmware, the same cloud platform — yet the device behaves completely differently the moment it leaves the bench. Four dimensions change most, in roughly this order of how often they bite teams:

Power

A prototype on a bench supply doesn't reveal battery-life problems. A field unit running on batteries or solar does, immediately. The worst version of this is the device that works for three days on a full charge in the lab, but drains in 14 hours when the radio is actually retransmitting through a noisy radio link — exactly the conditions the field unit will see.

Three power-related things to measure before calling the prototype "done":

• Average current draw with the radio active, not idle. Idle current is what almost every datasheet gives you; active current is what kills battery life.
• Worst-case peak current, especially during a cellular or radio transmit burst. If your power supply or battery cannot source this peak, the MCU brown-outs and you get an apparent firmware bug that is actually a power-rail bug.
• Brown-out recovery behavior. If the supply dips below the brown-out threshold, does the device reboot cleanly, log the event, and resume? Or does it wedge in a state that requires a physical power cycle?

Environment

Humidity, temperature swings, vibration, and dust don't show up in a lab enclosure. A device that ran for six months on a desk can fail in three days on the side of an oil palm plantation because condensation shorted a connector. IP rating is necessary but not sufficient — the enclosure has to be assembled correctly in the field, which means fasteners, gaskets, and cable glands that survive being opened and closed by technicians who aren't the original engineer.

Failure recovery

A prototype can be power-cycled by hand. A product needs to recover from a brownout, a corrupted firmware update, or a lost connection without anyone touching it. The simplest version of this is a watchdog timer that actually works; the harder version is an OTA update path with a known-good fallback image, so a bad firmware push doesn't brick a deployed fleet.

Manufacturability

A hand-wired prototype board doesn't need to be produced at volume; a product does. If every unit requires two hours of hand soldering, your cost structure doesn't work at 500 units, and your quality story doesn't work at 5,000. Design for the assembly process from the beginning — even if the first 20 units are hand-built.

A practical checklist before calling something "product-ready"

1. Does it recover automatically from a power loss mid-operation?
2. Does it buffer and retry data instead of silently dropping it when connectivity drops?
3. Has it been tested in conditions that match the actual deployment environment, not just a lab bench?
4. Can firmware be updated remotely, and can a bad update be rolled back?
5. Is the bill of materials sourced from parts that won't be discontinued next quarter?

If any of these is "no" or "I haven't tested it," the product is not ready to ship. Pretending otherwise is how field deployments become support nightmares.

A short worked example

A team I worked with built a GPS tracker for forestry assets. The bench prototype reported every 10 seconds for 6 hours on USB power. The first field version, on a 18650 cell, lasted 11 hours. The actual deployment environment — heavy tree canopy, weak GPS lock, frequent radio retries — dropped that to 4 hours.

The fix was not "buy a bigger battery." It was three things at once: a higher-gain antenna (better GPS lock under canopy, fewer retries), adaptive reporting cadence (10 seconds when moving, 5 minutes when stationary), and an actual sleep current budget enforced at the schematic-review stage, not discovered at integration.

None of those changes were exotic engineering. They were the discipline of asking "what does this look like in the field" before declaring the prototype done.

Why research-minded engineers do this well

Coming from a research and development background helps here, because the instinct to ask "what happens at the edge case" and "how do we know this is actually working, not just appearing to work" transfers directly. Product development isn't just implementation — it's the same rigor applied to a narrower, field-tested question: will this specific unit still be reporting correctly in six months, unattended, in the environment it was actually built for.

The reverse is also true: engineers who only ship demos tend to underweight environmental and recovery questions, because those questions never come up in a demo. The bridge between the two is process — checklists, real field tests, and the willingness to delay a launch when the answer to one of the questions above is still "I think so."

References

1. Texas Instruments, Low-Power Design for IoT Battery Applications (Application Note SLVAE43), 2023.
2. Espressif Systems, ESP32 Series Power Consumption and Wake-up Behavior (Technical Reference), 2024.
3. AWS IoT, Device Lifecycle and OTA Best Practices, 2024.
4. O'Reilly, Building Embedded Systems — Changyi Gu, 2016 (chapters on hardware/software co-design).

---

Last reviewed: 2026-09-16.