Open Source Is the Best Portfolio You Can Build
I've built three open source tools for the home automation community. They're not famous. They work. And they've taught me more about building for real users than anything else I've done.
The best thing about a resume is that almost nobody believes it. The best thing about working code is that it doesn’t care whether you believe in it.
I build open source tools because I run into problems, and building the solution is more satisfying than complaining about the problem. That’s it, really. But a side effect of that habit is that I now have a portfolio of working software that I can point to — tools that solve real problems for real users, that I can show a stranger and say “here, run it, see if it works.”
What I’ve shipped
I’ve built three tools for the home automation community, all of them free and open source.
Homey Pro Optimizer is a CLI tool that connects to your Homey Pro smart home hub over the local network and audits it. Memory usage, app count, device health, flow volume — it gives you a clear picture of what’s actually happening on your hub, and actionable recommendations for fixing what’s wrong. Home automation setups accumulate cruft over time. Devices you stopped using still running. Apps you forgot about eating memory. This tool makes the invisible visible.
Zigbee2MQTT Doctor is a browser-based diagnostic dashboard for Zigbee2MQTT. If you’ve ever tried to debug a Zigbee mesh — figuring out which devices have weak signal, which ones keep dropping offline, what your coordinator health looks like — you know how painful it is to piece together that picture from log files and command outputs. This tool shows you LQI signal bars, offline devices, coordinator health, a live log stream, and lets you export to CSV. No install required. Open it in a browser and it connects.
ESP32 Flasher is the one I’m most proud of.
Why the ESP32 Flasher matters
Flashing ESP32 devices — loading firmware onto the microcontrollers that power a huge percentage of DIY home automation hardware — is one of those tasks that should be easy but isn’t. The existing tools require Python, drivers, command line knowledge, and usually a fair amount of troubleshooting before things work. The user experience is largely an afterthought.
The ESP32 Flasher runs entirely in the browser. No Python. No drivers. No command line. You connect your device via USB, open the page, select your firmware (ESPHome, Tasmota, WLED, MicroPython, and more), and flash it. The WebSerial API makes this possible — it gives browser JavaScript direct access to serial connections, which means everything that used to require a dedicated app or a Python environment can now happen in a tab.
The thing that drove me to build it was anxiety. Every time I flashed a device, I was never quite sure if I was about to brick it. The existing UIs don’t give you good feedback about what’s happening. You’re staring at a terminal, watching output scroll, hoping the right thing is happening. The ESP32 Flasher gives you a clear, step-by-step interface that tells you what it’s doing at each stage. If something goes wrong, you know what went wrong. If it succeeds, you know it succeeded.
That clarity was what I wanted. That’s what I built.
Traction, honestly
I haven’t gotten a lot of traction on these tools yet. I haven’t done much promotion — no launch posts, no community outreach, no SEO work. They exist, they work, and a small number of people have found them and used them. I need to do more posting and more outreach to the relevant communities, and that’s on the roadmap.
I’m saying this plainly because I think there’s a tendency in builder culture to only talk about the things that are working. My open source tools aren’t famous. They’re not getting a thousand GitHub stars. But they solve real problems, the code is clean, and they’re better than the alternatives that existed when I built them.
That’s enough to be proud of.
What open source actually gives you
The obvious thing people say about open source as a portfolio is that it’s “proof of work.” That’s true, but it undersells the real value.
Working open source code proves you can ship. Not design, not plan, not prototype — ship. Something that a stranger can download and run and get value from. That’s harder than it sounds, and most people who call themselves builders have never actually done it.
The less obvious thing is what you learn from real users. When someone files an issue on your repo, or asks a question in a forum, or just uses your tool in a way you didn’t anticipate — you learn something about your own assumptions that you could never have learned by building in isolation. Real usage is brutal and educational in equal measure.
And the least obvious thing: it forces you to think about maintenance and communication, not just construction. Software that’s meant to be used by strangers has to be documented. It has to handle failure cases gracefully. It has to be something you can stand behind in public. Those constraints make you a better builder.
I’ll keep building open source tools. Not because I expect them to go viral, but because building things that work and putting them into the world is a habit worth keeping.
The portfolio is just a side effect.