I build acoustic monitoring systems from physics to product: modelling how waves propagate, writing firmware that captures them in real time, extracting features that make machine learning tractable, and shipping the whole stack.
Every acoustic monitoring product I've built spans nine technical layers, from the physics that governs wave propagation to the cloud and product layers that make it usable. Hover any node to see what it means. Solid nodes are deep expertise. Outlined nodes are expanded domains. Dashed nodes are real gaps.
The same kinds of problems recur across companies and domains. Organised here by what was actually done rather than by employer. Expand each section below to see what was built.
Built outside work hours, driven by curiosity or a gap in what existed.
The domains I work across have expanded, not because the physics changed, but because AI-assisted development lowered the cost of entering adjacent technical territory. The physics intuition and problem framing are mine; the implementation speed in unfamiliar languages and frameworks is augmented.
This isn't delegation. It's the difference between knowing what you want to build and being limited by how long it takes to build it. The Holiday Explorer involved frontend development, mapping APIs, and routing algorithms, domains I hadn't worked in formally. The LoRa mesh layer required RF and communications protocol knowledge beyond my core training. The embedded firmware demanded low-level memory management I had to learn in production. All of it now works.
In practice, this looks like maintaining a structured technical context document (what problem I'm solving, what the physics constraints are, what the edge device requires) and handing that to the model before any implementation session. The physics framing is mine; the implementation of unfamiliar syntax is accelerated.
Open to technical collaboration, consulting, and the occasional interesting problem.