AI ERP with agents inside the systems you run
AI phone and voice agents for real calls
LLM.coPrivate, self-hosted LLM deployments
Legal AI infrastructure for firms
AI RFP discovery and response drafting
Automatic.coBusiness process automation
CyberAttack.aiThreat detection and defense
Secure AI virtual data rooms
10 business days
To start an IoT engagement
Discovery through first prototype scope
100%
Senior engineers, US-based
Firmware through cloud pipeline
Every sprint
Working hardware or software on review
A device or a preview URL, not a slide deck
100%
Firmware, code, and designs you own
From the first commit
What "IoT development" covers
Four disciplines, one product
"IoT developer" is a broad label because the job genuinely spans hardware, embedded software, cloud infrastructure, and a companion application. Most IoT projects underestimate how much of the budget belongs to the parts that aren't the device itself.
Hardware and embedded firmware
The board, the sensors, and the low-level code that reads them, manages power, and talks to whatever radio or wired interface the device uses. This is where the power budget and the connectivity choice get made, and both are expensive to revisit later.
Connectivity
The protocol that gets data off the device — Wi-Fi, Bluetooth, Zigbee, LoRaWAN, or cellular — chosen for range, power draw, and data volume rather than whichever one a previous project happened to use.
Cloud and data platform
Ingestion, time-series storage, and the rules or alerts that turn raw sensor readings into something a person or another system acts on. This is usually a bigger, longer-lived engineering effort than the firmware that feeds it.
Companion app and dashboard
The mobile or web interface a user or operator actually touches — provisioning a new device, viewing live and historical data, and managing settings without needing to understand the protocol underneath.
Device management and OTA updates
The pipeline that gets a firmware fix onto devices already in the field, safely, without bricking a fleet you can't physically reach. This has to be designed in before the first unit ships, not added after the first bug report.
Industrial IoT
Sensor and control-system integration for manufacturing, agriculture, or logistics environments, usually built against wired industrial protocols and reliability standards that consumer-facing IoT never has to meet.
Connectivity
Choosing a connectivity protocol before anything else gets designed
This decision shapes the hardware, the power budget, and the cloud architecture that follows it. Reversing it after devices ship is closer to a new product than a firmware update.
Wi-Fi
High bandwidth and simple integration with existing home or office networks, at the cost of real power draw — a poor fit for anything running on a battery for months at a time, and dependent on network credentials a user has to configure correctly.
Bluetooth and BLE
Low power and simple for short-range, phone-paired devices — wearables, fitness trackers, smart locks — but range is measured in meters, not the building- or site-wide coverage many products actually need.
Zigbee and Z-Wave
Mesh protocols built for smart-home and building automation, where devices relay each other's signals to extend range without a cellular bill. They require a hub, which is a real product decision, not just a technical detail.
LoRaWAN
Long range at very low power, at the cost of low data rates — right for a soil-moisture sensor reporting a few bytes a day, wrong for anything streaming continuous data.
Cellular (NB-IoT, LTE-M, 5G)
Works anywhere there's cellular coverage without a local network to configure, at a real per-device connectivity cost and with a data plan to manage across a whole fleet — usually the right call for devices that move, or that are deployed somewhere with no existing network to join.
Wired and industrial protocols
Modbus, OPC-UA, and similar protocols dominate industrial settings where devices are fixed in place and reliability matters more than flexibility. Retrofitting a wireless-first design onto an industrial floor built around wired standards is usually the wrong direction to go.
What's involved
IoT engagement types
What moves the scope is less the device count and more how many distinct pieces — hardware, firmware, cloud pipeline, companion app — the engagement actually covers, and whether the hardware exists yet or has to be designed.
| Engagement | Commitment | Timeline | What's included |
|---|---|---|---|
| IoT discovery and architecture | Fixed scope | 2 – 4 weeks | Connectivity protocol selection, power and data-budget analysis, and a system architecture spanning device, cloud, and app. |
| Hardware and firmware prototype | Fixed scope | 6 – 12 weeks | A working proof-of-concept device and firmware, built to validate the core sensing, power, and connectivity decisions before a production run. |
| Production firmware and companion app | Fixed scope | 10 – 20 weeks | Production-grade embedded firmware, a mobile or web companion app, and the cloud ingestion pipeline behind both. |
| Device management and OTA platform | Fixed scope | 6 – 10 weeks | Device provisioning, fleet monitoring, and a signed, staged over-the-air update pipeline built to update a fleet safely. |
| Ongoing device fleet support | Ongoing retainer | Ongoing | Firmware maintenance, security patching, and cloud pipeline operation for devices already in the field. |
Ranges assume US-based senior engineers across hardware and software, and include the OTA and device-security work a cheaper quote often leaves out entirely. A discovery phase is worth running first specifically because the connectivity choice it produces changes almost every number that follows it.
Device security and lifecycle
The part that gets skipped, then becomes a recall
A device that ships without a plan for updating it is a device you'll eventually have to physically replace to fix. This is the most consequential set of decisions in an IoT build and the one most often left until it's too late to change cheaply.
Device identity and provisioning
Every device needs a unique, verifiable identity established during manufacturing, not assigned casually at first boot. Without it, there's no reliable way to know which device is sending which data, or to revoke access to one that's compromised or lost.
OTA update pipeline
A staged rollout — a small percentage of the fleet first, then the rest — catches a bad firmware build before it reaches every device, the same discipline a staged software deploy uses, applied to hardware you usually can't walk over and plug back in.
Firmware signing
Updates are cryptographically signed so a device only accepts firmware that's actually yours, closing off one of the more common ways a fleet gets compromised at scale.
Edge vs. cloud compute
Processing data on the device itself reduces bandwidth and works when connectivity drops; sending everything to the cloud is simpler to build and easier to update centrally. Most real products split the two deliberately rather than defaulting to one.
Decommissioning and end of life
A device that's returned, sold, or retired needs a way to be wiped of credentials and removed from the fleet cleanly — a step most IoT products don't design for until the first support ticket asks how.
Consumer vs. industrial
A smart-home product and an industrial deployment are different products
Both get called "IoT," and the similarity mostly ends at the acronym. Building an industrial system with consumer assumptions, or a consumer product with industrial complexity, both go wrong in predictable ways.
Reliability expectations
A smart-home device that occasionally drops connection is an annoyance; a sensor on a production line that silently stops reporting can halt output or miss a safety threshold. The acceptable failure mode is not the same, and the architecture shouldn't pretend it is.
Protocols in practice
Consumer products lean on Wi-Fi, Bluetooth, and mesh protocols built for a home network; industrial deployments more often run on wired standards like Modbus or OPC-UA, integrated with equipment that predates modern wireless IoT entirely.
Data volume and retention
Industrial sensor networks can generate continuous high-frequency data that needs a real time-series storage strategy and a retention policy decided up front; a consumer device reporting a few readings a day needs neither at the same scale.
Update and maintenance cadence
A consumer app updates on a normal software release cycle. An industrial system often can't take an update during a production run at all, which means the OTA pipeline has to support scheduled maintenance windows, not just "whenever it's convenient."
Environmental and safety standards
Industrial deployments frequently answer to safety and reliability standards specific to the facility or industry, which shape hardware ruggedization and failure handling in ways a consumer smart-home product never has to consider.
Data pipeline
From sensor reading to something a person acts on
The device is the part that's visible. The pipeline behind it is usually where the ongoing engineering effort actually goes.
Ingestion at scale
A pipeline built for ten devices sending data every minute behaves very differently at ten thousand devices sending data every few seconds. Designing for the fleet size you'll actually reach, not just the pilot, avoids a rebuild once it works.
Time-series storage
Sensor data is fundamentally time-series data, and a database built for that shape — rather than a general-purpose relational store pressed into service — makes both storage cost and query performance manageable as volume grows.
Edge preprocessing and filtering
Filtering noise or aggregating readings on the device before transmission cuts both bandwidth and cloud storage cost, and it's far easier to design in from the start than to retrofit onto a fleet already shipping raw data.
Real-time alerting vs. batch analytics
A temperature excursion needs an alert within seconds; a monthly usage report doesn't. Treating every data point as if it needs real-time handling adds cost and complexity the actual use case doesn't call for.
Integrating with existing business systems
IoT data is rarely useful sitting alone in a dashboard — it earns its value connected to an ERP, a maintenance system, or a business process that acts on it, and that integration is often the actual point of the project.
Related
Related services
What IoT projects usually need alongside the device itself.
Questions
Common questions about IoT development
What teams ask before a first call.
Usually some combination of four things: embedded firmware for the device, connectivity and protocol selection, a cloud pipeline for ingesting and acting on the data, and a companion mobile or web app. Which of these you need depends on whether the hardware already exists — a discovery phase is where we work that out together.
Device management and over-the-air updates are part of the scope for anything shipping more than a handful of units, not a separate project tacked on later.
By power budget, range, and data volume, in that order. A battery-powered sensor reporting infrequently points toward LoRaWAN or a low-power mesh protocol; a device with reliable power and high data needs points toward Wi-Fi or cellular; a phone-paired wearable points toward Bluetooth. There's no single right answer independent of the product.
This decision happens during discovery, before hardware is finalized, because it shapes the board design, the power budget, and the cloud architecture that follows it.
Both, depending on what you bring to the engagement. Some projects start with hardware already selected or designed and need firmware, connectivity, and the cloud pipeline built around it; others start from a concept and need hardware design and prototyping as well. Either way, the firmware, cloud, and app layers are built together so they're designed for the same device from the start.
Through a signed, staged over-the-air update pipeline designed in before the first device leaves the building, not added after a bug is discovered in the field. Updates are cryptographically signed so a device only accepts firmware that's genuinely yours, and rollouts go to a small percentage of the fleet first so a bad build doesn't reach every device at once.
Devices deployed somewhere they can't be physically reached make this discipline non-negotiable rather than a nice-to-have.
Yes, meaningfully. Industrial deployments usually run on wired protocols like Modbus or OPC-UA, tolerate far less downtime, generate more continuous data, and have to work around scheduled maintenance windows rather than updating whenever convenient. Consumer products lean on wireless protocols built for a home network and can tolerate an occasional dropped connection in a way an industrial sensor line generally can't.
We scope these as different engagements with different architectures, not the same build with a different label.
Each device gets a unique, verifiable identity established during provisioning, data is encrypted in transit to the cloud pipeline, and access to that data is scoped by least privilege the same way it would be on any other system. Firmware updates are signed so a device can verify it's only accepting code that's actually yours.
Device compromise at scale is usually a provisioning or signing gap, not a sophisticated exploit, which is why both get designed in from the first unit rather than added after a fleet is already in the field.
Yes. Provisioning a new device, viewing live and historical data, and managing settings all need an interface, and building it alongside the firmware and cloud pipeline — rather than handing it to a separate vendor — keeps the three in sync as the protocol and data model evolve.
You do. Firmware source, hardware design files, and cloud infrastructure are yours from the first commit, the same as any other engagement here. That ownership matters more in IoT than in most software categories, because switching vendors on a fleet that's already in the field is a much harder problem than switching on a web application.