When is Bluetooth LE enough for a connected product?

When the data is small and the phone is present: sensor readings, controls, notifications. BLE sips power, pairs cheaply, and needs no infrastructure — the phone bridges to the internet.

What does Wi-Fi add that BLE cannot?

Standalone connectivity: the device talks to the cloud without any phone, enabling remote access, streaming and over-the-air updates at real bandwidth. The costs are power, cost per unit and a household setup ritual.

When do products ship with both radios?

When the product must work standalone for some duties (streaming, cloud voice, remote access) and lean on the phone for others (setup, control, small data). Dual stacks are common in cameras, robots and audio — the design work is deciding which radio owns which job.

Choosing a wireless stack for connected hardware: Wi-Fi, Bluetooth or both

The radio decision looks like a connectivity checkbox and functions like a product definition. It reaches into the bill of materials, the battery budget, the app architecture and the privacy story — and reversing it after tooling costs a redesign. Choosing between Wi-Fi, Bluetooth LE and dual-stack designs is worth its own deliberate conversation before the first schematic.

Bluetooth LE: the phone is the network

BLE is the low-power default for products that live next to a phone. Sensor data, controls, notifications and firmware updates through the phone — all fit comfortably in BLE’s bandwidth, at a power draw that battery products can afford for years. It pairs cheaply, needs no household infrastructure, and its setup ritual is short. What it cannot do is stand alone: no phone nearby means no cloud, no remote access and no streaming. Products whose duties end at the phone — wearables, sensors, toys controlled by an app — are BLE products, and pretending otherwise adds cost without adding capability.

Wi-Fi: standalone, at a price

Wi-Fi gives the product its own voice to the cloud: remote access from anywhere, real bandwidth for audio and video, and OTA updates that do not depend on anyone opening an app. The costs are structural — higher unit cost for the radio and its power circuitry, a battery budget that changes shape, and the household setup ritual that every Wi-Fi product must survive (the moment of typing a network password into a toy is a UX event that deserves design). Wi-Fi belongs to products with duties the phone cannot carry: cameras, speakers, robots that answer from anywhere.

The dual-stack reality

Many shipped products run both: BLE for setup, control and small data; Wi-Fi for the standalone duties. This is not indecision — it is a division of labour, and the design work is drawing the line: which radio owns which job. Getting the line right keeps the BLE path fast and low-power while the Wi-Fi path stays reserved for work that needs it. Getting it wrong produces a product where every action wakes the wrong radio and the battery pays for the confusion.

The decision questions

Three questions settle the stack. Does the product need to work when the phone is not there? Does its data fit in BLE’s bandwidth, or does audio or video demand Wi-Fi? And who sets the product up — a household comfortable with Wi-Fi provisioning, or a user who expects a tap-to-pair? Honest answers point at a stack; the stack then points at a silicon tier, a battery size and an app architecture, which is why the radio decision belongs before the schematic, not during it.

We design connected hardware across all three stacks — BLE, Wi-Fi and dual-radio — and put the decision in the first architecture conversation. The ODM page describes how we run development, or contact us with your product’s duties and we will recommend the stack that carries them.