I help small teams build connected products.
A handful of capable engineers building real hardware that senses, controls, and talks to the cloud. A small team has no business being slower than a big one. I show — in public, with tools you can run today — how a team that size ships its first release and keeps shipping updates for years.
Capable engineers who are stuck shipping.
You have good people and real hardware, but getting a product out the door — and keeping it updated in the field — is harder than it should be. Most teams I help arrive one of two ways.
Already shipping, but the build fights back
Builds take hours, a small change rebuilds the world, and field updates feel like a risk event. You know the build system has become the bottleneck and you want a way out.
New to embedded Linux
A hardware or software company crossing into Linux for the first time, where the early architectural choices lock the product in for a decade. Better to make them on purpose.
The real filter is not where you came from. It is whether you have someone inside who wants to change how the team works and wants foundations the team can own and grow — not someone to hand the work to. That is who I do my best work with.
The idea behind everything I build
Don't just borrow other people's tools — borrow their processes.
When you eat at a restaurant, you don't hire the waiter, run the supply chain, and buy the ingredients. You buy the whole system, and that is what makes it useful. A package isn't just a file; it is the visible artifact of a process — maintainers, code review, CI, security response, release engineering. The win isn't reusing the code. It is reusing the work.
Three principles that hold across every project.
The tools change. These don't. Everything I make reinforces at least one of them.
Reuse the work, not just the code
Take the people, CI, security response, and packaging that produced a thing — not just the thing. Debian, Ubuntu, and Alpine already run that process across their whole catalog. Small teams should stand on it, not rebuild it.
Shipping is a capability, not an event
Decouple the pieces so each moves at its own pace. Get the first release out, and keep the updates flowing reliably after. Shipping once is luck; shipping again and again is a system you can build.
Be intentional about the foundation
How you put a system together matters more than what is in it. A platform is less about inventing everything and more about choosing what to build, what to reuse, and how it all fits.
You do not have to own the whole stack.
The instinct to build everything from source, in one big self-sufficient system, made sense in its time. For a small team today it is quietly fatal — it turns capable engineers into full-time maintainers of plumbing other people already maintain better. There is really nothing holding a small team back except its own ability to put the right pieces together.
Three ways to work together.
I present through my work. Some people teach through workshops or conferences; I build useful open-source tools and show the seams — the parts that worked and the parts that didn't.
Change how your team ships
Not billable hours against someone else's build system. We work on how your team ships — the build, the deploy, the field updates — and leave you with foundations you own and can grow. Ideally starting with a small, low-commitment first step.
Start a conversation →The tool, built in public
A next-generation embedded Linux build system: fast native builds, no cross-compilation, language-native package managers, and AI as a first-class interface. It is the operational proof of everything on this page, and every release is a public artifact.
Explore yoe build →Thinking out loud, daily
The long-form argument for leadership, plus a daily practice where I think through the problem in the open. Every piece goes out with a question: here is what I wrote, what did I miss?
Read the daily →Twenty-five years shipping connected products.
I'm not the best coder, the best Yocto debugger, or the best salesman — and I'll tell you so. What I know is what works when a small team has to build a real product and keep it running in the field. I've helped a lot of teams do exactly that.
Built in public
yoe build and the daily writing are open where anyone can watch the work take shape, seams and all.
Real engagements
Version control, OTA updates, and platform foundations delivered to teams shipping real hardware — Precision Planting, Levelstar, Radiant, Zoll, and others.
Open-source track record
Long-time contributor and maintainer across embedded Linux and IoT, including the Yoe Distribution and Simple IoT.
Let's build something that ships.
If any of this resonates — a product you're trying to get out the door, a build that fights you, or a foundation you want to get right from the start — I'd like to hear about it.