How We Build IoT Networks for Business and Cities

It Starts With a Question, Not a Device

Most IoT projects don't begin with sensors, gateways, or a shiny cloud dashboard. They begin with a question the business is quietly nervous about: "Will this actually work at scale?" Connecting fifty devices on a desk is a weekend project. Connecting fifty thousand devices spread across a city, a logistics network, or a utility grid is a different discipline entirely. At that point you are no longer building a gadget — you are building infrastructure, and infrastructure carries responsibility.

At OneDev we work with businesses and public-sector teams in Uzbekistan who need IoT not as a demo, but as a system they will depend on for years. This article walks through how we actually think about and build IoT networks: the architecture decisions, the trade-offs, the common mistakes, and the practical questions you should be asking before you buy a single device.

The Real Cost of "It Worked in the Pilot"

The most expensive phrase in IoT is "it worked in the pilot." A pilot of 50 devices hides almost every problem that matters at scale. Network congestion, firmware update logistics, battery drift, certificate expiry, data storage growth, and operational support all stay invisible when the numbers are small. Then the rollout multiplies everything by a thousand, and the cracks appear all at once.

Scale changes the nature of the problem in three ways. First, statistics turn into certainties: a 0.1% device failure rate is one device in a pilot, but fifty failures every day across a 50,000-device fleet — each one a potential support ticket. Second, manual processes break: you cannot SSH into devices or flash firmware by hand at scale. Third, the network itself becomes the bottleneck: bandwidth, message brokers, and databases that shrugged off a pilot start to buckle.

Architecture: The Four Layers We Always Define

Whatever the use case — smart metering, fleet tracking, building automation, environmental monitoring — we structure every IoT network around four clear layers. Keeping them separate is what lets you change one part without rebuilding the whole system.

• Device layer. The physical sensors and actuators, their firmware, and their local logic. This is where power budget, security keys, and over-the-air (OTA) update capability are decided. A device without a reliable OTA mechanism is a liability the day after it ships.
• Connectivity layer. How data leaves the device — cellular (LTE-M, NB-IoT, 4G), LoRaWAN, Wi-Fi, Ethernet, or a mix. This layer determines latency, cost per device per month, and coverage in the physical locations where devices actually live.
• Platform / ingestion layer. The message broker (typically MQTT), the device registry, authentication, and the pipeline that validates and routes incoming data. This is the heart of the system and the part most often under-engineered.
• Application layer. Dashboards, alerts, analytics, billing, and integration with the customer's ERP, GIS, or government systems. This is what stakeholders see — and it should be the last thing you design, not the first.

The discipline here is that data flows in one direction through clean interfaces. When the application team wants a new report, they query the platform — they never reach down to a device. When a device vendor changes, only the device layer is touched. This separation is unglamorous, and it is exactly what keeps a 50,000-device network maintainable.

Connectivity: Choosing the Right Network for the Job

There is no universal "best" connectivity for IoT — only the right fit for a given deployment. The choice depends on three variables: how much data each device sends, how often, and where it physically sits. Getting this wrong is costly because connectivity is a recurring monthly expense multiplied across the whole fleet, and migrating later means touching every device.

In practice, many real networks are hybrid: cellular for remote nodes, LoRaWAN for clustered zones, and wired links for fixed control points — all converging on the same platform. For projects in Uzbekistan specifically, we always validate operator coverage and NB-IoT availability at the actual installation sites before committing, because nationwide coverage maps and on-the-ground reality are not always the same thing.

The Platform Layer Is Where Projects Live or Die

If there is one place to invest engineering rigor, it is the ingestion and platform layer. This is where tens of thousands of devices connect, authenticate, and stream data continuously. We build this layer around a few non-negotiable principles.

• Every device has a unique identity and credentials. No shared keys. Each device authenticates individually so that a single compromised or decommissioned unit can be revoked without touching the rest of the fleet.
• The broker is sized for concurrency, not throughput alone. Fifty thousand devices holding persistent MQTT connections is a connection-count problem before it is a bandwidth problem. We plan broker clustering and connection limits from day one.
• Ingestion is decoupled from processing. Devices write to a queue; processing happens asynchronously. A spike in incoming data must never block devices from connecting, and a slow analytics query must never back-pressure the network.
• Data is validated at the edge of the platform. Devices in the field send malformed, out-of-range, or stale data — clocks drift, sensors fail gradually, firmware has bugs. The platform must treat every incoming message as untrusted and validate it before it reaches storage or dashboards.

Security and Operations: The Part Nobody Demos

Security in IoT is not a feature you add later — it is structural, because a deployed device is a physical attack surface sitting in the field for years. Beyond per-device credentials, three things matter: encrypted transport (TLS) for every connection, a credential and certificate lifecycle (certificates expire — you need a rotation plan before they do), and a clear decommissioning process so retired or stolen devices lose access immediately.

Equally important, and equally ignored in early planning, is day-two operations. A live IoT network needs answers to ordinary but relentless questions: How do we know a device went silent? How do we push a firmware fix to 50,000 units safely and in stages? Who gets paged when ingestion stops? How do we tell a real outage from a few flaky devices? We build monitoring of the fleet's health — connection rates, message gaps, error ratios — as a first-class part of the system, not an afterthought. A network you cannot observe is a network you cannot run.

How We Approach a New IoT Project

Our process is deliberately front-loaded. Before we write code or buy hardware, we define the target scale, the data each device produces, the physical environment, the connectivity coverage at real sites, and the integration points with existing business or government systems. From there we design the four layers, build a pilot on the production stack, and prove the hard parts — OTA updates, security revocation, fleet monitoring, and ingestion under load — while the numbers are still small enough to fix cheaply. Only then do we scale the rollout in controlled stages, watching fleet health at every step.