Hardware Is 15% of Your IoT Budget. The Other 85% Is Where Projects Die.
An IoT operator running 500,000 devices for 10 years published his cost breakdown.
Hardware and connectivity: 15% of total cost over a decade. Cloud services, integration, maintenance, OTA firmware updates, security management, device lifecycle: 85%.
Every IoT pilot I have reviewed is built around the 15%. Every production failure I have diagnosed lives in the 85%.
The pilot looks nothing like production
At 100 devices, you can run everything on a Raspberry Pi and a single API. OTA updates are manual. Monitoring is a cron job. Backend costs are negligible.
At 10,000 devices, none of that architecture survives.
You need time-series databases for sensor data at volume. Load balancers. Redundant ingestion layers. A conflict-free sync protocol for devices that go offline for days and reconnect with 72 hours of buffered data. An OTA pipeline that does not brick a device in the field.
The jump from 100 to 10,000 devices is not a quantity change. It is an architecture change that touches every layer of your stack.
Connectivity economics break faster than you expect
A cellular SIM at $5/month per device costs $500/month for 100 devices. Manageable for a pilot.
At 50,000 devices, that is $250,000 per month. At that number, connectivity alone exceeds most Series A engineering budgets.
The right protocol for production is almost never the right protocol for a quick prototype. LoRaWAN, NB-IoT, MQTT over WiFi, cellular - each has a different cost curve, range, power budget, and data throughput. Choosing the wrong one during a pilot means a hard migration when you try to scale.
Most teams choose the protocol easiest to prototype with. That decision looks free in month 1. It is expensive in month 18.
What the 85% actually costs
Backend infrastructure scales non-linearly. A million sensor messages per day requires time-series storage, message queuing, and a data ingestion layer designed for that volume - not retrofitted from a Raspberry Pi prototype. The backend that handles 100 devices and the backend that handles 10,000 devices are not the same backend with a bigger server.
OTA firmware is a different problem at every scale. 10 devices: you update manually. 1,000 devices: a broken OTA pipeline means a field visit for each unit. 100,000 devices: one bad firmware push can brick your entire fleet overnight. This infrastructure needs to be designed before the first production batch ships, not after you have 10,000 units in the field.
Security and device lifecycle management do not appear in pilot budgets but show up immediately in production. Device authentication at scale, certificate rotation, firmware signing, tamper detection - none of it matters with 10 devices in a lab. It matters at 1,000 devices at customer sites, and there is no retrofit path.
Field maintenance economics change the unit math entirely. A 2-year battery sounds acceptable for a pilot. At 100,000 deployed devices, a $10 technician visit per unit every 2 years costs $500,000 per year in field operations alone. That is a business model decision, not a component decision.
Integration with existing systems is always underestimated. In industrial IoT production deployments, your clean pilot dashboard becomes a connector to ERP, billing systems, SCADA, and legacy databases that were not designed to talk to IoT devices. This integration work adds months, not weeks - and IoT production costs from this layer alone are almost never scoped correctly before the contract is signed.
Why fragmented teams fail at this layer
The 85% breaks when the team that designed the pilot is not the team that builds production.
Hardware engineers hand off to backend engineers who hand off to integration engineers. Each team solves their layer. Nobody owns the seams between layers. And the seams are exactly where the 85% of costs live.
One team, no subcontractors, from hardware protocol selection through backend ingestion, OTA infrastructure, security model, and integration surface - that is what Silicon-to-Cloud Integration means in practice. Not "what hardware does it need." But "what does this product look like at 10,000 devices, and is the architecture we are building ready for that."
Most teams optimize for their first 100. We design for their first 10,000.
Three questions before you commit to production architecture
If you are running an IoT pilot right now:
What is your total cost per device per month at 10x your current scale? Not hardware cost - total cost including backend infrastructure, connectivity, field maintenance, and support. Run this math before you choose your connectivity protocol and backend stack.
What does your OTA process look like at 1,000 devices? If the answer is "we will figure that out later" - you have already created a production risk that cannot be patched in firmware.
What legacy systems does your production deployment need to connect to? Every integration discovered after the first production batch ships adds months and budget that were not in the original scope.
Audit before you commit
Every IoT project we take starts with a review of the full stack: hardware spec, connectivity selection, backend architecture, OTA strategy, security model, integration surface. Audit before contract - that is how we find the design decisions that work for a pilot and break at production scale.
Better to find them before the first batch than after.
If you are scaling an IoT product and want a second opinion on the architecture, send us the hardware spec and a description of your target scale. We will tell you exactly what we see.