BLE apps live or die in the pairing flow

Bluetooth Low Energy puts your product in someone's hand and its brain in their phone. The first sixty seconds of pairing decide the review. Below: the BLE work we can prove, with dates, and the three problems every BLE product has to solve.

The Work, With Dates

On the case studies, with the scope stated plainly

View Phyn by Belkin
Phyn by Belkin

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.

View Case Study
View Mitsubishi Comfort
Mitsubishi Comfort

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.

View Case Study

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

Why It Works

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.