Connected-device projects tend to fail at a predictable point. Not the prototype — the prototype almost always works. They fail somewhere between the fiftieth device and the five thousandth, when the things nobody scoped start arriving at once: firmware that needs updating in the field, certificates that expire, a sensor that reports plausible nonsense, and a data volume that made sense at pilot scale and doesn't at production scale.
The hardware is rarely the hard part. The software that surrounds a fleet of devices over its operating life is where the difficulty lives, and it is almost entirely custom work — because nobody else has your devices, in your environment, doing your job.
What changed: the intelligence moved to the device
The defining shift of the last two years is that meaningful computation stopped requiring the cloud. Models in the small-parameter range now run on hardware that fits in a device budget, which rearranges the entire architecture.
The old pattern was: sense, transmit everything, decide centrally, send an instruction back. It costs bandwidth on every reading, it fails when connectivity does, and it puts a network round trip inside every control loop.
The current pattern inverts it. The device decides locally and reports outcomes rather than raw streams. A camera that identifies an event on-device sends an event, not video. That single change cuts bandwidth by orders of magnitude, keeps the system working when the link drops, removes latency from the loop, and means sensitive raw data never leaves the premises at all.
The same economics we described in the 20× inference bill nobody is watching apply here, only more sharply — because in a fleet you are paying them per device, continuously.
The four systems every fleet needs
A connected product is not one piece of software. It is four, and teams that scope only the first one are the teams that get stuck.
1. Device management
Provisioning, identity, configuration, health monitoring, decommissioning. Every device needs a unique identity from the factory, a way to be enrolled without a technician typing anything, and a way to be revoked when it is lost or sold. Retrofitting identity onto a deployed fleet is close to impossible, which is why this is the one thing that has to be right before the first unit ships.
2. Over-the-air updates
You will ship firmware with a bug in it. The question is whether you can fix it without visiting every device. A serious OTA system needs staged rollout to a small cohort first, signed images so a device only accepts your firmware, atomic installation so an interrupted update does not brick the unit, and automatic rollback on failure to boot.
A fleet without safe OTA is a fleet you cannot change, and a device you cannot change is a device you cannot secure.
3. Data pipeline
Ingestion, validation, storage, aggregation. The design question that decides your costs is what you keep and for how long. Full-resolution readings from thousands of devices accumulate faster than teams expect, and most of it is never queried again. Decide the retention and downsampling policy at design time; discovering it from a storage bill is expensive and irreversible for the data you already discarded — or already kept.
Validation matters more than it sounds. Sensors drift, fail partially, and report values that are wrong but well-formed. A pipeline that trusts its inputs will quietly poison every dashboard and model downstream.
4. The application
The dashboard, the alerts, the control interface — the part everyone imagines first and the part that depends entirely on the other three being right.
Security is now a legal requirement, not a virtue
Connected devices spent a decade being the worst-secured category in computing: default passwords, no update path, open ports. Regulation has caught up. The EU's Cyber Resilience Act imposes security obligations across the lifecycle of products with digital elements — including vulnerability handling and providing security updates for a defined support period — and comparable labelling and baseline schemes have advanced in other markets.
The practical baseline any new fleet should meet:
- Unique credentials per device, provisioned at manufacture. Never a shared default.
- Signed firmware, verified by the device before installation.
- Encrypted transport with certificate validation that is actually enforced.
- A defined support window, and the ability to ship a patch within it.
- A disclosure route, so someone who finds a flaw can tell you.
Notice that most of these are decisions made before the first shipment. Security in a device fleet is overwhelmingly a design-time property; there is very little you can add later to hardware already sitting in someone's building.
Scoping a connected product honestly
The most useful exercise before committing to a build is to write down what happens in each of these situations. Every one of them will occur.
- A device loses connectivity for a week. Does it keep working? What happens to the data it gathered?
- A sensor starts reporting values that are wrong but plausible. How long before anyone notices?
- You need to ship a security patch to every unit within 48 hours. Can you?
- A customer returns a device. How do you revoke its access and wipe its credentials?
- The fleet grows 10×. What breaks first, and what does it cost?
- A device is physically opened by someone who wants your keys. What do they get?
A team that can answer all six has a project. A team that can answer two has a prototype and an optimistic timeline.
The part worth repeating
The interesting work in connected products is not making a device talk to a server — that has been a solved problem for years. It is everything that keeps a population of devices working, updatable and trustworthy for the years they remain deployed.
Which means the decisions that determine whether a fleet is maintainable are made early, in software architecture, long before scale exposes them. That is an uncomfortable place for them to sit, and it is where they sit regardless.
We build device management, OTA and data infrastructure for connected products — including the edge inference that keeps data local. Tell us what you are deploying.
