What I build, and what I build on
Platform thinking starts with being intentional about your foundation: what you create, what you borrow, and how it all fits together.
Open-source pieces of a connected-product platform
A connected product spans firmware, an edge gateway, and the cloud. These are building blocks I created to solve common needs.
Simple IoT
An application and framework for connected systems. One Go binary runs in the cloud and on embedded Linux gateways, with configuration and data synchronized between them.
yoe build
An efficient embedded Linux build system and infrastructure, optimized for small teams building complex edge systems. Built on OpenEmbedded and Yocto.
GitPLM
Product lifecycle management in Git. Part numbers, BOMs, and releases live as plain files in version control, so hardware and software follow one workflow.
HFID
Human-friendly industrial device IDs: a practical scheme for identifying and tracking versions, parts, units, and locations across the life of a product.
Smaller tools that earn their keep
Focused tools from the device end of the system and from the workflow around it.
Simple IoT for Zephyr
Brings Simple IoT patterns to the Zephyr RTOS, so MCU-class sensors and controllers join the gateway and cloud as one system.
Zephyr SNMP
SNMP support for the Zephyr RTOS, for devices that need to participate in managed industrial networks.
Yoe Kiosk Browser
A full-screen browser for embedded Linux kiosk and HMI displays, designed to drop into a Yoe or Yocto/OE image.
linux-serial-test
A utility for stress-testing Linux serial ports: throughput, latency, and error rates. Packaged in Buildroot and widely used for board bring-up.
brun
A simple way to define and run native build workflows. No containers required.
Claude Code plugins
Plugins for Claude Code that encode development workflows, so AI-assisted work follows the same process as the rest of the team.
Ansible roles
Roles for the self-hosted infrastructure a small team runs alongside its product: Gitea, Caddy, Grafana, InfluxDB, and more.
The foundation
When you borrow a tool, you also borrow the process behind it: the maintainers, review, CI, and security response that keep it healthy. That makes choosing your foundation one of the highest-leverage decisions in a product. Here is what I currently reach for, and why.
One language from cloud to edge: static binaries, painless cross-compiling, and a standard library that covers most of what a connected system needs.
The glue: scripts, data processing, and quick tools around the main system.
The language of the metal. Vendor SDKs, drivers, and the timing-critical paths inside a Zephyr application all live here.
A frontend language with no runtime exceptions. The Simple IoT user interface is written in it, and refactors stay safe as the application grows.
The pragmatic choice when a project needs the wider JavaScript ecosystem, or has a team that already knows it.
A modern RTOS with a real build system and an active community, for MCU-class devices.
The build framework under yoe build, flexible enough to produce exactly the Linux system a product needs.
Toradex, Variscite, and others have already solved the hard part of a reliable industrial computer. Starting from a module keeps the product board simple and shortens the path to market.
Reaches equipment where no network exists. LTE-M and NB-IoT modules have made this practical for deployments of any size.
Messaging and data synchronization that runs equally well in the cloud and on an edge gateway. The backbone of Simple IoT.
Dashboards for everything a running system produces.
Efficient time-series storage that stays small enough for modest hardware.
A web server with automatic HTTPS, simple enough to trust in front of everything.
Repeatable server and edge deploys, stored as plain text in Git.
Straightforward Linux servers at predictable prices, sized for a small team. Support answers when I need a person, something that is harder to come by on the large clouds.
The same role as Linode. Running on two providers keeps any single host from becoming a dependency.
The center of the workflow for everything: software, hardware designs, documents, and this website.
Self-hosted Git, issues, and CI. It runs on one modest server, and keeping the place the work lives under my own control means no part of the workflow depends on a vendor's plans.
Open-source electronics design, with file formats that Git and AI agents can work with directly.
Open-source mechanical design, chosen for the same reasons as KiCad.
An AI agent that reads and writes the same open file formats I do. Open tools matter more every year for exactly this reason.
Documentation that lives in the source repository as plain Markdown and builds into a searchable site. Docs travel with the code, review like code, and stay current because updating them is part of the same commit.
Where a Word or LibreOffice document used to go. Datasheets, manuals, and application notes are Markdown content plus a Typst template that carries the layout and typography, and the two combine into a professional-looking PDF. Product documentation then lives in Git beside the product, reviews as a diff, and rebuilds from a single command.
A fast static site generator. This site and several others run on it.
Could you write this page for your product?
Great products stands on great platforms. If you would like help defining yours — what to build, what to borrow, and how it all fits together — I would enjoy the conversation. The rest of my public work lives on GitHub, and the same thinking applied to running the business is on the BEC OS page.