Overview
A modern IoT product is rarely just a board. Somewhere between the sensor and the customer sits a mobile app, a cloud backend, and an API that ties them together, and the decisions made about how hardware and software divide responsibility shape the whole product — power budget, firmware architecture, and the app's responsiveness all trace back to that split. Getting it right means treating hardware and app as one system designed together, not two teams building to a spec handed over the wall.
Where the Line Falls Between Hardware and App
The first design decision is what the device decides on its own versus what it defers to the app or cloud. A device that can operate safely and usefully with no connectivity at all — logging locally, applying basic thresholds, running its core function — is more resilient than one that stalls without a network link, and it also survives a firmware bug in the app without becoming useless. The app and cloud layer is then free to add configuration, historical trends, and alerts on top of that reliable core, rather than being load-bearing for basic functionality.
Connectivity: BLE Pairing Versus Cloud-Connected Wi-Fi
Most connected products built around chips like the ESP32 use two different radios for two different jobs. Bluetooth Low Energy handles local pairing and configuration — provisioning Wi-Fi credentials, setting a device name, doing a firmware update over a short-range, low-power link that doesn't need internet access at all. Wi-Fi then carries the ongoing device-to-cloud connection once the device is provisioned, since it has the bandwidth and range within a building that BLE doesn't. This division of labor is covered in more depth in the ESP32 IoT development guide, and the broader tradeoffs between Wi-Fi, BLE, LoRa, and other protocols are compared in the complete guide to wireless communication protocols for IoT.
Cloud Integration and APIs
The API layer between device and app is worth designing deliberately rather than letting it emerge from whatever the first prototype needed. MQTT is the common choice for the device-to-cloud link because its publish/subscribe model suits frequent, small telemetry updates far better than repeated HTTP polling, and it copes gracefully with intermittent connectivity. The app then talks to the cloud backend over a conventional REST or GraphQL API, which keeps the device firmware simple — it only needs to speak one protocol to one endpoint, while the backend handles fan-out to however many app clients are watching that device's data.
Building the Dashboard and App Experience
The app or dashboard is where most users judge the whole product, even though it may be the smallest part of the engineering effort. Real-time updates need a live connection — typically WebSockets or MQTT-over-WebSocket from the backend — rather than the app polling on a timer, which drains battery and adds latency to something that should feel instant. Historical charts and trend views pull from time-series data the backend has already aggregated, not from raw device telemetry re-processed on every app open. Native Android and iOS development, or a cross-platform framework where the product doesn't need deep platform-specific features, both work well here — the deciding factor is usually how much the app needs to touch device-specific protocols like BLE, where native tooling is often the more predictable choice.
Security Across the Whole Stack
A connected product is a target from the moment it ships, and security has to be designed across hardware, firmware, cloud, and app together — a strong app login in front of a device that trusts any BLE connection without authentication is not a secure product. On the device side, secure boot and flash encryption protect firmware and stored credentials from physical tampering, and TLS should carry every device-to-cloud connection rather than plain MQTT or HTTP. Per-device credentials, provisioned uniquely during manufacturing rather than shared across a product line, limit the blast radius if any single device or its credentials are ever compromised.
Firmware and App Versioning Together
Once a product ships, the app and firmware evolve on different release cycles — app stores approve updates in days, OTA firmware rollouts are usually staged more cautiously — and the API between them needs to tolerate that gap. Versioning the API contract and keeping the app backward-compatible with at least the last one or two firmware versions avoids the common failure mode where an app update breaks older devices still waiting on their OTA rollout, or a firmware update ships a data format the current app release doesn't understand yet.
Testing the Whole System, Not Just the Parts
Hardware bring-up and app development usually run on separate timelines, which means the first time firmware, cloud, and app are tested together is often later than it should be. Standing up a minimal end-to-end path early — one device, one cloud endpoint, one app screen showing live data — surfaces integration problems (timezone mismatches in timestamps, unit conversion errors, connection state that the app assumes but the firmware doesn't report) months before they would otherwise be found, when a full fleet of devices and a finished app make them far more expensive to fix.
How PAK-EL LAB Can Help
PAK-EL LAB builds the full stack for connected products — ESP32 hardware and firmware, cloud integration, and Android/iOS apps — designed together rather than bolted on afterward. If you're planning a connected product, our team can help scope how hardware and app should divide the work.
Related services: ESP32 & UWB Development · Android & iOS App Development