A hardware startup founder came to me four months before their consumer IoT device was supposed to ship to Kickstarter backers. The device was a smart home sensor - temperature, humidity, air quality. The firmware worked. The cloud backend worked. The mobile app worked.
What did not work was the update mechanism.
The firmware was version 1.0. When the engineering team fixed a bug or added a feature, they had no way to push that update to devices already in the field. The plan was that customers could download firmware updates from the website and flash them manually using a USB cable.
I told the founder this was not a plan. It was a path to hundreds of one-star reviews, a warranty nightmare, and a product that would degrade in quality relative to competitors who could update their devices remotely.
We spent the next eight weeks building an OTA (over-the-air) update system. It was not glamorous work. It was critical work. The devices shipped with version 1.1. Three months later, version 1.3 was running on 94% of the fleet without a single manual update from a customer.
The OTA system is invisible when it works. It is existential when it is missing.
The Hardware-Software Integration Problem
Hardware-software companies have a unique challenge that pure software companies do not: two separate release cycles that need to work together.
Software updates can ship in minutes. A bug fix to a cloud backend or mobile app can go from code to production in an hour. Hardware updates - when they involve physical changes to the device - ship once every 18-24 months if you are lucky, measured by production runs.
This asymmetry has architectural implications. The firmware (software running on the device) and the cloud backend need to be designed to be version-independent from day one. A cloud backend that assumes all devices are running the same firmware version will break as soon as you have any devices in the field. Devices running older firmware versions will continue to exist in your fleet for years.
The principle: design for backward compatibility from the start. Every communication protocol between device and cloud should handle the case where the device is running firmware from two years ago. Every cloud-side change should be non-breaking to devices running previous firmware versions. This is harder to build than the naive version, and it is dramatically cheaper than the alternative of discovering you cannot push any backend changes without breaking your oldest device cohort.
OTA Updates: Architecture That Cannot Be an Afterthought
Over-the-air firmware updates are a safety and reliability requirement for any consumer or commercial IoT product. They are also architecturally non-trivial.
The components of a proper OTA system:
Update delivery. The device needs to check for available updates, download them securely, and apply them. The download needs to be resumable (devices have intermittent connectivity), verified (cryptographic signature of the firmware package), and safe (the device should not brick if the download is interrupted).
Rollout control. You cannot push a firmware update to your entire device fleet simultaneously and discover three hours later that the update has a critical bug. You need staged rollouts - push to 1% of devices, monitor error rates and connectivity, push to 10%, monitor again, then full rollout. This requires a device management system that knows the firmware version of every device in the fleet.
Rollback capability. If a firmware update causes problems, you need the ability to roll back to the previous version. This requires A/B partition design in the device firmware - the device keeps the previous firmware version until the new version has successfully booted and run for a stability window.
Update notifications to users. Users should know when their device is updating and why. A device that becomes unresponsive for 2-3 minutes during an update without notification creates support tickets.
The OTA system is one of the components I most consistently see missing or inadequate in hardware startups. It is also one of the most expensive to retrofit, because it requires both firmware changes and cloud infrastructure changes that need to be coordinated across your entire fleet.
Device Management: Knowing What Your Fleet Is Doing
Once you have devices in the field, you need visibility into what they are doing. Device management is the infrastructure for this visibility.
The core capabilities:
Device registry. A database of every device that has been manufactured, its unique identifier, its current firmware version, its online/offline status, and its assignment to a customer account. This sounds simple and is often underbuilt. I have worked with hardware companies that had thousands of devices in the field and no reliable way to query the current firmware version across the fleet.
Telemetry collection. The data the device sends to the cloud - sensor readings, error logs, performance metrics, connectivity events. The architecture question is how to store and query this data efficiently at scale. Time-series databases (InfluxDB, TimescaleDB) are designed for this access pattern; relational databases are not.
Remote diagnostics. The ability to request a diagnostic report from a specific device - current state, recent errors, connectivity history. This requires a command channel from cloud to device, which is different from the data channel from device to cloud. MQTT is the standard protocol for this bidirectional communication.
Alerting. When devices go offline, report errors, or show anomalous readings, someone needs to be notified. The alerting system needs to distinguish between a device that has been offline for two minutes (normal) and one that has been offline for three days (problem).
The device management platform is what lets you run a hardware business operationally. Without it, support is manual, fleet updates are blind, and quality problems emerge slowly through customer complaints rather than proactively through monitoring.
Cloud Architecture for IoT: Different Patterns Than SaaS
IoT cloud architecture has specific characteristics that differ from standard web application architecture.
High-frequency small writes. A device sending temperature readings every 30 seconds creates a very different database access pattern than a web application where users submit forms. Standard relational database architectures that work well for SaaS applications often struggle with the write throughput of an active IoT fleet. Time-series databases or purpose-built IoT data platforms handle this access pattern better.
Variable connectivity. Devices go offline. When they come back online, they may need to sync data that was buffered locally during the offline period. The cloud architecture needs to handle out-of-order data arrival and reconcile local device state with cloud state.
Message queuing for reliability. Direct HTTPS calls from device to cloud fail when the cloud is unavailable or the network is unreliable. MQTT with a message broker (AWS IoT Core, HiveMQ) gives you reliable message delivery with guaranteed ordering and persistence.
Edge processing. For devices that generate large amounts of data (video, audio, high-frequency sensor data), sending everything to the cloud is expensive and slow. Edge processing - doing computation on or near the device - reduces the data volume that needs to be transmitted. The architecture question is where to draw the edge/cloud boundary for each data type.
The IoT cloud architecture decisions I make for clients consistently are: MQTT for device communication, time-series database for sensor data, relational database for device registry and customer data, and staged rollouts for firmware updates.
The Hardware Supply Chain Factor That Affects Architecture
Hardware products have a constraint that software products do not: the hardware cannot be updated without a production run. This creates specific architectural pressures.
If your product has a hardware design flaw that requires the PCB to be revised, that revision takes months and costs significant money. This means hardware decisions need more rigor up front than software decisions, and the architecture of the firmware needs to account for the limitations of the hardware that will actually ship.
The practical implication: the firmware architecture needs to be forward-thinking about what the hardware is capable of, and the cloud backend needs to be designed to work within those hardware constraints. I have seen firmware teams design features that required a faster processor than the production hardware had, because the development hardware was spec'd higher than the cost-optimized production version.
The other supply chain factor: component availability. The chip shortage of 2020-2022 forced many hardware companies to substitute components - a different microcontroller, a different wireless module. If the firmware is tightly coupled to specific hardware, component substitutions require firmware rewrites. The hardware abstraction layer in the firmware architecture is the technical solution: a clean separation between hardware-specific drivers and application logic.
Fractional CTO engagement for IoT startup CTO needs most often focuses on these interconnection points - where the embedded system decisions constrain the cloud architecture, and where the cloud architecture requirements should constrain the hardware design. Someone who only understands cloud or only understands embedded systems cannot make these calls well.
Book a 30-minute call: https://calendly.com/alpsf/zoom-with-aleksandr