Service Embedded & IoT products
The whole chain, from sensor to screen.
Most studios stop at the app and hand the hardware back to someone else. We write the firmware, bring up the wireless link, build the iOS and Android app that talks to it, and the web console that watches the fleet — one team, one understanding of the whole path a byte takes.
01 What we build
Six links in one chain.
For PRS Motorsport Equipment in Monza, that chain runs from an electronic paddle-shift control unit — configured over a serial protocol decades old — to a native iOS app and a Next.js and Supabase web console, with two polling cadences: half a second for the live parameters, one second for the rest. Nothing beneath the protocol changed. It's an ongoing collaboration, and the full build log is in the Logbook.
Device firmware
ESP32, nRF52, and Arduino-class microcontrollers: sensor reading, actuator control, state machines, power behaviour, and the storage of settings that must survive a reset.
BLE & wireless connectivity
GATT services designed rather than improvised — pairing, reconnection, chunked transfers, and a link that recovers by itself when a phone walks out of range. Wi-Fi and serial where they fit better.
Companion apps
Native iOS and Android apps that connect, configure, and monitor: live readouts, setup flows, firmware updates, and the offline behaviour a device app needs when the device isn't there.
Web consoles & fleet dashboards
The operations side: every unit in the field, its owner, its parameters, its history and live graphs — the view the manufacturer needs, while the app is what the customer holds.
Protocol bridging for legacy hardware
Your product already works and already speaks something. We read it, map its real behaviour, and wrap it — so a proven control unit gains a modern front end without a firmware rewrite.
OTA updates & diagnostics
Signed, staged, reversible firmware rollouts from the console, plus the telemetry that tells you which units took the update, which are struggling, and why.
02 How it works
Where the seams usually are — and why we don't have them.
Hardware projects fail at the handovers: the firmware team blames the app team, the app team blames the link. We hold the whole chain, so a bug is just a bug. To be clear about the edges: we do the software — firmware upward. We do not manufacture hardware, design PCBs, or run regulatory certification.
Fig. — The full chain. Where hardware already exists, everything we add sits beside it: the firmware and its protocol stay as they are.
03 The build
From a bench cable to a product people use.
Read the hardware
A bench session with a real unit. We map what the device actually says — not what the datasheet claims it says. On legacy protocols this is most of the engineering, and it happens before anything is promised.
Prove the link first
A narrow spike: device to phone, real values, real reconnection. The riskiest part of an embedded project is the wireless layer, so we settle it in week one rather than discovering it in week eight.
Design the cadence
Which values must feel live, and which can wait a second. Deciding this parameter by parameter — with you — is what makes a device app feel instant instead of drowning its own link in traffic.
Build the chain
Firmware, app, and console developed together in short cycles, each one reviewed. You see running software on real hardware throughout, not a demo at the end.
Field test, then hand over
Tested where it will be used — the noisy, out-of-range, low-battery cases — then shipped with OTA in place. You get the firmware source, the app projects, the console, and the keys.
04 Fit
This is for you if…
- Your product is configured with a cable, a laptop, and software written years ago.
- You have working firmware and need the app and console that should sit on top of it.
- You've been quoted by an embedded shop and an app shop, and neither owns the middle.
- Your BLE connection works on the bench and drops in the field.
- You ship units you can't see once they leave — no update path, no diagnostics.
- Support answers questions a dashboard could answer, one customer at a time.
05 Questions
What clients ask first.
We already have firmware that works. Can you leave it alone?
Yes, and that's usually the right call. If your unit ships to paying customers, the safest project is a purely additive one: we speak the protocol your firmware already speaks and change nothing beneath it. That's exactly how the PRS work was built — a phone and a web console added around a control unit that stayed untouched. Where firmware changes are genuinely needed, we say so and scope them separately.
How reliable is BLE, honestly?
Reliable when it's designed for, unreliable when it's assumed. Phones drop connections, radios share a crowded band, and users walk away mid-transfer. So we build for it: reconnection logic, sequence numbers and acknowledgements, chunked transfers that resume, and app behaviour that stays sensible while disconnected. We also prove the link on real hardware in week one, before anything else is built on top of it.
Do you handle certification?
No — and we'd rather be blunt about it than discover it late. We do software: firmware, wireless, apps, cloud. We do not manufacture hardware, design or lay out PCBs, or run regulatory certification — FCC, CE, UKCA, EMC, or safety approvals. Those belong with your hardware partner or a test house. We'll work alongside them, keep the firmware side of any compliance requirement honest, and tell you early where our scope ends.
Who owns the firmware source?
You do. Firmware, app projects, console, schematics of the data model, build instructions — all in your repository, under your account, from the first commit. No binary-only drops and no licence that makes you come back to us. Clients who want us to stay do it because it's useful, not because they're locked in.
Our device speaks an old protocol nobody documents any more. Can you work with it?
That's the normal case, and it's the part we enjoy. Terse single-character commands, tightly packed responses, behaviour that lives half in the documentation and half in the firmware's habits — it's an archaeology problem before it's a coding problem. We start with a bench session and a real unit, map what it actually does, and only then quote the build.
06 Related
Often built together with:
Tell us what your hardware does today.
What the device is, how it's configured now, and what you wish someone could see on a phone. You'll get a straight read on scope, risk, and cost — and where a bench session is the honest first step, we'll say that too.
Book a free discovery call