Building an IoT device is fundamentally different from building a software product. It requires hardware and firmware expertise, knowledge of wireless protocols, an understanding of manufacturing processes, and the patience to deal with physical constraints that can’t be debugged by reading a stack trace. At the same time, the tools and platforms available in 2026 have never been more capable — a skilled team can move from concept to a production-ready connected device in 6–18 months depending on complexity. This guide walks through the complete development journey, stage by stage, so you know what’s coming and can plan accordingly.
Stage 1: Define Requirements Before You Touch a Schematic
The most costly mistakes in IoT hardware development happen before any hardware is ordered — they happen when requirements are underspecified or wrong assumptions go unchallenged. Before designing anything:
Define the core sensing/actuation requirements:
- What does the device measure or control?
- What accuracy and resolution are required?
- What sampling rate is needed?
- What environmental conditions will it operate in (temperature range, humidity, dust, chemical exposure)?
Define connectivity requirements:
- What data must be transmitted, and how often?
- What is the acceptable latency for commands?
- What connectivity infrastructure exists at the deployment site?
- Must the device function without cloud connectivity?
Define power requirements:
- Is the device mains-powered, battery-powered, or energy-harvesting?
- If battery, what target lifetime? (This is often the most constraining requirement)
- What battery chemistry and form factor are acceptable?
Define physical requirements:
- What are the dimensions and form factor constraints?
- What regulatory certifications are needed (FCC, CE, UL, ATEX)?
- What is the target cost (BOM + manufacturing)?
- What quantity will be produced (affects make vs. buy decisions for modules)?
Write these requirements down. Review them with stakeholders. Misaligned expectations between the development team and product/business teams are the most common cause of IoT project delays.
Stage 2: System Architecture and Technology Selection
With clear requirements, select the technology building blocks:
MCU/SoC selection: Match the MCU to the computational and connectivity requirements. The ESP32-S3 is an excellent choice for Wi-Fi+BLE products; Nordic’s nRF52840 for BLE-only products needing low power; nRF9160 for cellular IoT; STM32L4+ for ultra-low-power with flexible connectivity options.
Connectivity selection: Apply the protocol decision framework from our IoT protocols guide. At this stage, decide the primary connectivity technology and any secondary fallback.
Sensor selection: Evaluate candidate sensors against your accuracy, resolution, and environmental requirements. Request samples and evaluate them on a development board before committing to a design.
Cloud platform selection: Select the cloud platform (AWS IoT Core, Azure IoT Hub, custom MQTT broker) early, as it influences device-side SDK choices and OTA update architecture.
Security architecture: Define the security model now — will you use a secure element for key storage? How will devices be provisioned? What is the OTA update chain of trust? See the IoT Security Foundation guidelines for comprehensive security architecture guidance.
Stage 3: Proof of Concept on Development Hardware
Before designing custom hardware, validate your concept on off-the-shelf development boards. This is not optional — it catches fundamental feasibility issues when they’re cheap to fix.
Set up your development environment:
- Install the appropriate SDK (ESP-IDF for ESP32, nRF Connect SDK for Nordic, STM32CubeIDE for STM32)
- Configure a version control repository from day one
- Set up a CI pipeline even at this early stage — it instills good habits
Build the minimum viable firmware:
- Read the target sensors and verify the data matches expectations
- Implement the connectivity stack and connect to your cloud platform
- Validate that the communication protocol works end-to-end
- Measure power consumption in different states to validate against battery life targets
Identify risks: What assumptions turned out to be wrong? What’s harder than expected? Document these — they’ll inform the hardware design and schedule.
Development board resources:
- Arduino Uno/Nano for simple sensor prototyping
- ESP32-DevKit for Wi-Fi/BLE connected prototyping
- Nordic DK series for BLE or cellular prototyping
- Raspberry Pi for gateway prototyping
Stage 4: Schematic Design and PCB Layout
Once the concept is validated, design the custom hardware:
Schematic design:
- Follow MCU reference designs from the vendor’s datasheet and application notes
- Apply proper decoupling capacitors on every power pin (vendor recommendations are not optional)
- Include debug interfaces (JTAG/SWD, UART debug port) — you’ll need them
- Add test points for critical signals
- Design the power supply carefully — LDO vs. switching regulator choice affects efficiency and noise
PCB layout — wireless devices require special attention:
- Antenna placement is critical. Most RF module datasheets specify an exclusion zone (keepout area) where no copper should appear near the antenna. Violating this degrades RF performance severely. See our detailed guide on IoT PCB design tips.
- RF trace impedance: The transmission line from SoC to antenna must be 50Ω. Microstrip width depends on the PCB stackup — calculate it correctly or measure it.
- Ground plane: Solid, uninterrupted ground planes under RF circuits are critical for RF performance and EMC
- Power plane separation: Isolate noisy switching regulators from sensitive RF and analog circuits
Design review: Before sending gerbers to the PCB fab, conduct a peer design review. Have another engineer review the schematic for errors and the layout for RF, power, and signal integrity issues. This is time well spent.
PCB fabrication and assembly: For prototypes, low-volume PCB fabs like OSH Park, JLCPCB, or PCBWay offer fast turnaround. Use JLCPCB or PCBWay’s PCBA (PCB assembly) service to assemble SMD components — hand-soldering BGA or fine-pitch QFN packages invites reliability problems.
Stage 5: Engineering Validation Test (EVT)
First custom PCBs are your Engineering Validation Test units. EVT is about answering the question: “Does the hardware fundamentally work?”
EVT activities:
- Bring-up: Power on the board for the first time — often called “first light.” Verify power rails are at correct voltages before connecting the MCU.
- Firmware bring-up: Establish basic MCU communication (debug UART or SWD). Flash initial firmware.
- Peripheral validation: Verify each peripheral works as designed — sensors communicate, radio transmits, ADC channels measure correctly.
- Power consumption measurement: Measure active and sleep currents and compare to design targets. This is where power budget mistakes become visible.
- RF performance measurement: Verify antenna performance with a spectrum analyzer or by measuring link budget in realistic scenarios.
EVT typically uncovers issues — this is normal. Common EVT bugs:
- Power supply noise affecting ADC readings
- Antenna placement errors degrading RF performance by 3–6 dB
- PCB layout errors (missing vias, incorrect trace widths, silkscreen blocking pads)
- Incorrect component values (pull-up/pull-down resistors, crystal load capacitors)
Document all EVT issues and prepare a list of changes for the DVT revision.
Stage 6: Firmware Development (Parallel with Hardware)
While hardware iterations proceed, firmware development is underway in parallel. Key firmware development workstreams:
Application firmware:
- Sensor drivers and calibration
- Data processing and local logic
- State machine design (idle, active, alarm, low-battery, OTA states)
- Error handling and recovery from all foreseeable failure conditions
Connectivity firmware:
- Protocol stack integration (MQTT client, TLS configuration)
- Connection management (connect, reconnect, backoff, offline buffering)
- Message serialization
Security firmware:
- Secure boot implementation (if required)
- Certificate/key provisioning workflow
- Cryptographic operations (signing, verification, encryption)
OTA update firmware:
- Bootloader with A/B partition scheme
- Update download, verification, and swap logic
- Rollback capability if the new firmware fails to start
Testing: Write unit tests for pure-logic firmware components from the start. Hardware-in-the-loop testing (HIL) using the EVT/DVT boards validates the integrated firmware in a hardware environment. See our article on IoT testing strategies for a comprehensive approach.
Stage 7: Design Validation Test (DVT)
The DVT revision incorporates EVT fixes and prepares for pre-compliance testing and final validation.
DVT activities:
- Verify all EVT issues are resolved
- EMC pre-compliance testing (conducted with a pre-compliance test house or lab)
- Environmental testing if required: thermal cycling, humidity, vibration
- Battery life testing — long-duration tests measuring actual battery drain
- User experience testing — if there’s a mechanical enclosure and UI, evaluate it with real users
Regulatory pre-compliance: Before formal regulatory testing (FCC, CE, etc.), pre-compliance testing catches issues cheaply. Formal regulatory testing at an accredited lab is expensive and time-consuming — you don’t want to fail and need another PCB spin.
Stage 8: Production Validation Test (PVT) and Manufacturing
PVT is the final manufacturing validation before mass production:
- Boards are built on the actual production line, with production tooling
- All production test fixtures are validated
- The firmware programming and configuration workflow is validated
- Yield is measured — what percentage of boards pass production testing?
- All certifications (FCC, CE, UL) are obtained from accredited test labs
Manufacturing test (ICT and functional test):
- In-Circuit Test (ICT) verifies all components are correctly placed and soldered
- Functional test validates the assembled board works correctly before shipment
- Firmware programming: verify the production firmware flashing workflow, including any security credential provisioning
Certification: Final FCC ID and CE mark certifications are obtained. These are typically obtained on production-representative DVT or PVT units.
At UABit, we guide clients through this complete development journey. Our IoT consulting and prototyping services help teams navigate hardware and firmware development efficiently.
Common Mistakes That Kill IoT Projects
Underestimating power consumption: Battery life estimates based on datasheet typical values rather than actual measured consumption in the complete firmware context are almost always optimistic. Measure early and often.
Ignoring RF performance: An IoT device that can’t maintain a reliable wireless connection in its deployment environment is unusable. Test in realistic environments, not just in the lab.
Skipping OTA updates: Shipping firmware that can’t be updated in the field means every bug requires physical access or product recalls. OTA must be designed in from the start.
Insufficient testing before production: Rushing to production to meet a launch date is tempting but risky. A single firmware bug or hardware issue discovered after shipping 10,000 units is far more expensive than the delay would have been.
Conclusion
Building an IoT device is a multi-disciplinary engineering challenge that spans requirements definition, hardware design, firmware development, cloud integration, regulatory compliance, and manufacturing. Each stage builds on the previous one, and mistakes made early compound through the development process. Understanding this journey before you start — knowing what to expect at each stage and where the common pitfalls lie — is the best preparation for a successful IoT product launch.
Further reading:
- Espressif ESP-IDF getting started guide — comprehensive ESP32 development
- Nordic nRF Connect SDK — nRF52/nRF9160 development environment
- Hackster.io project examples — IoT device project inspiration and tutorials
- Embedded.com development process articles — professional embedded development guidance
- OSH Park PCB prototyping — US-based PCB fabrication for prototypes
- ARM developer resources — Cortex-M development documentation
IoT & AIoT Weekly
Get the best IoT development content delivered weekly. No noise, just signal.