BLE apps live or die in the pairing flow
The Work, With Dates
On the case studies, with the scope stated plainly

Phyn by Belkin
Belkin brought us in in 2016, before there was a product. We built the MVP that proved the bet: Bluetooth device pairing, the sensor data coming off the hardware, the service behind it, and the app someone actually used to see their own water. Phyn debuted at CES 2019 and shipped across iOS, Android, and web from that MVP. Phyn Plus took a Red Dot Award for product design in 2019.

Mitsubishi Comfort
BLE at fleet scale: we rebuilt the communication layer between the platform and its IoT device fleet and migrated the fleet to AWS IoT Core, with mobile, web, and adapter firmware moving together. Bluetooth is part of how those devices and that app meet.
What This Work Involves
The Three Problems Every BLE Product Has to Solve
The protocol is documented. These are not.
Pairing and Provisioning
The owner's first sixty seconds. Discovery, bonding, and recovery when it goes wrong, designed so a person in their kitchen succeeds without a support call.
The Operating Systems
iOS and Android meter background Bluetooth differently, and both change the rules by version. What your product can promise depends on what the platforms actually allow.
The Data Path
A constrained device, a phone in the middle, and a service that has to keep up when the data arrives in bursts. The app is the courier; the system is the product.
Design for the Phone You Don't Control
The phone is part of your device.
A BLE product borrows the owner's phone for its connectivity, its screen, and half its brain. That is the economy of the design, and it is also the trap: every OS update, permission prompt, and battery optimization sits between your hardware and your customer.
We design for that from the first day, because we have shipped through it: for Phyn, for Mitsubishi Comfort, and for Flume. The pairing flow, the background behavior, and the recovery paths get engineered like the product features they are.
Is This You?
We're a good fit if: You have BLE hardware in the field or on the way, and the app side needs people who have shipped a connected product, not a team learning on yours.
We're not a good fit if: You need firmware written from scratch with no app or cloud attached, or electrical engineering. Our work starts where the hardware meets software people touch.
Tell Us About the Device
Describe the hardware and where the app stands. We'll tell you which of the three problems is yours, and what we would do about it.