IoT software development at scale

Ten thousand devices is the number where most IoT teams discover their backend was never built for the job. The firmware team hits its milestones. The cloud team ships a pilot. Then the fleet grows, telemetry volume triples, and the whole platform gets rewritten under duress.

This is the pilot to production cliff, and it is the defining problem of serious iot software development. It is not a firmware problem, it is not a cloud problem, it is an architecture and seniority problem. Below is how we approach it at Devspace, drawing on the micro-mobility and connected fleet work our engineers ship every week.

What is IoT development?

IoT development is the practice of building software that spans embedded firmware on a physical device, the network transport that carries its data, the cloud platform that ingests and processes that data, and the applications that expose it to operators and end users. Real IoT software development couples all four layers so a fleet of thousands of devices behaves as one product, not four.

The skill gap most teams underestimate is the seam between them. Firmware engineers who have never operated a backend at scale make choices that cripple the platform. Backend engineers who have never debugged a device on a workbench make assumptions that brick fleets.

IoT application development at scale

A working prototype with fifty devices tells you almost nothing about what production looks like. At fifty devices you can afford chatty telemetry, synchronous API calls, and a single Postgres instance. At fifty thousand you cannot.

The patterns that survive scale are unglamorous. Batched telemetry with backpressure. Event driven ingestion behind a broker, not HTTP endpoints hitting your API gateway directly. A time series store for device data separated from the transactional database that runs your business logic. Idempotent command delivery, because devices will receive the same instruction twice and you need them to do the right thing.

Teams that skip these decisions during the pilot pay for them twice, first in the rewrite and again in the customer trust lost while the rewrite is happening.

Building a reliable IoT architecture

A defensible IoT architecture has four properties that are easy to state and hard to build.

Decoupled ingestion

Devices publish to a broker, MQTT or similar, and the broker fans out to consumers. This lets you scale ingestion independently of processing, replay traffic during incidents, and add new consumers without touching device firmware.

Stateful device shadows

Each device has a canonical state representation in the cloud, updated by both the device and the operator. This is the seam where firmware and backend engineers must agree on a schema, versioning, and conflict resolution. Get it wrong and every feature ships with a subtle race condition.

Observability at the device level

You need to know that a specific scooter in Lisbon is rebooting twice an hour before the operations team files a ticket. iot device monitoring is not a dashboard, it is a pipeline: structured device logs, health metrics, and alerting keyed to fleet cohorts rather than individual serial numbers.

A remote intervention path

When a device misbehaves, you need to update it, reconfigure it, or take it out of rotation without a truck roll. This is where OTA lives, and it is the single highest leverage capability in the entire stack.

OTA software update strategies

An ota software update pipeline is where careers are made and fleets are bricked. The rules we hold engineers to on connected fleet work:

1. Staged rollouts by cohort, never fleet wide. Start with one percent, watch the health metrics, then ramp.
2. Signed images with verified boot. Every image the device runs must be cryptographically verified against a key the device trusts.
3. A/B partitions and automatic rollback. If the new image fails to boot or fails a post boot health check, the device reverts to the previous image without operator intervention.
4. Bandwidth aware scheduling. A cargo bike on a cellular link is not a scooter on wifi in a warehouse. The update client must respect the link.
5. Delta updates once your images grow past a few megabytes, because you are paying for every byte across the fleet.

Most teams get one or two of these right during the pilot. The remaining three are what turn a pilot into a product.

IoT device management and fleet orchestration

iot device management is the operator facing layer that sits on top of the architecture. Provisioning, commissioning, decommissioning, grouping, tagging, remote diagnostics, firmware campaign management. This is where iot fleet management becomes a business capability rather than an engineering artifact.

The mistake we see repeatedly is treating this layer as a set of admin tools bolted on late. It is not. The provisioning flow determines your unit economics, the diagnostics tools determine your support cost per device, and the campaign management surface determines how fast you can respond to a security incident. These are product decisions and they need product ownership.

From pilot to production: IoT platform development

The transition from pilot to production is where most iot platform development efforts stumble. The pilot team was optimised for shipping a demo. The production team needs to be optimised for reliability, cost, and rate of change.

A short checklist we use with clients making the jump:

• Can you deploy a firmware update to a single device, a cohort, and the full fleet, with the same tooling?
• Do you have a rollback path that does not require operator action?
• Is your telemetry pipeline decoupled from your API tier?
• Can you provision a new device without a human touching a database?
• Do you have a per device cost model, and does it hold at ten times your current fleet size?

If the answer to any of these is no, you are still in pilot regardless of how many devices are in the field.

Embedded software development beyond firmware

Embedded software development is the discipline that makes all of this real, but it is misnamed. The engineers who thrive on connected products are not pure firmware engineers, they are systems engineers who happen to write firmware. They understand the backend contract, the OTA state machine, the observability pipeline, and the operational cost of every design choice.

This is the profile Devspace sources for connected product work. Our engineers are pre vetted for seniority and embedded directly into the client’s team, stack, and sprint, typically within two to four weeks. That includes our remote development team engagements and, where the leadership gap is the bottleneck, a Fractional CTO who has shipped connected fleets before and can own the roadmap through the pilot to production transition.

The takeaway

IoT software development is a systems problem, not a firmware problem. The teams that ship durable products treat the device, the transport, the platform, and the operator tools as one product with one architecture. The teams that treat them as four separate workstreams write the backend twice and lose eighteen months.

If you are approaching the pilot to production cliff, the highest leverage decision is who is at the table when the architecture is set. Senior engineers with connected fleet scars save you the rewrite. Everything else is downstream of that.