Most connected-product delays happen between the firmware team and the app team. We take both sides, so the protocol is agreed once and there is nobody to hand the bug to.
Usually somewhere between a working prototype and a product people can actually set up on their own.
You have hardware and firmware; what is missing is the phone side. Also the usual rescue: an app that works on the founder's iPhone and on half of Android. We build the BLE or WiFi client, the pairing flow, the control screens and the store releases.
One team owns the protocol on both sides
A breadboard ESP32 that works on your desk is not yet a device a customer can unbox. We take it through provisioning, error states, factory reset, updates and the things that only show up outside the lab.
Handles the paths that are not the happy one
The step where most support tickets are born. We implement provisioning over BLE or SoftAP, handle the 2.4GHz-only confusion, captive portals and wrong passwords, and tell the user what actually went wrong.
Setup the owner can finish without you
Devices report over MQTT or HTTPS into a backend you own. Readings, state, errors and battery in one place, with alerts when a fleet member goes quiet.
You can see what the fleet is doing
Signed images, two partitions and rollback that actually fires: the new build only marks itself valid once it has proved it can still reach the cloud, which is the step most implementations skip and the reason rollback is so often cosmetic. Staged rollouts keep a bad release away from the whole fleet.
Ship firmware without a recall
Deep sleep, wake sources and how often the device really needs to talk. Sleep current is rarely what drains the battery — the radio bursts and the external flash usually are. We measure on your board instead of quoting datasheet figures.
Runtime you can put on the box
Espressif silicon and the transports around it, plus the app and backend that make a device usable.
ESP8266 is marked Not Recommended for New Designs by Espressif, so we use it for devices already in the field and start new work on ESP32-C3 or C6. Working with a different MCU or a vendor SDK? Tell us which; the app and cloud half does not change.
Being clear about this up front saves a month of discovering it later.
We work alongside your electronics engineer or contract manufacturer and speak their language.
Your hardware, whatever firmware there is, and the protocol between device and phone. The first thing we write down is the protocol itself, versioned — so a firmware change and an app change can never disagree silently later. Then we say what we would keep and what we would redo.
The earliest useful milestone is a phone talking to your real board. We get that working first, because it is where the unknowns live. While boards are scarce or being respun, the app is built against a simulated device so it never waits on hardware.
Provisioning, control screens, telemetry, OTA and the error paths. Firmware and app move together, so the protocol never drifts.
Real phones, real routers, real walls. We test across Android makers, ship to the stores and stay on for the first firmware rollouts.
Yes, if the electronics are coming from your engineer or a contract manufacturer. We can prototype on a dev board so the app and cloud are ready when the first boards arrive, but we do not design the board itself.
Usually not. We read it, agree on the protocol, and extend it where the app needs something it does not expose. A rewrite gets proposed only when the existing code cannot carry OTA or security safely, and we say why.
Because Android BLE differs by manufacturer and by OS version. The undocumented GATT error 133, a silent limit of five scans per 30 seconds, MTU that stays at the 23-byte default when nobody negotiates it, and OEM battery managers that kill background connections are all ordinary field failures. We test on a matrix of real phones from the makers your customers own, not on one flagship.
A phone talking to your board is usually 2–3 weeks. A device someone can unbox and set up alone is 2–4 months depending on how much firmware exists and how many states the product has.
You do. Source, signing keys and cloud accounts are yours from day one and live in your accounts, not ours. If you later take it in-house, there is nothing to migrate.
Tell us what the hardware is and where it is stuck. We'll say what we would do first and what it would take.
Discuss your device