Most connected products fail on the phone, not on the board. The firmware works, the radio works, and then a customer stands in their kitchen with a device that will not finish setup — because the app assumed a clean connection, a stable operating system and a phone that behaves like the one on the engineer’s desk.
That gap is the work we do.
What makes a hardware app different
A normal app talks to a server you control, over a network that mostly works. A connected-hardware app talks to a device you may not control, over a radio link that drops, on two operating systems that each impose their own rules about what is allowed to happen while the app is in the background.
Three things follow from that, and they are where projects overrun:
- The connection is a state machine. Scan, connect, discover, negotiate, subscribe, operate, reconnect. Every one of those steps can fail on its own, and the app has to be honest with the user about which one did.
- The platform is not neutral. iOS and Android disagree about packet sizes, connection timing, permissions and what survives the app being closed. We have written about the specific traps and what they cost.
- You cannot test it at a desk. Range, interference, a phone in a pocket, a device at 8% battery, a firmware version from eighteen months ago. The bugs that reach support are all field bugs.
What we actually do
We start with the protocol, not the screens. If the GATT schema is wrong, every decision above it inherits the problem, and changing it later means shipping firmware to devices already in customers’ hands.
From there: the onboarding flow, because the first ninety seconds decide your return rate; the update path, because firmware you cannot update is a product you cannot fix; and the reconnection behaviour, because that is what people actually experience day to day.
We work alongside your firmware team rather than around them. In practice that means shared protocol documentation, a test harness both sides can run, and logs that say which half of the system went wrong.
If you already have an app
A lot of this work is rescue. The first version was written by the firmware team, or by an agency that treated BLE as a library call, and it has been accumulating workarounds ever since.
We will read it and tell you what is salvageable. Sometimes the answer is a protocol change and a rewrite of the connection layer, leaving your screens alone. That is a cheaper project than it sounds, and it is usually the one that fixes the support tickets.
Regulated and medical devices
If your product is a medical device, the app is part of it. Data handling, audit trails and the claims your interface makes are all in scope, and the rules differ between Canada and the United States — we have written a plain-language guide to which ones apply. We will tell you early if a project needs expertise we do not have.