The difference between a product you can fix and one you cannot

A software bug in a product that is already in customers' hands is two completely different events depending on one design decision. In a product that can update itself, you publish a new build and the problem disappears from the field within days. In a product that cannot, you have two options: live with the defect, or recall units for service at a cost that often exceeds the profit on them.

Over-the-air (OTA) firmware update capability is not a software feature you can add later — it is a hardware requirement you have to commit to at the start of design. Since no product ships bug-free, the ability to update is insurance; in connected products it is now simply expected.

What you get beyond bug fixes

  • Post-sale improvement. A product that gets better over time earns loyalty and justifies a higher price.
  • Earlier launch. You can ship with core functionality and add the rest, which is exactly the strategy behind a minimum viable hardware product.
  • Security patching. A practical necessity, and increasingly a market-access expectation for connected devices.
  • Customization for a large customer without a hardware variant.
  • Field diagnostics. The same channel that pushes builds can pull back the telemetry that tells you what is failing.

What the hardware has to provide

These are the decisions that are painful or impossible to retrofit:

  • Enough non-volatile memory for two images. The A/B pattern — write the new build to the inactive slot, verify it, then switch — is the standard. It roughly doubles your flash requirement, and that requirement drives part selection. See how to choose a microcontroller, and put flash size and vendor update support explicitly in the selection criteria.
  • A communication path. Direct to the network over Wi-Fi or cellular, or indirectly through a phone app over Bluetooth. The phone route is slower and depends on the user opening the app — plan for that in your rollout math. Budget the phone-side work accordingly.
  • A protected bootloader. A small, immutable piece of code that is never overwritten by an update and always knows how to recover.
  • Adequate power. An update interrupted by a dead battery must be either impossible (require mains or a charge threshold) or fully reversible.
  • Hardware root of trust. Somewhere to store a public key or use a secure element so signature verification cannot be bypassed.

The rule you never compromise: rollback

The mechanism must guarantee that a failed update never leaves a dead product. The standard approach:

  1. Download the new image into the inactive slot.
  2. Verify integrity and signature before doing anything else.
  3. Mark the new slot as “trial” and reboot into it.
  4. The new firmware must actively confirm it is healthy — connected, sensors responding, watchdog fed — within a time window.
  5. If it does not confirm, the bootloader reverts to the previous image automatically on the next reset.

Without this, one bad build pushed to thousands of units is an unrecoverable event. There is no way to reach the devices to fix them, because the thing you would use to reach them is the thing that broke.

Securing the update channel

An update channel is also an attack channel: whoever can load code onto a device owns it completely. Minimum requirements:

  • Cryptographic signing. The device verifies a signature against a key provisioned in manufacturing, before execution — not after.
  • Encrypted transport for the download, with server certificate validation on the device side.
  • Anti-rollback protection. Refuse to install an older version that contains a known, patched vulnerability. Note the tension with your recovery path: automatic reversion to the immediately previous image is fine; accepting an arbitrary old image from the network is not.
  • Key management as a real process. Where the signing key lives, who can use it, and what happens if it is compromised. Provisioning the public key is a manufacturing step, which ties this to your production line controls and factory access policy.

Staged rollout

Never release a build to the entire fleet at once. The accepted practice is to push to a small cohort, wait, watch for any increase in error rates or drop in check-in success, and only then widen. This requires at least minimal reporting from the device so you know an update actually succeeded — a version report and a health beacon are the bare minimum. The cloud infrastructure that manages cohorts, targeting, and reporting is a core capability of the major platforms; see AWS IoT vs Azure IoT for how the major platforms compare on fleet management.

Managing multiple versions in the field

The moment devices update at different rates, you have several firmware versions live simultaneously. The phone app and the cloud API must support all of them, which makes backward compatibility a contract you have to maintain deliberately: version the device-to-cloud message schema, document which app versions support which firmware versions, and treat every interface change as a change-control event rather than a commit. If your firmware architecture is still being defined, what is firmware gives the vocabulary, and FreeRTOS vs Zephyr matters here because the RTOS you choose partly determines how much update machinery you get for free.

Designing the update experience

The technical half is only half. The rest is what the user experiences, and three decisions determine how much of your fleet actually updates:

  • Automatic or user-approved. Silent automatic updates give the highest coverage but can interrupt someone mid-use. Requiring approval respects the user and leaves a permanent tail of devices that never update.
  • When. A product that can detect it is idle and on external power avoids most failure modes by itself.
  • What the user sees. Clear progress indication and an honest time estimate stop people from unplugging halfway. A device that looks frozen invites exactly the intervention you least want.

Two regulatory notes

If your product contains a certified radio, changes to the software that controls the transmitter can affect the validity of your authorization, and some changes require a permissive change filing. Confirm the boundaries before you ship a radio-touching update — background in FCC certification for electronic products. And if the software has a medical function, updates fall inside a controlled design process rather than a normal release cycle; see software as a medical device.

Budget it as scope, not as an extra

A robust update system — bootloader, A/B logic, signing chain, server side, cohort management, reporting — is a meaningful chunk of the firmware effort, and it is one of the biggest single line items founders forget. It belongs in the estimate from the beginning; see firmware development cost for how that scope is usually sized.

Build it in from the start

Projects House designs connected products where the update path, the bootloader, the security model, and the cloud side are specified together — before the microcontroller is chosen. If you are planning a product that will need remote updates, or you have one in the field that cannot be patched, tell us about it through our contact form. Related reading is in our embedded software section.