IoT projects stall on provisioning, updates, and connectivity cost rather than on hardware. Here is what actually decides an IoT product build.
Codestreaks Team
IoT product development is the work of making one device work, and then making ten thousand of them work when you cannot touch any of them. The first part is an engineering problem with a clear finish line. The second is the actual product, and it is where budgets and timelines go.
We have delivered 30+ projects to production since 2024, and connected-product work follows a reliable arc. The prototype impresses everyone in the room within weeks. Then the questions start. How does a unit get its credentials on a factory line. How does it get a firmware update in a customer basement with bad signal. What happens when 400 of them come back online at once after an outage.
Here is what to decide before the prototype makes those questions urgent.
Every device needs an identity, and how it gets one is a decision with factory consequences. Certificates burned at manufacture are the strongest option and require a step in someone else's production process. Claiming a device during customer setup is cheaper to manufacture and puts the burden on a user standing in a hallway with a phone.
Get this wrong and it is not a software fix. Recalling units for reprovisioning costs more than the software did.
The question to answer before hardware is finalized: who is trusted at the moment of first boot, the factory, the installer, or the end customer. Everything about the security model follows from that answer, and it cannot be changed for units already in the field.
Every device you ship will need a firmware update. Not maybe. The only question is whether you can deliver one safely.
That means an A/B partition scheme so a failed update rolls back rather than bricking a unit, signed images so nothing unsigned installs, staged rollouts so a bad build hits 1% of the fleet rather than all of it, and telemetry that tells you the update landed. A bricked fleet is the end of a hardware company, and it is entirely preventable with a week of work done up front.
We treat OTA as a day-one requirement, not a version-two feature. The teams who defer it always defer it into the moment when they most urgently need it.
WiFi is free and unreliable, because it depends on a customer's router and their willingness to type a password. Cellular is reliable and costs money forever, per device, per month. LoRa and similar are cheap and slow, which is fine for a sensor reading and useless for anything chatty.
The mistake is choosing the radio on technical preference and discovering the unit economics later. Work it the other way. Decide how much data each device must send, multiply by the fleet size you are aiming at, price it, and see whether the product still makes sense. That calculation has killed more IoT ideas than any technical problem, and it is better to know in week one.
While you are there, decide what the device does when it cannot reach anything. Local buffering with a bounded queue is usually right. Unbounded queues fill storage and take the device down, which is a self-inflicted outage.
On the cloud side, an IoT product is ingestion, storage, and rules. The traffic pattern is different from a web app. It is constant, it is bursty at reconnection, and it never has a quiet period you can deploy into comfortably.
So design for the reconnection storm. After a regional outage, every device comes back at once, and naive retry logic turns a recovered network into a self-inflicted denial of service. Jittered backoff on the device side is a two-line fix that saves an incident.
And separate hot data from cold early. Recent readings need to be queryable in milliseconds for dashboards and alerts. A year of history needs to be cheap, not fast. Putting both in the same store means paying premium prices for data nobody reads, which is the same architecture question we cover in custom cloud application development.
Useful now: anomaly detection on sensor streams, predictive maintenance from device history, and pulling patterns out of the support notes your field techs have been writing for years. All three sit next to the data rather than inside the control path.
Not useful now: letting a model decide device behavior in real time. Keep control logic deterministic and testable, and let the model recommend rather than act.
Cost is rarely the barrier. Production agents typically run $50 to $2,000 per month, and good engineering around caching, model routing, and prompt design cuts that by 3 to 10 times. The barrier is evaluation. An agent without an evaluation suite is a liability with a chat interface, and on a device fleet a confident wrong answer becomes a truck roll.
Our typical engagement runs 4 to 8 weeks from kickoff to live deployment, at $8,000 to $60,000 fixed price. For connected products, the software side splits into three pieces that can be phased: device firmware and connectivity, the ingestion and management backend, and the customer-facing app.
A sensible first phase is a small fleet, real telemetry flowing, OTA proven end to end, and one dashboard. That is enough to learn what the hardware actually does in the field, which is knowledge you cannot get from a bench.
The companion mobile app is usually phase two, and it is worth resisting the urge to build it first because it demos well. Pairing flows, offline behavior, and background connectivity are their own project with their own platform rules, and the tradeoffs there are the ones covered in custom mobile development. Ship the fleet you can operate, then give it an interface.
Prototypes lie. A device that works on a desk with good WiFi tells you nothing about a hundred of them in a warehouse with metal racking. Most of our work across projects is reliability engineering rather than the first demo, and IoT is where that is most obviously true.
Operating the fleet, not building the device. Provisioning identity, delivering firmware updates safely, and handling reconnection at scale are what consume the schedule after the prototype works.
Start from data volume per device and target fleet size, price the recurring cost, and check the product still works economically. Choose the radio that fits that answer rather than the one that is technically nicest.
Yes. Every fielded device eventually needs new firmware, and adding OTA after units have shipped is far harder than including it. Signed images, A/B partitions, and staged rollouts are the minimum.
The software side of a first phase, covering telemetry ingestion, device management, OTA, and one dashboard, generally fits our 4 to 8 week engagement window. Costs rise with fleet size, data retention, and certification requirements rather than with feature count.
Managed platforms handle the undifferentiated parts well and are usually the right base. The custom work is your device logic, your data model, and your customer experience. Keep those portable so the platform stays a choice rather than a dependency.
If you have a working prototype and no plan for provisioning or updates, that is the conversation worth having now, before units exist. We offer a free 30-minute scoping call and reply within two business days. We take two engagements per quarter and we say no when the scope does not fit.
See how we approach custom web development, or start a project and tell us how many devices you expect in year one.
