Custom IoT firmware development: from prototype board to a product you can ship and update

Almost any connected product starts the same way: a development board on a desk, a sensor wired up, and example firmware that blinks, reads, and sends data within an afternoon. The gap between a prototype that works once and a device that works for thousands of customers, in bad weather and on flaky networks, for years, is almost entirely firmware — and it is where off-the-shelf code usually runs out of road.

Custom IoT firmware development is not about writing code from scratch for its own sake. It is about owning the behaviour that matters: how the device wakes, what it measures, how it fails, how it recovers, and how it improves after shipping. Left to a generic example project, those decisions get made by accident — and you discover them in the field, one support ticket at a time.

Start from the product, not the board

The most expensive firmware mistake is choosing hardware before defining behaviour. A board chosen for its demo videos may lack the sleep current, flash space for two firmware images, or secure storage for device keys — none easily retrofitted once the enclosure is designed.

Before writing application code, pin down the design drivers: report frequency and size, battery life, behaviour on power loss mid-write, offline operation, and the cost of a failed update — a truck roll, a bricked device, or just a retry? The same discipline applies to any build-versus-buy call: count the whole lifecycle cost, not just the cost of getting started. A cheap prototype that cannot be updated or diagnosed is not cheap at all.

Design for the field, not the bench

On a bench, power is clean, Wi-Fi is strong, and the developer is watching. In the field, none of that holds. Good firmware assumes the worst and degrades gracefully: it retries with backoff instead of hammering a dead network, it queues readings instead of dropping them, and it never writes a half-finished record as if it were truth. This is the same problem as turning raw sensor samples into events you can actually trust — the sensor is rarely the hard part; deciding what counts as a real reading, and what to do with a doubtful one, is.

Three design choices pay for themselves many times over. First, separate measurement logic from transport logic, so a change of connectivity — Wi-Fi to cellular — does not mean rewriting the sensing code. Second, log locally with timestamps, even if the device is normally silent; the log turns “it stopped working” into a diagnosable fault. Third, make every state transition explicit and recoverable, so a device power-cycled at any moment comes back in a known state.

Give every device an identity it cannot fake

A fleet is a collection of identities that happen to run the same code. If two devices can present the same credentials, you cannot revoke one without revoking both. That is why provisioning and fleet identity deserve attention before the first production unit ships: each device needs a unique key, stored in hardware-backed storage where supported, issued at manufacturing time and never shared in source code or a spreadsheet.

Per-device credentials also shape your cloud side: you can revoke one compromised unit, throttle a misbehaving one, and trace bad readings back to a firmware version and a manufacturing run. Without that, every fleet problem looks like a product problem.

Ship updates like the product depends on it — because it does

No firmware ships perfect. Sensors drift, protocols change, and security issues emerge. Without field updates, each becomes a recall, a replacement, or a permanent limitation. Over-the-air updates done properly — signed images, a fallback partition, and a rollback when the new image fails its own health checks — are not a nice extra. They are the mechanism that lets a product improve instead of ageing in place.

The update design belongs in the first firmware release, not the second: dual-bank flash, a bootloader that verifies signatures before booting, and a versioning scheme the cloud can reason about are far harder to add after deployment. Test the failure modes deliberately — kill power mid-download, corrupt an image, roll back to the old version. An update path never tested under failure is the one that will fail in front of a customer.

Where the intelligence should run

Simple thresholding and filtering usually belong on the device: they cut bandwidth, work offline, and respond instantly. Heavy analysis, fleet-wide comparison, and model inference usually belong elsewhere — and where an AI model should run, cloud, edge, or device, is a trade-off between latency, cost, power, and how often the model itself will change. The firmware team's job is to make that boundary clean: the device should send trustworthy, well-labelled events, and the cloud should not need to know which sensor produced them.

A practical build sequence

A shipping firmware project tends to follow the same sequence:

1. Prove the behaviour on a dev board — sensing, actuation, and connectivity, with real power measurements.
2. Freeze the hardware requirements — sleep current, flash layout, secure storage, and debug interfaces.
3. Build the production firmware skeleton — bootloader, update path, identity provisioning, and logging — before application features.
4. Test in hostile conditions — brownouts, weak signal, and full flash.
5. Ship a small pilot fleet and watch it for a full duty cycle, with remote logs and a tested rollback.

Skipping step three is the most common shortcut, and the most expensive: application features are easy to add later, but a missing bootloader or a shared device key is a structural defect that follows the product for its whole life.

The go-live checklist

Before the first production run, check these:

• Every device has a unique, hardware-stored identity, revocable alone if compromised.
• Firmware updates are signed, verified, and reversible, with a tested rollback.
• Power loss at any point leaves a known, recoverable state — verified by test.
• Remote logs let a field fault be traced to a device, firmware version, and time.
• Sensor data is validated at the edge, so the cloud receives events, not raw noise.
• The team can reproduce a customer's firmware version, configuration, and calibration in the lab.

Any unchecked item means the launch is really a pilot with production branding. That is sometimes the right call, but it should be deliberate, with the risks written down and an owner for each.

What custom firmware actually buys you

Done well, custom firmware buys three things an off-the-shelf stack rarely delivers together: behaviour matched to the product, a fleet you can diagnose and update, and a platform the next product can reuse. The first device is the expensive one; the second, reusing the same bootloader, identity, and update pipeline, is where the investment pays back.

Judge a firmware engagement not by how fast the prototype blinks, but by whether the ten-thousandth device is as maintainable as the first. If you are scoping a connected product, our IoT and hardware team builds firmware, provisioning, and update pipelines together — and for the surrounding application, custom software built around the same workflow. Talk to us before the hardware is frozen, when these decisions are still cheap to get right.