Wi-Fi provisioning is the process by which your app hands a new device the network name and password it needs to get online, using a temporary side channel — usually Bluetooth Low Energy or an access point the device broadcasts itself — because the device is not yet on any network and typically has no screen or keyboard. It sounds like a minor technical detail. In reality it is where connected products lose users: if a customer cannot get the device onto their home network within about two minutes, they call support, leave a one-star review, or return the product. At Projects House we treat onboarding as a full development component with its own specification, tests, and budget, not something handled in the last week before launch.

The problem you are actually solving

The difficulty comes from a small paradox. To receive credentials, the device needs a communication channel; at that moment it has no network connection. Most compact products also lack a display and keypad, so the user cannot type anything into them directly. The answer is always a temporary intermediate channel through which the app transfers the network details. Which channel you choose affects hardware cost, current consumption, and field success rate, so it should be decided together with the product's wireless architecture rather than left to the software team as an afterthought — the same reasoning behind selecting a wireless-capable microcontroller early.

Three common provisioning methods

SoftAP

The device broadcasts its own temporary Wi-Fi network. The phone joins it, the app sends the home network credentials, and the device connects and shuts the temporary network down. The advantage is that it needs no additional hardware — the Wi-Fi radio you already have does the job. The disadvantage is user experience: on some mobile operating systems the user must leave your app, open system settings, and pick a network manually. That handoff is a well-known drop-off point.

BLE provisioning

The app connects to the device over Bluetooth Low Energy and transfers credentials without ever disconnecting the phone from the internet. This is the smoothest experience available and it is what most polished consumer products use. It requires a chip supporting both radios, and it requires a properly designed BLE service and app layer — the effort involved is discussed in our overview of BLE app development cost, and the implementation side in using React Native with BLE.

Optical and acoustic methods

Displaying a flashing QR code on the phone screen, or encoding data in sound. These suit products that already have a camera or microphone and are uncommon in simple consumer devices.

Mature products frequently implement two methods: a primary path and a fallback. The additional development cost is modest, and it rescues a substantial share of the cases where the first attempt fails because of an unusual router, a hidden network, or marginal signal range.

The small details that decide your success rate

A good provisioning flow is a short chain of screens where each screen owns exactly one step: find the device, choose the network, enter the password, wait with genuine progress feedback, confirm success. From experience, the factors that matter most are the ones that get forgotten during specification:

  • The 2.4 GHz issue. Most inexpensive Wi-Fi modules only support 2.4 GHz. A large share of field failures come from a user whose phone is on the 5 GHz band of a combined network, so the device never sees the SSID the app is showing. Detect this and explain it in plain language.
  • Error messages that say what happened. Wrong password, weak signal, router blocking new clients, captive portal — each needs distinct wording and a suggested action.
  • Re-provisioning without a factory reset. Users change routers and internet providers. Forcing a full reset to change networks generates support tickets.
  • Physical feedback on the device. An LED pattern or tone lets the user understand the state without staring at the phone, and it makes support calls dramatically shorter.
  • Timeouts and retries. Decide explicitly how long the device waits, how many attempts it makes, and what state it lands in afterward.

Signal strength is an engineering concern, not only a software one. A device installed inside a metal enclosure or low to the floor will have poor reception, so antenna design has to be settled before the first production run.

Security, cloud identity, and long-term maintenance

This flow carries the customer's home network password, so it must be encrypted end to end — including when the channel is a temporary access point or a BLE link. An unencrypted SoftAP transfer is a genuine vulnerability, not a theoretical one, and it is the kind of finding that surfaces in any serious review of IoT security for connected products.

You also have to decide how the device identifies itself to your server: a unique key burned in at manufacturing, a one-time token issued to the app, or a combination. That decision ties into device provisioning on the cloud side and into your fleet management approach, covered in our article on IoT fleet management.

Finally, remember the product keeps changing after launch. Compatibility fixes for new routers and mobile OS releases arrive almost exclusively through over-the-air firmware updates, so the update mechanism has to ship in version one rather than being planned as a later addition. Related material on building the app side of a physical product is collected on our app development page.

Get onboarding right before you ship

Projects House specifies, builds, and field-tests provisioning flows as part of connected product development — firmware, app, and cloud together. Describe your product through the contact form and we will map the right onboarding path for it.