IoT device development: from working prototype to a fleet you can support

The prototype works. Now what?

The prototype sits on a bench next to a dev kit, joins the office Wi-Fi, streams readings to a dashboard, and an engineer re-flashes it whenever something changes. The next question sounds simple: what does it take to put several thousand of these in customers’ homes, vehicles or plants, and keep them working for years?

Most of the answer is work the demo never had to do. A shipped device must be set up by a stranger, survive days without a network, accept new firmware without a technician, prove its identity to your cloud from the first boot, and stay supportable after the original team has moved on.

The unknowns to settle first, and the assumption to test in each

Estimates go wrong when the brief describes features and the cost sits in conditions. “The device sends temperature to the app” can be a short task or a long programme depending on the answers below. For each condition, the right-hand column names the assumption that hurts most if it is wrong, and how to test it early.

How hardware, firmware, connectivity, cloud and app depend on each other

It is tempting to split a connected product into a hardware contract, a firmware contract, a cloud team and an app agency. Each can meet its own specification while the product still fails, because system performance is set where the layers meet.

Example: a heart-monitoring sensor where four layers had to be specified together

Monitoring Life was developing Sensocor: a sensor unit that records heart signals, a patient app and a portal for doctors. The company already had the sensor hardware with Arduino-based firmware and an Android app reading the sensor’s Bluetooth Serial stream. It had no cloud backend, no doctor portal and no build pipeline.

• Problem. Recordings had to reach the doctor’s portal intact. Sampling rate, Bluetooth throughput, the app and the backend all decided whether the data path congested.
• Constraint. Assembled units could not be re-flashed without opening the enclosure, and the unit runs on a battery.
• Choice. Indeema moved the firmware to ESP-IDF, replaced Bluetooth Serial with Bluetooth Low Energy and protected pairing, added firmware delivery through the app, reworked the Android app, and built the Azure backend and the doctor portal. It also proposed schematic and PCB changes for USB programming on the bench. Measurements start and stop from the app, so the unit records only when needed.
• Trade-off. Firmware and app had to change together instead of patching the old serial data path.
• Verified result. The four layers work as one data path, and sensor firmware is updated through the app instead of by opening the enclosure. The published case reports no throughput, latency or battery figures, and the PCB change is described as a proposal.
• Lesson for you. Write one specification for the data path, not one per layer, and decide how a sealed device will be updated before the enclosure is final.

Worked numbers: how much Bluetooth LE can carry

Vendor-documented reference and illustrative calculation. These are not Sensocor measurements; that case publishes no throughput figures.

What it changes. Compare your data rate (sampling rate × channels × bytes per sample) with these ceilings, not with the radio’s raw bit rate. If it lands near them, plan buffering, compression or a different link. If it is a small fraction, the risk moves to the phone side: negotiated connection parameters, background limits and how fast the app reads.

The decisions that move budget, schedule, battery and unit cost

There is no universally best protocol, microcontroller or cloud, only choices that fit a set of conditions. The trade-offs later in this article summarise the main ones. Two decisions most often fix the architecture early: the system-on-chip and the connectivity path.

Example: one SoC for several control channels in a ventilation unit

Prana makes decentralised ventilation units with heat recuperation. For its next generation, Prana Platinum, the electronics, firmware, sensor architecture and user experience were redesigned, on top of Prana’s existing ThingsBoard cloud.

• Problem. The unit had to accept control from the mobile app over Wi-Fi or Bluetooth LE, an IR remote, Matter smart-home platforms and its physical controls.
• Constraint. One controller had to cover those channels with enough I/O and a stable supply chain, without a connectivity co-processor. Motor switching noise could disturb sensor readings.
• Choice. Indeema evaluated seven SoC families against I/O, connectivity, supply-chain and ecosystem criteria and chose the ESP32-C6. Motors get dedicated supplies, separate from isolated rails for the MCU and sensors, with per-channel current sensing that also feeds diagnostics. Operating modes run as an explicit state machine, and schedules fall back to an on-board real-time clock when the network drops.
• Trade-off. One chip simplifies the board and concentrates the product on one vendor’s silicon, SDK and supply.
• Verified result. A defined architecture on ESP32-C6 with isolated power, FreeRTOS firmware with self-diagnostics, the four control channels above and ThingsBoard extensions, developed on prototype hardware with Prana. The case lists Thread and Zigbee among the chip’s radios, not as delivered features.
• Lesson for you. Choose the SoC against every channel you need and the supply chain, not against the first prototype. Design for the moment the network disappears: a schedule that depends on cloud time stops when the router does.

Connectivity options by condition

The right link depends on where the device lives, how it is powered and who pays for data. This comparison describes typical fits, not rankings.

A proof of concept is not a production-ready product

A proof of concept answers one question: can the core function work? It is valuable because it ignores most of the product. The risk starts when a successful demo is treated as most of the way to launch.

Hardware teams often call the later stages EVT, DVT and PVT: engineering validation (does the design work?), design validation (does it pass environmental, reliability and pre-compliance tests?) and production validation (can the factory build it repeatably?). The names matter less than the rule: each stage has written exit criteria, and firmware, cloud and app readiness are part of them.

Example: what a proof of concept proved, and what it left open

A maker of in-building communication systems wanted an indoor monitor that shows analog video from an installed door camera on a smartphone, and had proposed the ESP32-P4 without testing it for this video path. Indeema wrote the requirements and specification, assembled a feasibility prototype from manufacturer-recommended parts, and wrote firmware that digitises PAL video, encodes it with the SoC’s hardware video encoder and streams it over Wi-Fi. Espressif’s RTSP component was not built for full multimedia use and its source was not available, so the team wrote its own.

• Proved: the ESP32-P4 can carry this video path end to end to a computer on the network, with colour calibrated to the analog source.
• Left open: the smartphone client, productisation, and published latency or image-quality figures. The prototype streamed to a PC precisely so those could be evaluated before app work.
• Lesson for you: a good proof of concept is narrow and states what it did not cover. Ask for its exit criteria in writing and treat the next stage as a separate decision.

Where products fail after the demo: onboarding

Four areas rarely appear in a demo and almost always appear in support tickets: onboarding, connectivity loss, firmware updates and provisioning. Onboarding is the first real use of the product, done by someone who has not read the manual, and it touches every layer: app permissions and pairing, the device’s provisioning mode, network credentials or a hub, account linking, and recovery when a step fails.

For UBreez, users had to connect a device and set their own acceptable ranges without technical help; a beta with a small user group led to written user guidelines. In a hub-based smart-home system, Indeema’s part of a multi-team app was the BLE connectivity API and the in-app flow that onboards devices and connects them to the cloud.

Designing for connectivity loss

A device that loses its connection must decide what to keep, what to drop and what to do locally. That is a product decision with an engineering cost, not an edge case.

Example: telemetry that survives coverage gaps on an electric bike

An e-bike maker already had two hardware revisions of its vehicle control and telemetry unit and a backend; the unit’s embedded software was basic. Indeema’s scope was the embedded application on those boards, described in the e-bike telemetry case.

• Problem. The unit had to keep working when its cellular module could not reach the network, without losing telemetry.
• Constraint. Queued telemetry competes for limited on-device storage, and an update interrupted by connection loss must not leave the unit unusable.
• Choice. Modem handling, telemetry reporting and updates run as separate real-time tasks on ThreadX. Telemetry is queued on the device within its storage limit, and the update flow was designed so an interrupted download leaves the unit able to recover. QA verified each milestone build against acceptance criteria agreed at the start.
• Trade-off. Any on-device queue forces a policy for a full buffer. That policy decides which data the business can lose, so the product owner has to agree it.
• Verified result. A real-time application that connects over cellular, reports to the existing backend, keeps telemetry through coverage gaps, accepts updates over the air and is configured from a PC over USB. The case does not publish buffer sizes, outage durations or recovery-test counts.
• Lesson for you. Specify offline behaviour as requirements: how long, how much data, what is dropped first, and what the user sees.

Worked numbers: sizing the offline buffer

Illustrative calculation. The inputs are assumptions chosen for the example, not data from the e-bike project, whose case publishes no buffer figures.

What it changes. The result decides whether the queue fits in spare internal flash or needs an external flash chip, which changes the bill of materials, and how long the device can be offline before the drop policy starts. Halving the logging interval or doubling the outage doubles the storage.

Firmware updates you can recover from

Delivering a firmware image is not the same as a recoverable update architecture. Delivery gets the image onto the device. Recovery decides what happens when power or the link fails at any point, and it shapes the hardware, because it usually needs flash for a second image.

Our published cases describe different parts of this. In Sensocor the app delivers images to the sensor over Bluetooth LE. Cube Air firmware downloads updates over HTTPS. The e-bike unit’s update flow was designed to recover from an interrupted download. In the hub-based smart-home system Indeema built CI/CD with automated tests and versioning for ESP-IDF firmware, and AWS sandbox, development, pre-production and production environments with OTA update jobs. None of these pages documents secure boot, image signing or A/B rollback, so treat those as items to specify, not as precedents.

Worked numbers: the flash budget for recoverable updates

Illustrative calculation on vendor-documented rules. The image size is an assumption; the partition rules come from Espressif’s ESP-IDF documentation. Other platforms differ in detail but follow the same logic.

What it changes. With a factory slot, the application space alone exceeds a 4 MB flash part, before NVS, logs or an offline queue. Either drop the factory slot and rely on two OTA slots with rollback, or choose a larger flash part, and decide it before the board layout is frozen.

Identity, provisioning and the fleet

Every unit needs its own identity and credentials to talk to your cloud. On a prototype an engineer creates them by hand; on a production line it must be automatic, auditable and fast enough for the line.

Example: provisioning manufactured air-quality monitors

Cube Air is an indoor air monitor for a property developer building premium hotels and condominiums, which was entering device production for the first time with purifier drawings and no in-house hardware team.

• Problem. Each manufactured unit needed its own cloud identity and certificates before it reached a resident.
• Constraint. The first-generation unit had to fit inside the client’s purifier; the second became a standalone desktop device in the client’s dimensions with an added CO2 sensor.
• Choice. Indeema built a serverless AWS back end on AWS IoT Core with production scripts that create a database entry per device, obtain its certificates and flash them to non-volatile storage. Firmware publishes data over MQTT with TLS, receives configuration over MQTT, downloads updates over HTTPS and calculates the air-quality index on the device, so the LED and the cloud show the same value.
• Trade-off. Serverless services remove servers to run and tie operating cost and limits to the provider’s pricing and quotas.
• Verified result. Two device generations prepared as prototypes for beta testing, connected end to end with the back end and a Flutter app, with provisioning scripts for manufactured devices. The case makes no claim about production volumes.
• Lesson for you. Treat provisioning as a manufacturing deliverable: who runs the script, where keys are generated and stored, and how a failed unit is handled on the line.

When you depend on someone else’s hardware or firmware

Many products contain a part the product owner does not control: an OEM battery management system, a camera API from another company, a module with closed firmware. SuperVolt batteries use an OEM battery management system whose firmware is not Indeema’s work; Indeema rebuilt the companion app. The BMS documentation was incomplete, so the team reverse-engineered its behaviour, worked through it with the OEM and reported discrepancies, and isolated support for older batteries in its own modules.

Lesson for you. Budget interface discovery for every third-party component, name who resolves disagreements between documentation and behaviour, and isolate support for older hardware so it does not block new features.

Compliance: what applies, and who does what

Regulation now shapes a connected device’s update and security design, not only its radio. Check scope for your product: the points below are common cases, not a rule for every device.

• EU radio cybersecurity until the Cyber Resilience Act takes over. Since 1 August 2025, Delegated Regulation (EU) 2022/30 has applied the Radio Equipment Directive’s cybersecurity requirements to internet-connected radio equipment and some other categories; the EN 18031 series are the harmonised standards. Regulation (EU) 2026/339 repeals it with effect from the day the Cyber Resilience Act applies in full, and equipment placed on the market before then stays under market surveillance against those requirements.
• EU Cyber Resilience Act. Manufacturers’ obligations to report actively exploited vulnerabilities and severe incidents apply from 11 September 2026. Most other requirements, including security by design, vulnerability handling, security updates and conformity assessment, apply from 11 December 2027 to products with digital elements in its scope.
• UK and US. The UK’s product security regime for consumer connectable products has applied since 29 April 2024. In the US, a device that transmits needs FCC equipment authorisation before it is marketed; the FCC Cyber Trust Mark is a voluntary label.

Conformity assessment is the manufacturer’s job

In the EU the manufacturer carries out the conformity assessment, draws up the EU declaration of conformity and affixes the CE marking. CE marking is the manufacturer’s declaration, not a certificate issued by someone else. A notified body takes part only where the procedure requires it: under the Radio Equipment Directive, for example, when harmonised standards are not applied in full, which matters because EN 18031 is cited with restrictions; under the Cyber Resilience Act, for some higher-risk product classes. Test laboratories produce reports. An engineering partner designs to the requirements and prepares test builds and technical documentation. A pre-certified radio module reduces radio testing, but the finished product still needs its own assessment.

Turning requirements into acceptance criteria

Vague requirements produce estimates nobody can hold to. Write each critical behaviour as a test with conditions and a pass rule. The example below is illustrative: the bracketed values are placeholders to replace with your own, not results from our projects.

What to prepare before asking for an estimate

A useful estimate needs constraints more than features. Copy the template, answer what you can and keep “unknown” where you do not know yet: unknowns tell a partner where discovery is needed.

CONNECTED PRODUCT BRIEF
(Answer what you can. "Unknown" is a useful answer.)

PRODUCT AND USERS
- What the device does:
- Who installs it:
- Who uses it day to day:

ENVIRONMENT AND POWER
- Indoor or outdoor, temperature range:
- Mounting and mobility:
- Connectivity available on site:
- Mains, rechargeable or primary battery:
- Required time between charges or battery changes:

VOLUMES AND COST
- Pilot quantity:
- First production volume:
- Target unit cost at that volume:

MARKETS
- Countries or regions of sale:
- Approvals or test reports you already hold:

WHAT ALREADY EXISTS (owner, documentation)
- Hardware and enclosure:
- Firmware:
- Cloud or backend:
- Apps:
- Third-party modules or APIs:

OFFLINE BEHAVIOUR AND UPDATES
- What must keep working without the network:
- Longest outage to survive:
- Data that may be dropped first:
- Field updates required, and who may trigger them:

DATA AND INTEGRATIONS
- What is sent, and how often:
- Retention and access:
- Systems to integrate (ecosystems, ERP, SCADA, other devices):

MANUFACTURING AND SUPPORT
- Contract manufacturer (chosen or not, who):
- Who owns provisioning and end-of-line testing:
- Support period after sale:
- What your team, the partner and other suppliers each own:

RISKS AND ACCEPTANCE
- The assumptions that would hurt most if wrong:
- How you will decide the product is ready (tests, pilot, sign-off):
- Dates that drive the timeline (pilots, trade shows, funding, regulation):

Still at the idea stage? Start with starting an IoT project. Comparing vendors? Use how to choose an IoT development partner. The disciplines behind this article are described on our embedded firmware, IoT hardware development and post-production support pages.

Hidden work that rarely appears in the first estimate

These items are real work in most connected products. Decide which apply to yours instead of discovering them late; for how they turn into a budget, see how much an IoT solution costs.