Key takeaways
- An IoT device needs six separate, deliberate design choices: the microcontroller, the radio and connectivity protocol, the sensors, the cloud backend, the companion app, and the security approach.
- The radio choice has the biggest effect on battery life and real-world range, and the right answer depends on whether you need an existing module or a custom RF design.
- A cloud backend choice is not permanent. Google discontinued its original Cloud IoT Core service in 2023, which is a useful reminder to pick a backend you could migrate away from if you had to.
- Security and certification are not a late-stage checklist. US FCC rules and new EU cybersecurity requirements both affect decisions made early in the design.
Developing an IoT device comes down to a set of specific technical decisions: which microcontroller runs it, which radio connects it, which sensors it reads, where its data lives in the cloud, what the companion app needs to do, and how it is secured. The overall journey from idea to a finished connected product, including feasibility, prototyping and production, is covered separately in the IoT development process. This guide stays on the practical decisions inside that process: what to actually choose, and why.
Choosing the microcontroller
The microcontroller (MCU) sets your power budget before anything else does. A device that runs for months on a small battery and one that plugs into wall power can reasonably use very different chips. Espressif’s own datasheet for the ESP32, a common Wi-Fi-and-Bluetooth MCU, lists deep-sleep current as low as 10 microamps with its RTC timer running, compared to 20 to 68 milliamps in active “modem-sleep” mode depending on clock speed, a gap of roughly three orders of magnitude between sleeping and working. That gap is why the sleep and wake pattern you design matters as much as the chip itself.
- If the device is always plugged in, prioritize processing headroom and peripheral support over sleep current.
- If it runs on a battery, design the firmware around how often and how long it actually needs to be awake, then pick a chip whose sleep current matches that pattern.
- Integrated Wi-Fi-and-Bluetooth MCUs reduce board complexity but are not always the lowest-power option for a pure low-duty-cycle sensor.
Picking a radio and connectivity protocol
Range, power and bandwidth trade off against each other differently for every wireless protocol, so the right choice depends on the product, not a universal ranking. Independent range testing published by Nordic Semiconductor on its own hardware, run outdoors with a one-meter antenna height, found meaningful differences by transmit power and protocol:
| Protocol | Range at 8 dBm transmit power |
|---|---|
| Bluetooth Low Energy (1 Mbps) | 345 meters |
| Bluetooth Low Energy, Long Range coded PHY | 756 meters |
| Thread | 328 meters |
| Zigbee | 280 meters |
For devices that need to reach further than a mesh or local radio can manage, cellular IoT protocols are the alternative. In Nordic’s own field testing, LTE-M held a connection out to 12 kilometers from a base station before dropping it, and NB-IoT held a connection slightly further, to about 14 kilometers, attributed to its narrower 200 kHz channel. Which protocol uses less power depends on distance and network configuration rather than one always winning, so this is a decision to test on your actual target network, not assume from a spec sheet.
At Inventornest, we use an off-the-shelf wireless module when it can meet the product’s requirements, because it reduces development time, initial cost and technical risk, particularly useful when validating a product before committing to production engineering. We consider a custom PCB when a module cannot meet the required dimensions, power consumption, interfaces, performance or production cost, comparing the additional development and validation cost against the expected unit-cost savings over the planned production quantity. Volume alone does not decide this: a low-volume wearable may need a custom board because space is limited, while a higher-volume product may still be well served by an established module. Custom RF work specifically becomes relevant when the required size, antenna arrangement, range, power consumption or production cost cannot be achieved with an available module, and even a pre-certified module does not automatically remove all testing obligations for the finished product.
Sensors: match the sensor to the question you are answering
Sensor selection should start from the specific measurement the product needs, not a generic feature list. Three broad categories cover most IoT products: environmental sensors (temperature, humidity, pressure) for monitoring and compliance; motion and orientation sensors (accelerometer, gyroscope, sometimes a magnetometer) for tracking movement or impact; and biometric sensors (optical heart-rate, SpO2) for wearable health and fitness uses, which typically carry extra regulatory scrutiny. Each type adds its own interface, power draw and firmware complexity on top of the MCU and radio choices above, so sensor selection belongs alongside those choices, not after the board layout is locked.
Where the data lives: choosing a cloud backend
The three major cloud providers currently offer different device-connectivity services, and that has changed before. AWS IoT Core remains Amazon’s managed device-connectivity service, supporting MQTT and HTTPS device connections and fleet management, and Microsoft’s Azure IoT Hub plays the equivalent role for Azure. Google discontinued its original Cloud IoT Core service in August 2023 and did not replace it with a direct equivalent, instead pointing customers toward general-purpose messaging and data-pipeline tools. That history is a practical argument for choosing a cloud architecture you could migrate off of, rather than building firmware so tightly coupled to one vendor’s device-management API that a provider’s future product decision becomes an emergency for you.
The companion app: decide if it needs to exist at all
Every connected feature in an IoT device, including the app that pairs with it, adds power consumption, setup steps, software maintenance and security responsibility that a standalone device does not have. At Inventornest, we advise against adding connectivity when it adds cost and complexity without solving a meaningful problem for the user. A standalone version is often the more appropriate design whenever the product can perform its essential function reliably without an app or a cloud connection, with connected features validated in a later phase instead of the first one.
Security and certification are not a final checklist item
In the United States, radio-emitting devices fall under FCC rules in 47 CFR Part 15, which governs unlicensed intentional and unintentional radiators and requires equipment authorization before a device is marketed. The cost and process of that testing, and which labs are currently recognized to run it, are covered in FCC certification cost and FCC recognized test labs.
Security requirements are also changing. In the European Union, the Cyber Resilience Act (Regulation (EU) 2024/2847) phases in obligations over several years, including incident reporting duties that began applying in September 2026, ahead of full enforcement in December 2027; the text is published on EUR-Lex. In the United States, NIST published revised foundational guidance for IoT manufacturers, NIST IR 8259 Revision 1, in 2026, available from NIST’s own publication page. The FCC’s voluntary US Cyber Trust Mark program had not yet put a labeled product on shelves as of late 2026, after changing its lead administrator earlier in the year. None of this is legal advice; a product headed for EU or US markets should have its certification and compliance scope reviewed by a qualified attorney or the relevant regulator.
Frequently asked questions
What is the first technical decision to make when developing an IoT device?
The power budget, which starts with the microcontroller and the sleep and wake pattern the firmware will use. That decision shapes how much range and bandwidth you can afford from the radio you choose next.
Should I use an off-the-shelf wireless module or design custom RF?
Start with a module if it can meet your size, power and range requirements. Move to custom RF only when a module genuinely cannot meet them, since custom RF adds development time and certification complexity.
Which cloud platform should an IoT device use?
AWS IoT Core and Azure IoT Hub are both currently active managed options. Choose based on your existing infrastructure and team familiarity, and design the firmware so migrating providers later is possible, since vendor IoT offerings have changed before.
Does every IoT device need a mobile app?
An app and a cloud connection should solve a specific problem for the user. A standalone device is often the better starting design whenever the core function works reliably without one.
What certification does an IoT device need in the US?
Most radio-emitting IoT devices need FCC equipment authorization under Part 15. The specific path and cost depend on the device and its radios; consult a qualified test lab or attorney for your specific product.
Is Matter or Thread something I need to support?
It depends on your market. Matter and Thread matter most for devices meant to integrate with consumer smart-home ecosystems; a device aimed at an industrial or single-purpose use case may not need either.
Where Inventornest fits
These six decisions, the MCU, the radio, the sensors, the cloud backend, the app and security, interact with each other, which is why we treat them as one connected design conversation rather than six separate checkboxes. We use an off-the-shelf wireless module when it can meet the requirements, moving to a custom board only when it genuinely cannot, and we advise against adding connectivity that does not solve a real problem for the user. If you are working through these decisions for a connected product, see our IoT product design services and examples of finished devices in our portfolio, or get a quote for your specific device.
