From ESP32 Prototype to Production: 7 Steps to Launch an IoT Product

Getting an ESP32 or Arduino to read a sensor and send data to the cloud takes a weekend. Getting a thousand devices to run reliably in customers' hands for years is a different job.

That gap between a working prototype and a real product is where most hardware ideas stall. Here are the seven steps we follow to close it.

Why prototypes break in the real world

• Wi-Fi drops and comes back, and the device never reconnects.
• A power cut corrupts the stored settings.
• The device sits somewhere hot, dusty or damp.
• Users enter the wrong Wi-Fi password and there is no easy way to fix it.
• A bug is found after shipping, and there is no way to update the firmware.

The 7 steps

1. Lock down the requirements

Write down what the device must measure or control and how often it sends data. Decide the power source (battery or mains), the connectivity (Wi-Fi, Bluetooth Low Energy or cellular), where it will be installed and your target cost per unit. These answers drive every later decision.

2. Choose production hardware

Move from development boards to a module on a custom PCB. ESP32 modules are a strong choice when you need Wi-Fi and Bluetooth in one chip. A Raspberry Pi works well as a gateway when you need more processing near the devices. Check component availability early, because one part with a long lead time can delay the whole launch.

3. Write production-grade firmware

Firmware written in C or C++ should expect things to go wrong. Use watchdog timers to recover from freezes, reconnect automatically when the network drops, store readings locally when offline and send them later, and use low-power modes if the device runs on battery.

4. Connect securely to the cloud

Use MQTT over TLS for device-to-cloud messaging. Give every device its own certificate instead of a shared password. AWS IoT Core, for example, authenticates devices with X.509 certificates. Then set up rules that route incoming data to storage, alerts and your dashboard.

5. Plan over-the-air (OTA) updates from day one

You will need to fix bugs and add features after devices ship. Build in signed firmware updates, automatic rollback if an update fails and staged rollouts, so a bad update reaches 10 devices, not 10,000.

6. Build the app and dashboard

Decide what your customers need to see on their phone and what your team needs to manage the fleet. That usually means device status, alerts and history for customers, and health, firmware versions and remote actions for your team.

7. Test end to end, then certify

Test the device, cloud and app together, not as separate parts. Run devices for days to catch slow memory leaks, and simulate network loss, power cuts and bad user input. Before launch, check which certifications your market needs, such as WPC (ETA) approval for wireless devices sold in India, or CE and FCC marking if you plan to export.

Plan for life after launch

Shipping the first batch is not the finish line. Connected products need ongoing care, so plan these before launch:

• Fleet monitoring: know which devices are online, which firmware version each one runs and which ones report errors.
• A firmware release process: test every update on a small group of devices before rolling it out to everyone.
• Support tools: give your support team a way to see a customer's device status without asking them to read out settings.
• Spare parts and supply: keep enough stock of key components to repair or replace faulty units.
• Data and privacy: decide how long you keep device data and who can see it.

Teams that plan this early spend less time firefighting and more time improving the product.

Real example: Product Design Labs

We helped Product Design Labs take a connected product from proof of concept to a working implementation, with Arduino on the device side and AWS for hosting. In their words: "Their experience with Arduino and hosting in AWS helped us to build an end to end solution."

Common mistakes to avoid

• No OTA update path, so every bug fix needs a site visit.
• Wi-Fi credentials hard-coded into the firmware.
• Ignoring power consumption until the battery dies in two days.
• Testing the device, cloud and app separately and never together.
• Choosing parts with long lead times or a single supplier.
• Treating device security as something to "add later". Our security testing checklist covers the app and API side.

How INNOVISCENT can help

Our embedded and IoT team takes connected products from proof of concept to production: firmware for ESP32, Arduino and Raspberry Pi, secure connectivity over MQTT, AWS cloud hosting, and the apps and dashboards on top. Because we started as a QA automation company, we test the whole system end to end.

Frequently Asked Questions