Connected products are budgeted like software projects and behave like hardware ones. The firmware is a bounded piece of work with a clear finish line. Everything around it - provisioning, updates, fleet visibility, and a support obligation measured in years rather than months - is where the real cost sits, and it is almost always discovered after the first units ship.
01The bill of materials nobody forecasts
A connected product needs an identity for every device, a way to provision that identity during manufacture, a channel to deliver updates safely, and enough telemetry to know when a subset of the fleet is misbehaving. None of these are optional at scale and none are firmware.
The asymmetry that makes this expensive is that mistakes are not fully recoverable. A bad server deploy is rolled back in minutes. A bad firmware update to devices in the field can brick units that must then be physically retrieved, and the cost is logistics rather than engineering.
| Component | Typical share | Discovered when |
|---|---|---|
| Device firmware | 20-30% | Planned from the start |
| Update and rollback infrastructure | 15-25% | First field bug |
| Provisioning and identity | 10-15% | First manufacturing run |
| Fleet telemetry and diagnostics | 15-20% | First support escalation |
| Backend and data pipeline | 20-25% | Partially planned |
| Multi-year maintenance | Ongoing | After launch |
02Updates are the feature that makes everything else survivable
Over-the-air updates should be built before the first unit ships, not after the first field bug. A fleet without a working update path is a fleet where every defect is permanent, and the pressure that creates leads to rushed updates - which is exactly the condition under which devices get bricked.
Safety comes from a small set of properties: signed images so a device only accepts firmware you built, an A/B partition scheme so a failed update falls back to the previous image, staged rollout so a bad build reaches a hundred devices rather than a hundred thousand, and a health check that must pass before the new image is marked good.
03Connectivity choices constrain everything downstream
Power budget, protocol and connectivity are usually decided early on hardware grounds and then quietly dictate what the software can do for the product's whole life. A device on a constrained radio budget cannot stream verbose telemetry, which means diagnostics must be designed as summaries rather than logs.
Deciding telemetry alongside connectivity avoids the common outcome: a fleet in the field, a defect affecting some fraction of it, and no way to tell which units are affected because the data needed to answer that was never budgeted for in the power envelope.
- Decide what you must be able to diagnose remotely before fixing the power budget
- Prefer summarised, event-driven telemetry over periodic verbose logging
- Ensure devices can be asked for more detail on demand rather than always sending it
- Include a mechanism to identify affected units by firmware version and hardware revision
04Security obligations now outlive the product
Regulation across major markets increasingly requires connected products to receive security updates for a defined support period, and to ship without default credentials. That converts a one-off build into a multi-year commitment with staffing implications well beyond launch.
This should be priced as a support obligation from the outset. The cheapest way to meet it is to build the update infrastructure properly on day one - the same mechanism that makes field bugs recoverable is the one that makes the security commitment sustainable.
Topics
Aarav Patel
Principal Engineer · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.