Out-of-box setup is the first thing a real user does with a connected product, and it's also the moment where three separately-built systems — firmware on the device, the mobile app, and the cloud backend — have to hand off to each other flawlessly, in an uncontrolled environment, on a network the team doesn't control. It's a disproportionately high-stakes few minutes: a user who abandons setup never gets to experience whatever the product actually does well.
Provisioning protocol choice shapes the whole experience
The mechanism for getting a device onto the user's Wi-Fi network is one of the earliest and most consequential architecture decisions. BLE-based provisioning, where the app talks to the device directly over Bluetooth to hand off Wi-Fi credentials, tends to give the smoothest experience because it avoids asking the user to manually join the device's own access point — but it requires the device to have a BLE radio, adds firmware complexity, and depends on the phone's BLE stack behaving consistently, which varies more across Android devices than iOS. SoftAP-based provisioning, where the device broadcasts its own temporary Wi-Fi network for the phone to join, needs no extra radio but asks the user to manually switch networks mid-setup — a step that a meaningful fraction of users don't complete correctly on the first try, especially on iOS where switching networks and returning to an app is not seamless.
Neither approach is universally better; the right choice depends on what radios the hardware already has for other reasons, and how tolerant the target user is of a few extra manual steps.
Design the failure paths, not just the happy path
Most onboarding flows are designed and tested against a strong, uncongested Wi-Fi network in an office — which is not the environment most users are actually setting up in. Real homes have weak signal in the room where the device ends up, 5GHz-only or enterprise-style networks the device doesn't support, and typos in Wi-Fi passwords. What happens when Wi-Fi handoff fails is often more important to the overall experience than what happens when it succeeds, because a failed first attempt is where most abandonment happens.
A setup flow that can clearly distinguish between failure causes — wrong password, weak signal, unsupported network band, device firmware issue — and give the user a specific next step is far more forgiving than one that just times out with a generic error. That specificity requires the firmware to report meaningful failure states back to the app rather than a single opaque "provisioning failed," which is a decision that has to be made in firmware, not patched in later from the app side.
Failure modes worth designing for explicitly
- Wrong Wi-Fi password entered by the user
- Network band or security type the device's radio doesn't support
- Weak signal at the device's physical location
- Account-linking failure after the device is online but before it's associated with the user's account
- App losing connection to the device mid-setup (backgrounding, BLE drop) with no way to resume where it left off
Onboarding is a cross-team problem before it's a design problem
The user experiences onboarding as one continuous flow, but it's almost always built by three separate teams — firmware, mobile app, and cloud/backend — each of whom owns a different segment of it. Firmware owns provisioning and the device's initial network join; the app owns the UI and orchestrates the sequence; the backend owns account linking and device registration. When these teams design their pieces independently and integrate late, the seams show up as exactly the kind of inconsistent error handling and dead-end states that frustrate users. Getting onboarding right usually means treating the end-to-end flow, including every failure branch, as a single shared spec that all three teams design against together from the start, rather than three independently-built pieces stitched together at the end.
Practical takeaway
Out-of-box setup deserves the same design rigor as the product's core feature set, because for a real user it functionally is the product until it's done. Choosing a provisioning approach that fits the hardware, designing explicit failure states instead of a single generic error, and coordinating firmware, app, and cloud teams around one onboarding spec are what separate a setup flow users complete from one that quietly costs a product its early adopters. See our mobile & web work and firmware work for how we approach this end-to-end.