I build systems from the ground up, usually somewhere at the intersection of
software · infrastructure · embedded hardware · electronics

I like understanding the whole stack. That might mean designing the PCB, writing the firmware, reverse-engineering an undocumented protocol, building the backend and UI, then deploying the infrastructure it all runs on.

Sometimes because that's the right architecture.
Sometimes because somebody said "there's no API."

I design custom hardware and the software that runs on it.

• PCB & circuit design · KiCad, power distribution, protection and sensing
• Embedded platforms · ESP32, Silicon Labs MCUs
• Connected devices · Matter-over-Thread, MQTT
• Power electronics · MOSFETs, gate drivers, high-current switching
• Hardware interfaces · I²C, SPI, UART, ADC
• Firmware · development, bring-up and hardware debugging
• PCB engineering · RF-aware layout, grounding and high-current routing
• Precision control · high-frequency PWM and smooth LED dimming

A 6-channel, high-current Matter-over-Thread LED controller designed from the power and protection architecture through the switching hardware, PCB, firmware and eventual home-automation integration.

Schematic → PCB → firmware → network → application

Apparently buying a dimmer would have lacked educational value.

I'm particularly interested in hardware and software that wasn't designed to be understood outside its original ecosystem.

• ARM/Linux firmware analysis with Ghidra
• Decompiled binaries and undocumented application behavior
• Firmware extraction and embedded filesystems
• Proprietary protocols including MQTT-based device communication
• Binary state formats and internal APIs
• Serial/debug interfaces and hardware investigation
• Cloud replacement with local-first control paths

I've reverse-engineered commercial IoT hardware from its firmware, binaries and internal state representation, then built native agents and Home Assistant integrations around the resulting local control path.

"Not supported" and "not possible" are wonderfully ambiguous phrases.

I'm building a cryptocurrency market-data and quantitative research platform rather than another wrapper around an exchange API.

Market feeds → raw immutable events → validation → parallel normalization → Parquet → research

The system handles:

• High-throughput asynchronous capture from multiple market-data providers
• Raw event storage preserving provenance and event timing
• Trades, pricing and Level 2 order-book data
• Incremental depth streams, partial-depth observations and reconstruction checkpoints
• Parallel parsing, validation and normalization
• Canonical columnar datasets for reproducible downstream analysis

A recent pipeline run processed more than 100 GB of raw recorded market data into validated, normalized and organized Parquet datasets ready for:

market replay · backtesting · feature generation · quantitative research · ML

Turns out get_candles("BTC") wasn't quite enough.

I build the applications and tooling around these systems too.

Languages

Python · Go · Rust · TypeScript · C · C++ · SQL · Bash

Applications & systems

React · Next.js · Node.js · REST APIs · async services · data pipelines · CLI tooling

Beyond application development, I've been building infrastructure for AI-assisted software engineering:

• Isolated execution environments
• Separate Unix identities and credentials
• Explicit permission boundaries
• Controlled remote execution
• Just-in-time privilege approval
• MCP tooling and lifecycle management
• Testing and deployment automation

The goal is to give coding agents genuinely useful capabilities without also giving them the keys to the kingdom.

chmod 777 is not an authorization model.

Calling it a homelab is becoming increasingly charitable.

At the center is a 96-core / 192-thread AMD EPYC 9654 virtualization server running Proxmox, backed by enterprise NVMe storage and ZFS.

Because a rackmount server would have been far too reasonable, the EEB platform is crammed into a Lian Li O11D EVO XL with:

• AMD EPYC 9654 · 96C / 192T
• Enterprise NVMe storage
• ZFS storage architecture
• Custom water cooling
• EK hardware, ZMT tubing and quick disconnects
• 3× 360 mm radiators
• Dedicated airflow for the motherboard and enterprise storage
• RGB, because apparently the datacenter needed ambiance

The network surrounding it has undergone a similar failure of restraint:

Fiber uplinks · 10 GbE switching · VLAN segmentation · high-speed storage/network paths

The rest of the infrastructure includes:

• Proxmox virtualization across VMs and LXC
• ZFS and high-capacity enterprise storage
• 10 GbE fiber and copper networking
• Managed switching and network segmentation
• Internal DNS and automated service discovery
• PKI and automatic certificate issuance/deployment
• Cloudflare Tunnel, Access, WARP and Zero Trust networking
• SSH identity separation and least-privilege access
• systemd services, reverse proxies, monitoring and backups

Internal services get real hostnames and publicly trusted TLS. Certificates renew and deploy automatically, and private networks remain securely reachable remotely without exposing the services themselves to the public Internet.

At some point I stopped having a home network and started operating
a tiny datacenter in a spare bedroom.

_{The electricity bill was apparently informed before I was.}

I build things because I want them to exist, reverse-engineer things because someone decided they shouldn't be documented, and automate things because doing the same task twice feels suspiciously like a software bug.

Current uptime of my relationship with scope creep: 100%