The App, the Cloud and the Setup Experience for Your Hardware
Companion apps, provisioning, telemetry and update delivery for connected products. We build the software side of your device — the hardware and the firmware stay with your engineers, and we say so plainly before anyone signs anything.
What We Do, and What We Don't
Connected products fail at the seams between teams. So here is exactly where our work stops, in public, before you call us.
The companion app
iOS and Android, or one cross-platform build. Discovery, pairing, provisioning, control, history, notifications, account and household sharing, and all of the unhappy paths that decide whether your device gets returned.
The cloud side
Telemetry ingestion, device registry, time-series storage, alerting, the customer-facing web app and the internal fleet dashboard your support team lives in. Plus the APIs that connect all of it.
Update delivery and operations
Signed image hosting, targeting by device group, staged rollout with a stop button, progress and failure reporting, and the tooling your support staff needs to see what a specific unit in the field is doing.
Hardware design
Schematics, board layout, component selection, antenna design, enclosures, certification and manufacturing. You need a hardware team for that, and if you do not have one yet, that is the gap to close first.
Embedded firmware
The code on the device, the bootloader and the radio stack belong to your firmware engineers. We will specify the Bluetooth characteristics and message formats we need with them, test against real units constantly, and be a demanding but useful counterpart.
The interface between us
Services, characteristics, payload formats, error codes, provisioning states, retry behaviour, update protocol. Written down and agreed in the first fortnight. Vague here means months lost later, every single time.
If your device already exists and the firmware team is in place, this is a straightforward engagement. If the hardware is still an idea, talk to a hardware partner before you talk to us.
Most of the Difficulty Is in the First Five Minutes
Getting a device onto a customer network is the hardest part of nearly every connected product, and the part people assume will be trivial.
A Bluetooth scan, filtered so the user sees their new device and not eleven neighbouring ones.
An encrypted Bluetooth session, with the pairing code shown on the device or printed on it — never the same code on every unit.
The app lists nearby networks, takes the password, and sends the credentials over the encrypted link. This is the step that goes wrong.
It connects to the network, opens a session with your cloud and claims its place in the device registry under this account.
The cloud tells the app the device is online and bound to this user, so ownership is proved from the server, not assumed by the phone.
Wrong password, 5 GHz only, out of range, captive portal. Each gets a specific message and a way forward, because "setup failed" is how a unit gets returned.
Why this eats a third of the budget
During provisioning the phone is asking a device it barely knows to join a network it cannot see, using a password a human typed with their thumbs. The phone often has to leave its own network to talk to the device, so for several seconds nothing can confirm anything, and any of a dozen ordinary household conditions will break the sequence.
So the work is not the happy path, which takes a week. It is the timeouts, the retries, the ability to resume after the user walks into another room, the specific error messages, and the permission prompts that iOS and Android show for Bluetooth and location in ways that change between versions. Products that skip this look fine in the demo unit on the desk and generate support calls from real houses.
- Tested against real routers, not only a clean office network
- Every failure mode gets its own message and its own next step
- Setup can be resumed, not restarted from the beginning
- Provisioning logs your support team can read when a customer calls
What a Companion App Has to Get Right
Onboarding and ownership
Unboxing to working device with as few taps as possible. Then the questions people forget to scope: who else in the household can control it, what happens when the device is sold, and how a factory reset releases it cleanly from the old account.
Telemetry ingestion
Thousands of small messages arriving continuously, written into storage built for time-series data rather than an ordinary table. Sensible sampling and retention too, because keeping every reading at full resolution forever is a bill nobody enjoys.
Dashboards and alerts
History the customer can read, and a fleet view your team can work from: which units are offline, which are reporting oddly, which firmware version is where. Alerts that fire on a real condition rather than on every momentary blip, and reporting that joins device data to the rest of the business.
Offline and intermittent links
Devices lose connectivity constantly and that is normal. Readings are buffered on the device and reconciled on reconnect, the app shows the last known state with a timestamp, and commands sent into a void are either queued or cancelled, never silently lost.
Control and notifications
Turning something on from the app should feel immediate, which means optimistic feedback plus real confirmation from the device. Push notifications for the events that matter, and restraint about the ones that do not.
APIs and integrations
A documented API for your own web app and for partners, and integrations with the voice assistants and home platforms your customers already use. Built on the same backend services as everything else.
Shipping an Update to Devices You Cannot Reach
We build the delivery system, your firmware team builds the part that installs it safely. Both halves have to exist before a fleet update is a good idea.
Sign the image and host it
Every image is signed, and the device verifies that signature before installing anything. Without it, the update channel is a way for somebody else to put their code on your hardware, which is the worst outcome available in this whole category.
Target a group, not the fleet
Updates go to a cohort: internal units first, then early adopters, then a percentage, then everyone. Targeting by hardware revision and current version matters too, because the same image is rarely correct for every unit in the field.
Assume the power goes out mid-install
A device that loses power halfway through must come back on the old image, not as a brick. That means dual storage banks and a bootloader that falls back on its own. It is firmware work, we do not write it, and we will not roll out without it.
Watch the numbers and keep a stop button
Download success, install success, devices that came back online, error codes by hardware revision. If a cohort looks wrong, the rollout stops immediately rather than after the weekend.
Respect the constraints of the thing
Battery devices should not download over cellular at two percent charge. Devices doing something safety-relevant should install when idle, not mid-cycle. These rules come from your hardware team and get encoded in the rollout service.
Security on Devices That Have Very Little to Spare
A connected product is a computer in somebody's home with a permanent route into your cloud. It deserves the same seriousness as the rest of your infrastructure, on a fraction of the resources.
Device identity
- Every unit gets its own credential at manufacture, never one shared secret across a product line
- One leaked shared key means every device you have ever sold is compromised at once
- Credentials belong in secure storage on the chip where the hardware offers it
- Individual devices can be revoked without a recall, which is the whole point
Transport and the cloud side
- Encrypted connections throughout, with the device verifying your server and not only the reverse
- A device may only write its own telemetry and read its own configuration, nothing else
- Rate limits, so a single misbehaving unit cannot flood your ingestion pipeline
- Treat every incoming message as untrusted input, because a field device can be opened and probed
Working within the constraints
- Small memory, slow radios and a battery budget rule out a lot of ordinary choices
- Compact binary message formats rather than verbose text, to save both power and airtime
- Cryptography that the hardware can accelerate, agreed with your firmware team early
- Batched sends, because a radio that wakes constantly drains a battery faster than any feature
Privacy and the long tail
- Device data is often household data, so retention and deletion need answering before launch
- Selling or giving away a device has to remove the previous owner completely
- A published end-of-support date is more honest than quietly abandoning old units
- Plan for the day a dependency you rely on changes its terms, because it will happen
How a Connected Product Build Runs
Agree the boundary
A written interface between the firmware team and us: Bluetooth services and characteristics, message formats, error codes, provisioning states. Two weeks here saves two months later.
Build against a simulator
Real units are scarce early on, so we build a device simulator and develop against it. It also lets us reproduce failures on demand that would take hours to trigger on real hardware.
Get onto real units fast
Simulators lie eventually. We test on actual hardware, real routers and real phones as soon as units exist, because provisioning problems only appear in genuine conditions.
Pilot, then open the gate
A small field pilot with full logging, so the failures arrive as data rather than reviews. You get a working build every two weeks and a written update at the end of each working day.
Connected Device Questions
Do you build the hardware or the firmware?
No. We build the software side: the mobile and web apps, the cloud services that receive telemetry, the dashboards, and the system that delivers updates. The board, the enclosure and the code running on the device itself need a hardware team or an engineer you already have. We work alongside them throughout and define the interface between us in writing early, because that boundary is where most connected-product projects lose their weeks.
Why is Wi-Fi setup such a big part of the budget?
Because it is the first thing a customer does and the thing most likely to fail. The app has to find the device over Bluetooth, pair with it, hand over network credentials somebody typed on a phone, then wait while the device joins a network the phone cannot observe. Each step fails for reasons the app cannot see: wrong password, hidden network, a 5 GHz band the device cannot use, a captive portal, a weak signal in the hallway. Recovering gracefully from each of those is real engineering, and skipping it produces returned units.
Do you support Bluetooth Low Energy and Wi-Fi?
Yes, and most often both together. Bluetooth handles setup and close-range control, while Wi-Fi or cellular carries telemetry once the device is on a network. We also build for products that stay on Bluetooth alone, which changes the design considerably, because then the phone is the only bridge to the internet and nothing reaches your cloud while the app is closed.
What happens when the device is offline?
It should keep doing its job. Devices buffer readings locally and send them when the link returns, the app shows the last known state with an honest timestamp instead of an endless spinner, and a command issued while offline is either applied on reconnect or clearly cancelled. Which of those two is correct is a product decision we make with you deliberately, not a default someone picks quietly during the build.
Can you deliver firmware updates over the air?
Yes, on the delivery side. We build the service that hosts signed images, targets them at a group of devices, releases in stages and reports progress and failures. The device itself needs a bootloader that verifies the signature and falls back to the previous image if the new one fails to start, and that part belongs to your firmware team. We will not push a fleet update without that safety net, because a bad image with no way back is how a product becomes a recall.
Tell Us About Your Device
What it measures or controls, how it connects, and who is doing the firmware. We'll come back with a scope for the software side and a budget range for it.