About

I build products where the boundary between hardware, software, and ML is the real problem.

That can mean PCB design and firmware for constrained embedded systems, a desktop tool with a careful interface, or a local-first AI workflow that needs to be fast, inspectable, and actually usable.

Hardware

PCBs, embedded systems, low-power devices

Software

CLI tools, desktop apps, web products

Training, on-device inference, edge deployment

What I Build

The work ranges from USB-C analyzers and wearable sensors to desktop apps, terminal tools, and local AI systems. I care less about category than I do about whether the final thing is useful, understandable, and properly finished.

How I Work

I move between KiCad, firmware, Python training loops, inference tooling, and product UI because that is often what the problem demands. Understanding each layer changes the decisions you make in the others.

Why Open Source

Most of what I make comes with enough documentation and context that someone else can build on it. Open source is not just distribution; it is part of making technical work legible and durable.

Working Style

Broad enough to cross disciplines, disciplined enough to ship.

I am usually most valuable when a project has technical seams that are easy to mishandle: hardware constraints that shape firmware, firmware limits that shape inference, or product details that determine whether a tool is actually pleasant to use. That breadth is the point.

Typical stack

KiCad, ESP32, RP2040, C/C++, Rust, TypeScript, Python, PyTorch, TensorFlow Lite, Next.js.

What I optimize for

Clarity, practical engineering tradeoffs, and products that feel coherent all the way through.

Let's Build Something Difficult

If the project does not fit neatly into one discipline, that is usually a good sign. Those are the ones worth talking about.

Start a Conversation