What this is. Opinion + Experience + Fact (30% opinion · 50% experience · 20% fact). Written in collaboration with AI — I discuss, I do not outsource.

Why so many connected products stall at the same place — the jump from one working device to a fleet of thousands — and the five jobs that carry you across it.

A prototype is a promise. It sits on your bench, blinking, doing the thing you built it to do, and it feels like you are almost finished. You are not almost finished. You are at the start of the harder half.

Because the first device and the ten-thousandth device are not the same product. The first is a demo you can hold in your hand. The ten-thousandth is a business you can't touch — scattered across cities, basements, factory floors, and customer sites you will never visit. I have taken a lot of products across this gap, and I have watched more of them stall right here than at any other point. The device was never the hard part. Everything around the device, once there are thousands of them, is.

Here is what actually changes.

1. One device you can reach. A fleet you cannot.

On your bench, every problem has the same fix: pick it up. Reflash it, poke it with a debugger, power-cycle it, swap a wire. That option quietly disappears the moment the product ships. The device is now in someone's wall, or a moving truck, or a machine on a factory floor — and you will never physically touch it again.

So every single thing you used to do by hand — update it, diagnose it, recover it when it wedges — now has to happen remotely, over a network that drops, to a device that might be asleep. If you did not design for that from the beginning, you did not design a product. You designed a demo that happens to have a lot of copies.

▸ First principle. At scale, "walk over and fix it" stops being an option — so every fix has to be possible from a thousand miles away.

2. One-off setup becomes provisioning.

Setting up one board is a cable and a coffee: flash it, type in the Wi-Fi, paste a key, done. Setting up ten thousand is a different category of problem. Each unit needs its own identity, its own keys, and its own configuration — installed on a factory line, at speed, with no engineer babysitting each one.

That is provisioning, and teams almost always underestimate it. Do it well, and a device wakes up on the line already knowing who it is and how to reach home. Do it late, and you are hand-holding every unit forever — or worse, you ship ten thousand devices that share a single identity and key, which is a security incident quietly waiting to be discovered.

▸ First principle. Identity has to be born on the factory line, not bolted on afterwards.

3. "It works" becomes "which ones don't?"

With one device on your desk, health is a glance — you can see the LED, read the log, feel that it is warm. With ten thousand in the field, "does it work?" is the wrong question. The right question is: "which ones don't — and how do I know before the customer does?"

At scale you need to see the whole fleet, continuously: which cohort is crashing, which firmware version is drifting, which batteries are fading, which region just went quiet. Without that view, your first signal of a problem is a support ticket — which means it already reached a human, and there are probably thousands more just like it that you cannot see yet.

▸ First principle. You cannot manage a fleet you cannot see.

4. The five jobs of fleet management

Put those shifts together and a pattern falls out. Everything that gets hard between one device and a fleet lands in exactly five jobs — and a real connected product needs all five, not the dashboard that a lot of vendors call "fleet management" and stop there.

One device becomes a fleet — the five jobs On the left, a single device on the bench. An arrow marked times-ten-thousand leads to a grid of many devices — the fleet, most healthy, a few unhealthy. The five jobs of fleet management run underneath: provision, monitor, update, recover, secure. One device becomes a fleet 1 · your bench x 10,000 the fleet · which ones don't? 1 · PROVISION 2 · MONITOR 3 · UPDATE 4 · RECOVER 5 · SECURE

Provision — give every device its identity and keys on the line. Monitor — watch the whole fleet's health continuously, not one device at a time. Update — ship firmware safely, in staged cohorts, with rollback (never the whole fleet at once). Recover — bring a wedged device back on its own, without a truck roll. Secure — protect identity, keys, and the update path across thousands of endpoints, because every device is also a door.

▸ First principle. Fleet management is not a dashboard — it is five jobs: provision, monitor, update, recover, secure.

5. None of it is your product — so we built it once

Here is the uncomfortable part, and it is the same for every connected product ever made: none of those five jobs is your product. Your customer does not pay you for provisioning or telemetry or staged rollouts. They pay you for the thing your device does. Yet the five-job layer is enormous, it is the same on every product, and most teams rebuild it from scratch — a little worse each time — in the months they meant to spend on the thing that actually matters.

So we built that layer once, properly, above the device and above the cloud, and open-sourced it. It is called EmbedIQ. You inherit the fleet layer as a foundation instead of a side quest, and your engineers spend their months on your product. The architecture and the code are public — read them, and judge for yourself.

▸ First principle. Spend your engineers on your product; inherit the fleet layer, don't reinvent it.

The prototype on your bench is real, and it is worth being proud of. It is also the easy half. The moment you decide to make ten thousand of them, you have signed up for the other half — the reach, the identity, the visibility, the five jobs — and the teams that ship are the ones that saw that coming and built for it from the first device, not the ten-thousandth.

FAQ

Why do so many IoT products stall between prototype and fleet?
Because the device was never the hard part. At scale, the surrounding jobs — provisioning, monitoring, updating, recovering, and securing thousands of remote devices — become the whole job, and most teams underestimate them until the ramp exposes them.

What is device provisioning?
Giving each device a unique identity, keys, and configuration automatically on the factory line, so it wakes up already knowing who it is and how to reach the cloud — without an engineer setting up each unit by hand.

What are the five jobs of fleet management?
Provision (identity on the line), Monitor (continuous fleet health), Update (safe staged OTA with rollback), Recover (remote and automatic recovery), and Secure (identity, keys, and a protected update path). A dashboard alone is not fleet management.

Why can't you update a whole fleet at once?
A bad build pushed to every device bricks the whole fleet at once. You roll out in stages to a small cohort, watch the telemetry, and halt if error rates climb — so the blast radius is one percent, not one hundred.

How do you monitor thousands of devices?
Continuous telemetry from every device flows into a fleet view that surfaces failing cohorts, drifting firmware versions, dying batteries, and quiet regions — so you find problems before a customer's support ticket does.

The short version of this is on my LinkedIn; the longer story and the links are on my profile.