Software for machines people depend on.
I'm an embedded software engineer working on the systems inside industrial and agricultural equipment — the real-time C++ underneath, the CAN and ISOBUS networks in between, and the Qt/QML interfaces operators actually touch. I build new products from the ground up, join codebases that already exist, and help teams get unstuck.
Whether the repository is empty or fifteen years old.
Most of my work falls into one of these. If yours sits somewhere between them, that is usually a good conversation to have rather than a reason not to get in touch.
Built from the ground up
A new product, a blank repository. I take it from the first architecture conversation through to software running on real hardware — and stay involved long enough to see it hold up in the field, not just in a demo.
Work on software you already have
Most software isn't new. I join projects already underway: adding features, untangling the parts everyone has learned to avoid, migrating Qt 5 to Qt 6, and getting stalled work moving again.
Performance and reliability work
When something is too slow, too heavy, or drops frames on the target board, I profile it and find out why — startup time, render performance, memory, bus load — then fix the cause instead of the symptom.
Consulting and technical review
A considered second opinion before you commit: architecture and code review, protocol conformance, technology choices, feasibility, and an honest read on what a piece of work actually involves.
Training and mentoring
Workshops and hands-on mentoring for your team — modern C++, Qt/QML, CAN, J1939 and ISOBUS, and the testing habits that keep embedded projects from drifting sideways.
Integration, tooling and automation
The unglamorous work that makes a team faster: bus simulators and test rigs, decoders and log analysers, build and CI automation, and the glue between systems never designed to talk to each other.
Systems that have to keep running.
A sense of the shape and scale of what I build. Details of any particular engagement stay between me and the people who paid for it.
- 01
Precision-agriculture platform
Guidance, telemetry and implement control across roughly thirty modules — the software a machine runs on all day, from satellite fix to the section valves.
- C / C++
- Qt
- ISOBUS
- GNSS
- 02
Vehicle protocol stack
A CAN protocol stack covering J1939, ISO-TP, UDS and CAN-FD, with virtual terminal, task controller, file server, auxiliary control and tractor ECU support.
- C++
- J1939
- ISO 11783
- UDS
- 03
CAN engineering workbench
A desktop bus workbench for engineers who live in trace files, paired with a database linting and decoding toolchain that catches malformed definitions early.
- Python
- Qt Quick
- DBC
- 04
Browser toolset for bus engineers
Around thirty client-side tools — trace analysers, database explorers, parameter and data dictionaries — that run entirely in the browser, so no trace file ever leaves the laptop.
- TypeScript
- Astro
- React
What I work with, and where it came from.
The list is broad because off-highway machinery is: one product can span a real-time control loop, a vehicle bus, a satellite fix and a touchscreen. Everything below is something I have shipped with, not something I have read about.
Embedded & real-time
- Modern C++ (17/20)
- C11
- Embedded Linux
- RTOS & bare metal
- Device drivers
- Cross-compilation
- Hardware bring-up
Interfaces & HMI
- Qt 6
- QML / Qt Quick
- PySide6
- In-cab touchscreens
- Outdoor readability
- Desktop tooling
- Qt 5 → 6 migration
Vehicle networks
- CAN & CAN-FD
- J1939
- ISOBUS (ISO 11783)
- ISO-TP
- UDS diagnostics
- DBC
- VT · TC · FS · AUX · TECU
- Bus load analysis
Precision agriculture
- GNSS positioning
- Auto-steering & guidance
- Section control
- Implement control
- ISOXML / TaskData
- Telematics
Software & web
- Python
- TypeScript
- React
- Astro
- Node.js
- REST APIs
- SQLite & Postgres
- Cloudflare Workers
AI & automation
- LLM agent integration
- Self-hosted inference
- Workflow automation
- ONNX & edge accelerators
- Data pipelines
Practice & infrastructure
- Automated test suites
- CI pipelines
- Docker
- Linux servers
- nginx
- Observability
- Technical documentation
How the work actually runs.
Understand
Before any code: what the machine does, who operates it, and where the real constraint sits. In my experience it is rarely where everyone expects.
Shape
Architecture and interfaces sketched together, so integration risk turns up at design time rather than during bring-up, when it is expensive.
Build
Small increments, each one running on the real target against real data. You see working software every week, not a long silence and a big reveal.
Hand over
Tests, documentation and a proper walkthrough — so the work still makes sense to your team once I am no longer the one holding it.
A short version.
Most of my work has been in off-highway and agricultural machinery — guidance and auto-steering, ISOBUS implement control, and the displays in the cab. The common thread is that the software has to be right when someone is depending on it at five in the morning, in a field, a long way from a laptop and a debugger.
That has shaped how I work. I test against real hardware and real bus traffic rather than mocks alone. I would much rather find the awkward constraint in the first week than during integration. And I try to leave behind a codebase the next engineer can read without a guided tour.
I work with teams of any size, from a founder with a prototype and a deadline to an established engineering group that needs one specific gap filled properly — as a contractor, an extra pair of hands on an existing team, or an advisor you can call when a decision is hard to reverse.
Tell me what you're building.
A new product, a codebase that has become hard to change, something that needs to run faster, or a team that wants to learn this properly — all worth a message. No obligation, and no sales pitch waiting at the other end.