The real cost of an IoT product: beyond the build

When people budget for a connected product, they usually budget for the build: the hardware design, the firmware, the cloud platform and the apps. That is the part with a clear start and end, and the part a proposal prices. It is also, for most products, only the beginning of what the product will cost.

A connected device keeps costing money for as long as it is switched on. It uses a network, sends data to servers, runs firmware that needs fixing and patching, and eventually wears out. None of this is a reason not to build. It is a reason to understand the whole picture before you commit, and to make design decisions that keep the running costs sensible.

Build cost versus lifetime cost of ownership

The build cost is what it takes to get the first working product into the field. The lifetime cost of ownership is everything it takes to keep a fleet of those products working, secure and useful until the last one is retired. The second is almost always the larger, and it is shaped by decisions made during the first.

Some examples of build decisions with long tails:

• How often a device reports. Every message costs data, cloud processing and battery. Reporting every few seconds when every few minutes would do multiplies costs across a fleet for years.
• Whether processing happens on the device or in the cloud. Sending raw data is simpler to build but more expensive to run than sending the result.
• Whether the device can be updated remotely. Leaving out over-the-air updates saves effort now and guarantees site visits later.
• Which components you choose. A part that is cheap today but hard to source in a few years can force a redesign.

The cheapest device to build is rarely the cheapest device to own.

The running costs, one by one

Connectivity per device

Every device on a cellular network needs a SIM and a data contract, and those charges recur for every device, every month. The cost depends on the technology (LTE-M, NB-IoT, standard cellular), how much data each device sends, and whether you need coverage across networks or borders. Wi-Fi avoids per-device contracts but depends on each site's network and the people who manage it. LoRaWAN keeps per-device costs low but may need gateways, which have their own installation and upkeep.

The practical lesson is to design the data a device sends as carefully as the data it collects. Compact message formats, sensible reporting intervals and sending changes rather than repeats all reduce a cost you will pay for the life of the fleet.

Cloud

Cloud costs grow with the number of devices, the volume of messages, how long you keep data and how much processing you do on it. A platform that is inexpensive for a pilot can become costly at fleet scale if it was not designed for it. Worth planning for early:

• How long raw readings are kept, and when they are summarised or archived.
• Which data needs to be real time, and which can be processed in batches.
• How reporting and analytics are separated from live ingestion, so heavy queries do not slow the system down.
• Where the data is hosted, which also matters for compliance with POPIA.

Firmware maintenance and security patching

Firmware is never finished. Bugs appear in the field that never appeared on the bench. The libraries and radio stacks it depends on publish security fixes. Networks change. Customers ask for new features. Each of these means a new release that has to be built, tested and rolled out safely.

This is ongoing engineering work, and it needs a budget and an owner. It is much cheaper when the product was built for it: automated tests, reproducible builds, documented interfaces and a reliable, staged update process with rollback. It is much more expensive when every release is a careful, manual event that only one person knows how to run.

Device lifecycle and replacement

Every device has a life: provisioning, installation, operation, maintenance, and eventually retirement. Each stage has costs:

• Provisioning: getting each device its identity, keys and configuration, in the factory or in the field.
• Installation: getting it on site and working, and knowing which device is where.
• Maintenance: site visits, consumables, repairs and battery replacements. Good remote diagnostics reduce these by telling you which visits are really needed.
• Replacement: batteries age, components fail, radio technologies are retired by networks, and parts go out of production.
• Retirement: removing devices from service, revoking their credentials and handling their data properly.

Planning for replacement from the start, for example by designing for a second source of key components, avoids a forced redesign later.

Build or buy your device management platform

Device management covers provisioning, identity, configuration, over-the-air updates, monitoring and remote commands. You can build it yourself, buy a platform, or combine the two. There are good options either way:

• AWS IoT provides managed device connectivity over MQTT, device identity and security, device state and remote jobs such as firmware updates, within the wider AWS ecosystem. You pay for usage, and you build your own applications on top.
• ThingsBoard is an IoT platform for device management, data collection and dashboards, which can be self-hosted or used as a hosted service. It can get a fleet visible quickly, though dashboards and workflows beyond what it offers need custom work.
• Building your own on standard components gives complete control and no platform licence, but you own every feature, every fix and every security update.

How we think about the choice:

1. Buy the commodity parts. Secure device connectivity and identity are hard to build well and rarely what makes a product different.
2. Build what is specific to your business. The data model, workflows, integrations and dashboards your users rely on are usually where the value is.
3. Price the platform at fleet scale, not at pilot scale, and include the cost of the engineering time to run it.
4. Avoid lock-in you cannot justify. Know what it would take to move your devices and data if you had to.

This is the kind of decision we work through in our IoT device management work, and it shapes what goes into an IoT monitoring platform on top.

Questions to ask any vendor, including us

Whoever builds your product, these questions will tell you a great deal about what it will cost to own. Ask them before you sign, and expect clear answers:

1. What will each device cost to run each month, including connectivity and cloud, and how does that change as the fleet grows?
2. How often does each device report, how much data does it send, and why that much?
3. How are firmware updates delivered, tested and rolled back if something goes wrong?
4. Who is responsible for security patches after launch, and how quickly are they applied?
5. What happens to a device when power or connectivity is lost, and what happens to its data?
6. How do we know when a device needs a site visit, and when it does not?
7. Which platforms and third-party services does the system depend on, and what would it take to move away from them?
8. Who owns the code, the data, the cloud accounts and the signing keys?
9. What documentation and tests will we receive, and could another team take over the product from them?
10. How are devices provisioned, and how are they retired?
11. Which components are at risk of going out of production, and what is the plan if they do?
12. What ongoing support is included, and what is charged separately?

A vendor who has thought about these questions will have answers, and will be comfortable being asked. For how we approach a project from discovery to running it in the field, see our services. If you are weighing up a connected product and want to talk through the full cost of owning it, get in touch.