About · Jason Too · Cambridge
I'm Jason. I build hardware, software, and ML, and the projects I like most need all three at once.
I'm Jason Too, a Cambridge-trained engineer who owns products end to end, from hardware and firmware to ML, apps and the web. I'm increasingly focused on using AI and agentic workflows to change how I build, test and ship.
Hardware
PCBs, embedded systems, low-power devices
Software
CLI tools, desktop apps, web products
ML
Training, on-device inference, edge deployment
Experience
- In my day job in consumer-electronics R&D, I take features from concept to production across firmware, platform services and mobile apps, working with design, data science and signal-processing teams.
- I build agentic workflows for development, triage and monitoring. One cut a 10-15 minute loop to about 60 seconds and made agent-driven validation and evals on real hardware possible.
- I co-created a 24-hour hackathon prototype that won a company-wide hackathon, shipped to millions of customers and was shown at CES 2026.
- I've shipped edge ML to production on embedded devices and prototyped on-device LLM agents, including fine-tuning a 270M function-calling model.
- Through elektroThing (since 2022) I design, manufacture and ship my own products: Spark Analyzer (open-source USB-C PD analyser, three hardware revisions, 596% funded on Crowd Supply, Hackaday Prize 2022 finalist), Tracer (13 g BLE wearable with on-device motion classification, 30+ days battery, sold on Tindie, featured by Espressif), trinkt.co (social generative-art app, Next.js + Supabase) and patchly.cc (error monitoring that turns production errors into GitHub issues with LLM-written repair notes).
01
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 which category it lands in than whether someone can pick it up and it just works.
02
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.
03
Why Open Source
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
I work across the stack because most of my projects don't respect the boundaries between layers.
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 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.
Got something that doesn't fit one box?
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