Embedded software and device integration
The device works, the app works, and the connection between them is nobody's job. That's usually where the project stalls. I work both of those sides: driving printers, scanners, and sensors from production software, and writing the firmware on the device when that's the missing piece.
Based in Groningen, working across the Netherlands and remotely for clients worldwide.
Software that talks to physical devices, and firmware for the devices themselves. Driving equipment over serial, USB, Bluetooth LE, and MQTT, plus firmware for ESP32 and Arduino boards.
Suitable when the device comes from one team and the software from another, and nobody sits in between.
Good for
- Products where an app or backend has to drive real devices over serial, USB, Bluetooth LE, MQTT, or plain TCP.
- An integration that already runs but isn't reliable: dropped connections, duplicate commands, print jobs that sometimes never arrive.
- IoT projects where the firmware, the backend, and the dashboard have to fit together, and nobody owns all three.
- Existing hardware with a protocol that's poorly documented, or not documented at all.
How I approach it
- The protocol first. Before any screen exists, I get a throwaway script talking to the device and write down what the device actually does, including the undocumented parts. Everything above that layer is cheap to change. This layer is not.
- Dropouts as the default. Cables get unplugged, batteries die, WiFi drops mid-write. Queueing, retries, and idempotent commands are designed in from the start, not patched on after the first field report.
- One system, not three. The device, the backend, and the dashboard are built and released together. That way a change to the protocol doesn't quietly break the screen that reads it.
- Prove it on the real device. Every milestone is signed off on your hardware, not on a simulator: a demo or a log of the device doing what we agreed. For firmware, that includes how you update the device yourself later, over the air or with a flashing script you can run without me.
Work I can show
- Peripherals in a retail platform. For a retail automation platform I drove receipt printers, label printers, and barcode scanners from the web application, over ESC/POS on serial and USB, with a local queue that kept running when a device or the network dropped out.
- ESP32 firmware with e-paper and a UART sensor. A build of my own. I worked out an air-quality sensor's protocol from thin documentation and built the monitor as ESP32 firmware driving an e-paper display. The display side became a standalone open-source ESPHome component on GitHub, which has since collected stars and forks from people who wanted the same panel working. Read the build.
- Reverse-engineering headphone Bluetooth protocols. Also my own. To drive noise control on non-Apple headphones from iOS, I captured the Bluetooth traffic and reconstructed the command set. Read the write-up.
Tech I work with
Serial and USB (CDC, ESC/POS), Bluetooth LE, MQTT, TCP, ESP32, Arduino, C and C++, Go, Python, TypeScript, Postgres, offline-first sync.
Frequently asked questions
Do you write the firmware, or only the software that talks to the device?
Both, though the track record differs per part. Driving devices over serial and USB is what I've shipped in production. Bluetooth LE, and firmware for ESP32 and Arduino, have so far come out of my own projects, and the builds above show what that looks like. As with any project, the first step is one small fixed-price milestone, so you see it running on your hardware before committing to the rest.
We already have the hardware. Can you connect to it?
Usually yes. With a datasheet or protocol document it's straightforward. Without one it becomes investigation: capturing traffic on the wire, reconstructing the command set, and confirming it against the device. That takes time, so I scope it as its own step instead of hiding it inside a fixed price.
Is this one prototype, or devices in the field?
Both happen, but they're different projects. One device on a bench is mostly protocol and firmware. Two hundred devices out at customer sites also bring in provisioning, remote updates, and some way to see what's going wrong.
What happens when the network or the device drops out?
Commands queue locally, and the device and the central system reconcile once the connection returns. On the firmware side that means watchdogs, and a device that comes back up in a known state after a power cut.
Do you design the electronics or the PCB?
No. Schematics, PCB layout, and enclosures aren't my field, and I'd rather say so than learn on your budget. CE marking and EMC testing are the same answer: work for a test lab, and for whoever puts the device on the market. What I do is work with off-the-shelf boards and pre-certified radio modules, stay inside the limits of those modules, and supply the documentation the test lab asks for. Otherwise I work alongside your electronics engineer, on both sides of the connector.
Tell me what the device has to do
Tell me which device or module it is, what documentation you have, even if that's none, and what it needs to drive. I'll tell you whether it's feasible and what the first step would be, and that costs you nothing.
Get in touchOther services
- Custom application development End-to-end design and implementation of bespoke applications across web, native iOS, and backend systems, including MVP builds for early-stage products.
- Web, API and backend development Production websites, web apps, and APIs in React, Preact, Svelte, and vanilla web. Backends in Go and Python with REST or event-driven APIs.
- AI prototype to production Turning a prototype built in Lovable, Bolt, Replit, v0 or Cursor into software you can safely put real users and real customer data on.
- AI and LLM integration LLM-powered features for existing apps and new products: agent workflows, RAG pipelines, and integrations with OpenAI, Anthropic, and similar providers.
- Legacy code modernization Refactoring and modernizing older codebases. Framework upgrades, careful test-driven changes, and migrations from end-of-life platforms.
- Native iOS apps Native iPhone and iPad apps in Swift and SwiftUI, including widgets, Live Activities, and App Store delivery.
- Browser extensions and integrations Chrome extensions, Thunderbird add-ons, and integrations between browsers and external services.
- Performance-critical engineering Algorithms, audio and video processing, codec work, P2P networking, and other engineering-depth projects where performance and correctness matter.