Loading...
Loading...

About
Some weeks that's a PCB and its firmware; other weeks it's a desktop app or an AI tool that has to run fast on someone's own machine.
Hardware
PCBs, embedded systems, low-power devices
Software
CLI tools, desktop apps, web products
ML
Training, on-device inference, edge deployment
01
The work ranges from USB-C analyzers and wearable sensors to desktop apps, terminal tools, and local AI systems. I care less about which category it lands in than whether someone can pick it up and it just works.
02
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.
03
Most of what I make comes with enough documentation and context that someone else can build on it. I open-source it because the docs that make a project usable to me are the same ones that let someone else fork it.
Working Style
The work I'm best at sits where the layers meet: a hardware limit that forces a firmware decision, a firmware limit that shapes what the model can do, a UI detail that decides whether anyone actually uses the thing. Knowing all three layers means I don't hand those tradeoffs off to someone else.
Typical stack
KiCad, ESP32, RP2040, C/C++, Rust, TypeScript, Python, PyTorch, TensorFlow Lite, Next.js.
What I optimize for
Honest tradeoffs, no half-built features, and a final product that does what it says.
If you're building something that needs hardware, software, and ML to all work together, that's exactly the kind of thing I like to take on.
Get in touch(opens in new tab)