For fleets that have to keep working when nobody is watching
IoT Development Services
A device in a lab connects reliably every time. A device in the field drops connection, loses power and gets updated by nobody standing near it. This practice designs for the field condition from the start, whether the work is a first fleet reaching the cloud, safer updates, or scaling a pilot to production volume.
How a device fleet gets designed for the field
Intermittent connectivity, safe updates and provisioning at real scale.
90 secSample frame · video pending01Before choosing a protocol
MQTT or CoAP is a real decision, not a default.
The protocol choice gets made too early, often before device constraints are understood. Four questions settle it against your actual hardware.
How constrained is the device's power budget?
Extremely low-power devices often favour CoAP's lighter overhead. Devices with more headroom handle MQTT's persistent connection model comfortably.
How reliable does message delivery need to be?
MQTT's quality-of-service levels give stronger delivery guarantees. CoAP trades some of that guarantee for a lighter footprint.
How many devices report at once?
MQTT's publish-subscribe model scales cleanly to large fleets reporting frequently. CoAP suits smaller, more request-driven interactions.
What does your cloud platform already support well?
Most major cloud IoT platforms favour MQTT natively. Matching the platform's strength usually beats a theoretically ideal protocol choice.
| MQTT | CoAP | |
|---|---|---|
| Connection model | Persistent, publish-subscribe | Lightweight, request-response |
| Power overhead | Moderate | Lower |
| Delivery guarantees | Configurable quality of service | Simpler, fewer guarantees |
| Best fit | Large fleets, frequent reporting | Very constrained, occasional reporting |
02Agreed before the first device ships
The ledger that keeps a fleet deployment honest
IoT engagements go wrong when device provisioning is assumed to scale the same way it did for ten test units. This ledger lays out what you bring, what we build, what returns, and what stays yours.
- Your side
You bring
- The device hardware and its power and connectivity constraints
- The data the devices need to send and how often
- Any existing cloud platform this needs to feed
- Our side
We build
- Firmware-to-cloud communication built for intermittent connectivity
- Protocol selection matched to the device's power and bandwidth limits
- Device provisioning designed for fleet scale, not one unit at a time
- Your side
You receive
- A working fleet reporting reliably to the cloud
- A provisioning process ready for production volume
- Monitoring showing device health and connectivity across the fleet
Never leaves you
- Ownership of the hardware and its manufacturing
- The cloud platform and every decision made on its data
- The pace of scaling the fleet further
Where the line sitsIntermittent connectivity is the normal condition here, not the edge case. We design for devices that go offline constantly, not devices that stay perfectly connected.
03From device to production fleet
Four stages, each closing on evidence
Fleets that fail quietly in the field usually skipped a stage here. This system closes each one with something tested against a real connectivity drop.
Fix the protocol against real constraints
Power, bandwidth and message volume are measured against the actual hardware before a protocol is chosen, not assumed from a reference architecture.
Protocol and power budgeted firstDesign provisioning for volume, not one unit
Devices are provisioned through a process built to handle production volume from the start, so scaling the fleet never means rebuilding this step.
Provisioning built for fleet scaleTest against dropped connectivity deliberately
Devices are tested with connectivity deliberately interrupted, because a fleet that only works when perfectly connected will fail in the field regularly.
Failure tested, not just the happy pathBuild OTA updates with a rollback path
Over-the-air updates roll out staged, with a tested rollback path, so a bad update reaches a handful of devices before it reaches the whole fleet.
Updates that can be pushed with confidence
04What actually moves the number
Four drivers, priced from the fleet
IoT work is priced against fleet scale and connectivity conditions, because these four factors change scope by multiples.
Fleet size and expected growth
A pilot fleet of a dozen devices costs less to provision than a system designed to scale to thousands from day one.
Connectivity reliability in the field
Devices operating in genuinely unreliable connectivity conditions require more resilience engineering than devices on stable networks.
Update and rollback complexity
Safe OTA updates with staged rollout and rollback cost more upfront than accepting manual updates, though they save far more later.
Security hardening required for the exposure level
A fleet exposed to public networks needs materially more security work than devices operating on a closed, controlled network.
05Evidence and proof
Fleets that kept reporting when the connection dropped.
IoT proof is a fleet that survived real connectivity conditions at scale. Every record here waits for written client approval before production.
Explore case studiesA device fleet moved from a twelve-unit pilot to production scale.
Nexa Foundry's sensor pilot worked fine at twelve units. Provisioning and monitoring rebuilt for fleet scale carried the same reliability to several hundred devices in production.
- Devices in production
- From 12 to 400+
- Provisioning time per device
- Cut to under a minute
A staged OTA rollout caught a bad update before it reached the fleet.
Tern's tracking devices had no rollback path for a failed update. A staged rollout with tested rollback caught a bad firmware build after five devices, not five hundred.
- Devices affected by the bad update
- 5 of 500+
- Rollback time
- Under one hour
The devices in the field drop connection constantly and the system just handles it now, which it never did before.
Sample · pending client approval
06Read this first
When IoT engineering is the wrong first move
Building fleet-scale provisioning for ten devices that will never grow spends effort on infrastructure nobody needs yet. The exits are marked plainly. Where IoT work is justified, it runs on standard embedded platforms with MQTT, CoAP and major cloud IoT services.
The fleet is small and will likely stay small
A handful of devices reporting occasionally rarely justifies fleet-management infrastructure built for scale it will never reach.
- API development
The need is really a cloud backend, no hardware involved
If there is no physical device to connect, this is a standard application and API problem instead.
- Team extension
You need embedded engineers, not a delivery layer
If your team already owns the firmware and hardware relationship, team extension fits better than a commissioned build.
| Shape | Best when | You direct | We carry |
|---|---|---|---|
| Scoped build | Hardware and fleet size are known | Device roadmap and priorities | Firmware-to-cloud delivery |
| Delivery pod | The fleet will scale with real usage | Product decisions each cycle | Engineering, provisioning, monitoring |
| Team extension | Your leads own the hardware relationship | Architecture and standards | Named engineers and continuity |
07Straight answers
Asked before a fleet deployment is scoped.
01Do you build the firmware, the cloud side, or both?
Both, depending on scope. Firmware-to-cloud reliability is the core discipline here, so the two sides are usually designed together rather than handed to separate teams.
02How do you handle devices that lose connectivity often?
By treating intermittent connectivity as the normal operating condition, not an edge case. Devices queue and retry data rather than assuming a constant connection.
03Can you add safe over-the-air updates to an existing fleet?
Yes, staged rollout and a tested rollback path are the usual starting point, since a failed update on unreachable hardware is a real and costly risk.
04MQTT or CoAP, which should we use?
It depends on device power constraints, message volume and what your cloud platform supports well. The assessment weighs your specific hardware rather than defaulting to one.
05What does IoT development cost?
Priced against fleet size, connectivity conditions and update or security complexity from the assessment. A small, stable fleet costs less than one built to scale into thousands.
06Can you take a pilot fleet to production scale?
Yes, provisioning and security are usually rebuilt for production exposure rather than simply extended from pilot conditions, which tolerate more than production should.
07How do you secure constrained devices that cannot run heavy security software?
Through protocol-level security and provisioning discipline suited to constrained hardware, rather than assuming a full security stack a small device cannot actually run.
08Do you build the dashboard and analytics on top of the device data?
Yes, when needed. Data and cloud engineering share this practice's delivery discipline, so fleet data rarely needs a separate vendor to become useful.