IoT System Development: How to Specify Data Capture
A vague request for equipment status reporting becomes priceable only when you specify the asset list, data fields, connectivity fallback, and who reads which number.
IoT system development turns a business problem like "we need to know when the cold room drifts" into a written specification a developer can price. To get there, define three things before asking for quotes: the exact assets and data fields, the connectivity and offline behaviour, and the people who will act on each reading. If a wrong answer would cost money, the citation column decides the purchase — that is, write down where each number is used before choosing sensors.
What does IoT system development actually involve?
IoT system development involves four layers that must be specified separately: the device and sensor, the connectivity and message protocol, the data store and rules engine, and the user-facing dashboard or alert. A specification that names only the dashboard is not priceable because the device and connectivity choices drive most of the engineering effort.
The device layer includes the sensor, the controller that reads it, and the firmware that decides when to send a message. The connectivity layer chooses how that message travels — cellular, Wi-Fi, LoRaWAN, or a wired bus — and what happens when the link drops. The platform layer stores readings, applies thresholds, and manages the device fleet. The presentation layer is the dashboard, the alert message, or the API that feeds an existing ERP.
For a first specification, list each asset and the minimum data fields it must report. A cold room might need temperature, door state, and compressor run status every five minutes; a vehicle might need position, ignition state, and cargo temperature every minute while moving. If a field is not tied to a decision, leave it out of version one — every extra field adds storage, dashboard design, and testing work.
Our own delivery practice starts with a written asset-and-field table signed off by the operator, because it is the document that lets a developer estimate device firmware, platform rules, and dashboard screens without guessing. You can see the scope of that work on our IoT system development service page, which lists the layers we quote separately.
How do you turn a vague problem into a priced specification?
A vague problem becomes priceable when you write it as a decision table: asset, reading, threshold, recipient, and required action. If the recipient and the action are missing, the developer cannot size the alerting or dashboard work and will either pad the quote or exclude the feature.
Start with the phone calls you want to eliminate. If a driver currently calls to report a refrigerator fault, the specification should say which sensor detects the fault, how long the condition must persist before an alert fires, who receives it, and what they are expected to do. That single sentence replaces a paragraph of adjectives about "real-time visibility".
Then separate what the delivery team controls from what you control. The delivery team controls firmware behaviour, platform rules, dashboard layout, and integration code. You control sensor placement, SIM contracts, site power, and the staff who respond to alerts. Write both columns into the specification so that a missed alert can be traced to a named owner rather than debated after go-live.
A practical way to test the specification is to hand it to someone who was not in the meetings and ask them to describe what happens on a normal day and on a bad day. If they cannot, the document is still a wish list. This is the same discipline we apply to cold chain monitoring for food wholesale, where a temperature excursion has a documented commercial consequence.
MQTT versus HTTP telemetry: which should the specification require?
MQTT is usually the better choice for frequent, small telemetry from many devices because it keeps a persistent connection and uses far less bandwidth per message than HTTP; HTTP is simpler when devices report rarely or when the receiving system already exposes a REST endpoint. If a device sends more than a few messages per hour, specify MQTT and a message broker rather than asking each device to open an HTTP request.
| Criterion | MQTT telemetry | HTTP telemetry |
|---|---|---|
| Typical message frequency | Seconds to minutes; persistent connection | Minutes to hours; request per message |
| Bandwidth per message | Low header overhead | Higher header overhead per request |
| Offline behaviour | Broker can hold sessions; device queues locally | Device must buffer and retry each request |
| Integration with existing systems | Needs a broker and a bridge to the business system | Direct to an existing REST API |
| Firmware complexity | Client library plus connection state handling | Simple request code, more retry logic |
| Best fit | Device fleet management with many sensors | A few devices reporting to one endpoint |
The table is a starting point, not a rule. A cold chain monitoring deployment with forty temperature loggers reporting every five minutes is a natural MQTT case; a single weighbridge reporting once per shift may be simpler over HTTP. Specify the protocol and the broker together, because choosing MQTT without deciding who runs the broker leaves an unpriced item in the quote.
If you need industrial IoT solutions that feed an existing ERP or warehouse system, the specification should also name the integration point — an API, a database table, or a file drop — and who owns it. Our service overview describes how integration work is scoped alongside the device and platform layers.
How do you handle devices that lose connectivity?
Devices lose connectivity, so the specification must state what the device does while offline, how long it buffers readings, and how the platform reconciles late data. If the specification does not state a buffer duration, the developer will choose one and you will discover it during an outage.
A workable pattern is local storage with timestamps, a reconnect backoff, and a platform rule that accepts late readings but flags them. For cold chain monitoring, the flag matters because a reading that arrives two hours late still proves the temperature history, but it cannot trigger a timely phone call. The specification should say which alerts are real-time and which are reviewed after reconnection.
Firmware update strategy belongs in the same section. Decide whether updates are pushed from the platform, pulled by the device on a schedule, or applied manually during a site visit. If devices are in vehicles or remote sites, specify a staged rollout with a rollback version, because a failed update on a remote device can mean a site visit.
Device fleet management also needs a named owner for credentials and certificates. The delivery team can build the provisioning process and the rotation tooling; your operations team decides who holds the keys and when rotation happens. Writing that split into the specification prevents a later argument about responsibility.
What should the IoT dashboard show, and to whom?
An IoT dashboard design should be specified per role, not per data field: an operator needs current state and exceptions, a manager needs trends and response times, and a finance or compliance reader needs an exportable record. If two roles need different numbers, specify two views rather than one crowded screen.
List the screens before the charts. A typical first version has a fleet or site list with status colour, a detail page per asset with recent readings, an alert history with acknowledgement, and an export for audit. Each screen should name the decision it supports, which keeps the dashboard from becoming a wall of gauges nobody reads.
- Asset list: which units are reporting, which are silent, and since when.
- Asset detail: the last readings, the threshold band, and the last acknowledged alert.
- Alert history: who was notified, when, and what action was recorded.
- Export: a dated record suitable for a customer or auditor.
The dashboard specification should also say what happens when a device goes silent. A silent device is different from a normal reading, and if silence is not treated as an alert condition, a failed sensor looks like a stable process. That single rule changes the platform work and should be priced explicitly.
For operators in sectors where equipment status feeds production planning, the same dashboard rules apply; our notes on industrial IoT solutions for mining describe how site conditions affect device choice and alert thresholds.
How much does an IoT system cost to build?
The cost of an IoT system depends mainly on the number of device types, the protocol and broker choice, the number of dashboard roles, and the integration points into existing systems — not on the number of sensors alone. If the specification names one device type, one dashboard role, and one integration point, the quote can be fixed; each additional type or role adds a separate estimate line.
Hardware and connectivity are usually passed through at cost and should be quoted separately from engineering. Ask for the engineering estimate to be split by layer — firmware, platform, dashboard, integration — so you can defer a layer without renegotiating the whole project. You can find more scoping questions on our frequently asked questions page.
Frequently asked questions
What is IoT development and what does it involve?
IoT development is the work of connecting physical assets to software so their status is recorded and acted on without manual reporting. It involves device firmware, a connectivity and message protocol, a platform that stores and rules on the data, and a dashboard or integration that puts the result in front of a person or another system.
How much does an IoT system cost to build?
Cost depends on the number of device types, the protocol and broker choice, the number of dashboard roles, and how many existing systems must be integrated. A specification with one device type, one dashboard role, and one integration point can be quoted as a fixed scope; each additional type or role adds a separate estimate line.
How do you handle devices that lose connectivity?
The device buffers readings locally with timestamps and retries when the link returns, and the platform accepts late data with a flag. The specification must state the buffer duration and which alerts are real-time versus reviewed after reconnection, because those choices change the firmware and platform work.
What is MQTT and why is it used for IoT?
MQTT is a lightweight messaging protocol that keeps a persistent connection between a device and a broker, so many devices can send small messages with low overhead. It suits frequent telemetry from a device fleet, while HTTP is simpler when devices report rarely or must call an existing REST endpoint.
What should an IoT dashboard show first?
The first dashboard should show current asset status, exceptions and silent devices, recent readings per asset, and an alert history with acknowledgement. Specifying one view per role keeps the screen tied to a decision rather than accumulating every available field.
Questions we are asked
What is IoT development and what does it involve?
IoT development is the work of connecting physical assets to software so their status is recorded and acted on without manual reporting. It involves device firmware, a connectivity and message protocol, a platform that stores and rules on the data, and a dashboard or integration that puts the result in front of a person or another system.
How much does an IoT system cost to build?
Cost depends on the number of device types, the protocol and broker choice, the number of dashboard roles, and how many existing systems must be integrated. A specification with one device type, one dashboard role, and one integration point can be quoted as a fixed scope; each additional type or role adds a separate estimate line.
How do you handle devices that lose connectivity?
The device buffers readings locally with timestamps and retries when the link returns, and the platform accepts late data with a flag. The specification must state the buffer duration and which alerts are real-time versus reviewed after reconnection, because those choices change the firmware and platform work.
What is MQTT and why is it used for IoT?
MQTT is a lightweight messaging protocol that keeps a persistent connection between a device and a broker, so many devices can send small messages with low overhead. It suits frequent telemetry from a device fleet, while HTTP is simpler when devices report rarely or must call an existing REST endpoint.
What should an IoT dashboard show first?
The first dashboard should show current asset status, exceptions and silent devices, recent readings per asset, and an alert history with acknowledgement. Specifying one view per role keeps the screen tied to a decision rather than accumulating every available field.
