Building a connected device means joining hardware, firmware, connectivity, power management, and security into one system that can survive the real world. The practical answer to how to make iot devices is less about wiring a board and more about making reliable choices early: the right microcontroller, the right radio, the right provisioning flow, and the right update strategy. In the UK, that also means keeping an eye on consumer security rules if the product is going to market.
The shortest path from idea to a reliable connected device
- Start with the use case, environment, and power source before choosing any hardware.
- For most first builds, a microcontroller is cheaper, simpler, and lower power than a Linux-based board.
- MQTT, unique device credentials, and signed OTA updates are the backbone of a solid IoT stack.
- UK consumer devices sold at scale must meet baseline security requirements, including no universal default passwords.
- A small pilot run will expose power, RF, and support problems that a bench prototype hides.
Start with the job the device must do before you choose parts
I start every IoT project by forcing the problem into one sentence. What is the device sensing or controlling, where will it live, how often does it need to talk, and who will maintain it after launch? If those answers are fuzzy, the hardware will be fuzzy too.
This matters because the same board can be brilliant for one product and wrong for another. A battery sensor in a warehouse, a thermostat in a London flat, and a camera in a retail store all need different trade-offs. Power budget, enclosure size, radio range, latency, and maintenance effort should shape the design long before the first PCB is ordered.
- Environment - indoor, outdoor, dusty, damp, hot, cold, or vibration-heavy.
- Power - mains, battery, solar, or energy harvesting.
- Data pattern - occasional readings, continuous telemetry, or event-driven alerts.
- Response time - can the cloud be slow, or does the device need a local response?
- Maintenance - who updates firmware, replaces batteries, and handles failures?
When I am clear on those constraints, the rest of the build becomes a sequence of decisions instead of a pile of guesses. That is what keeps the project from drifting into an expensive prototype that never hardens into a product.
Choose the compute and connectivity stack that fits the job
The biggest early decision is whether you need a microcontroller or a single-board computer. A microcontroller, or MCU, is the better fit when the device is mostly reading sensors, driving actuators, and sending small packets of data. A single-board computer, or SBC, makes sense when you need Linux, a camera pipeline, a local database, or heavier app logic.
| Option | Best for | Strengths | Trade-offs |
|---|---|---|---|
| MCU | Battery devices, simple sensors, compact products | Low power, fast boot, low cost, easier to keep stable | Less memory, fewer software comforts, more care needed for complex apps |
| SBC | Cameras, local analytics, rich UI, container-based software | Flexible software stack, easier development for full apps | Higher power draw, longer boot times, more maintenance and storage wear |
For a first connected sensor, I usually prefer an MCU unless there is a strong reason not to. It keeps the power budget honest and forces the design to stay lean. If you need video, local AI, or a browser-based interface on the device itself, the SBC becomes the practical choice.
Read Also: IoT Principles - Build Trustworthy Connected Products
Pick the radio for the environment
The connectivity layer should match the way the device will actually be used, not the way it looks in a demo.
| Radio | Best for | Strengths | Limits |
|---|---|---|---|
| Wi-Fi | Mains-powered products, home and office devices | Cheap, familiar, high bandwidth | Power hungry, depends on local network quality |
| BLE | Phone-paired devices, short-range accessories | Low power, simple mobile pairing | Short range, limited throughput |
| Cellular | Remote assets, trackers, infrastructure monitoring | Wide coverage, no local gateway required | SIM management, recurring cost, stronger power demand |
| LoRaWAN | Sparse telemetry over long distances | Excellent range and low power | Low bandwidth, needs gateway planning |
My rule is simple: if the device sends tiny amounts of data and runs on a battery, choose the lowest-power path that still meets range requirements. If you pick the wrong radio, the rest of the stack spends its life compensating for that mistake.
Build the first hardware prototype on a dev board, not a custom PCB
There is a reason so many successful products begin on a dev board. It lets you prove the sensing path, the radio, the power budget, and the software flow before you commit to silicon and tooling. I try to keep the first prototype ugly but truthful.
The minimum useful prototype usually includes a board, one sensor, the correct power input, and the simplest physical wiring that still resembles the final device. Add level shifting if the sensor and MCU speak different voltages, measure current draw early, and think about antenna placement before you hide the electronics in a box.
- Power path - battery protection, regulator choice, and sleep behavior.
- Sensor path - signal conditioning, calibration, and noise filtering.
- Physical layout - cable strain relief, antenna clearance, and enclosure fit.
- Manufacturability - test points, serial numbers, and programming access.
I avoid custom PCB work until the firmware and data flow are stable. Otherwise you end up freezing a bad assumption into fiberglass and paying for it twice.
Write firmware that behaves well when networks fail
Firmware is where IoT projects either become dependable or annoying. A good device should boot predictably, recover from bad inputs, buffer data when the network drops, and update itself without forcing a truck roll. If the cloud is unavailable, the device should still do the local job it was built for.
In practice, I look for a few non-negotiables: a clear boot sequence, a watchdog timer, state-based logic instead of tangled loops, and a secure over-the-air update path. NIST's recent work on IoT securability treats update validation, rollback, and strong identity checks as part of robustness, which matches what I see in real deployments. A device that cannot validate an update or return to a known-good version is a liability, not a product.
- Buffer locally when connectivity is patchy, then upload in batches.
- Filter noisy readings so you do not flood the backend with junk.
- Version your settings so new firmware can read older configs safely.
- Sign updates and verify them before install.
- Support rollback so a failed update does not brick the device.
The quiet lesson here is that reliability is mostly about handling the messy 10 percent, not the happy-path 90 percent. Once the firmware can survive interruptions, the cloud layer becomes much easier to trust.
Design the data path before you ship the enclosure
IoT devices are not just hardware. They are hardware plus a message flow. I usually define the backend before the casing, because the data model affects what the device sends, how often it sends it, and how much state it needs to keep locally.
MQTT remains a strong default for lightweight device messaging because it fits small payloads and publish-subscribe patterns well. A clean topic structure, a clear device identity, and a limited set of message types will save you a lot of debugging later. If you use device shadows or a digital twin, use them for actual state reconciliation, not as a way to avoid thinking about state on the device.
| Architecture | Best for | Why it works | When I would avoid it |
|---|---|---|---|
| Direct to cloud | Simple sensors and controls | Fast to build, fewer moving parts | When local resilience or privacy matters more |
| Gateway-based | BLE, Zigbee, or mixed-device environments | Good for local aggregation and protocol translation | When you want the simplest possible field deployment |
| Edge-first | Low-latency control, privacy-sensitive systems | Keeps critical decisions local | When the product does not justify the added software load |
Provisioning deserves the same attention as telemetry. Unique device credentials, per-device policies, and a repeatable manufacturing flow are what keep a fleet manageable. I prefer a process where each device leaves production with its own identity, not a shared secret copied across thousands of units.
Make security and UK compliance part of the spec
If the device will be sold to UK consumers, security is not an optional polish layer. GOV.UK guidance for consumer connectable products makes the baseline clear: no universal default passwords, a public way to report security issues, and a published minimum security update period. That is the floor, not the ceiling.
In product terms, that means security starts in the BOM and the provisioning flow. Use unique credentials per device, store secrets securely, sign firmware, and build a support path for vulnerabilities before launch. If you wait until the first incident, you are already behind.
| Security requirement | What it means in practice |
|---|---|
| No universal default passwords | Ship unique credentials or user-defined setup, never one shared password across the fleet. |
| Vulnerability reporting | Publish a clear contact route and triage process for security issues. |
| Update support period | State how long firmware updates will be provided and make that support real. |
| Secure onboarding | Provision devices with unique identity, controlled pairing, and authenticated first use. |
| Update integrity | Verify signatures, block tampered images, and keep rollback available. |
If the product is industrial or internal rather than consumer-facing, the UK consumer regime may not apply in the same way, but the controls still matter. NIST's IoT guidance points in the same direction: secure onboarding and lifecycle management are part of building a product people can trust, not a bolt-on for later.
Test like the device will be installed badly
Bench testing is useful, but it is not enough. Real devices live in bad Wi-Fi, noisy power, cramped enclosures, and imperfect installations. I like to test for power loss, network loss, sensor drift, and enclosure effects before I ever call a build stable.
A practical test plan usually includes a 24 to 72 hour soak test, repeated reconnect cycles, brownout checks, OTA update retries, and a small pilot of real units in the field. Five to twenty devices is often enough to reveal the failure modes that a lab hides. If the radio works on your desk but fails inside a metal cupboard or behind a boiler, the enclosure is part of the RF design whether you planned for it or not.
- Power - cold starts, battery dips, and abrupt outages.
- Connectivity - weak signal, AP reboots, roaming, and broker downtime.
- Environment - temperature swings, humidity, dust, and vibration.
- Manufacturing - flashing, calibration, and serial-number tracking.
- Field support - logs, diagnostics, and remote recovery.
The right test strategy does not just find bugs. It tells you which assumptions were unrealistic, which is usually the more useful lesson.
The lean build path I would use in 2026
If I were building a first product from scratch, I would keep the path brutally narrow: one MCU board, one sensor, one radio, one backend, and one secure update mechanism. That is enough to prove the system without drowning in options.
- Define one user problem and one success metric.
- Choose the simplest MCU and radio that fit the power and range requirements.
- Prove the sensor reading and power budget on a dev board.
- Add MQTT or an equivalent publish-subscribe path with unique device identity.
- Build signed OTA updates with rollback before you think about scale.
- Pilot with real users, then fix the support and provisioning flow.
The shortest route to a good IoT product is not a flashy one. It is a disciplined one: start with the use case, keep the hardware lean, make the firmware resilient, and treat security as part of the architecture from the first prototype onward. If you do that, the device is far more likely to survive past the demo and into the field where it has to earn its keep.
