Hardware development · Ketchikan, Alaska
Custom flight controllers, embedded systems, and sensor networks — schematic, layout, bring-up, firmware, and the backend the data lands in, all from one bench. Built for places where the signal drops and the weather doesn't cooperate, because that's where I test them.
What I build
Small-run and prototype work where the electrical, embedded, and application layers all have to agree with each other.
Custom FC boards on STM32H7, working from the FMUv6 reference lineage, targeting PX4 and ArduPilot. NDAA-compliant sourcing throughout, with the BOM costed across tiers before anything gets routed — so you find out what it costs at schematic, not at fab.
Bare metal through RTOS. Drivers, bootloaders, sensor fusion, and the unglamorous power and timing work underneath it.
MAVLink hub-and-spoke fleets with clean addressing, and LoRa mesh for long-range low-power sensor networks off the grid.
GNSS and RTK, IMU, sonar, environmental. Getting the reading off the device, through the link, and into a database that answers questions.
Coordinators, mission planning, telemetry ingest, and the dashboards that make a fleet legible to whoever's responsible for it.
RTK/PPK aerial survey end to end — flight plan, capture, processing, and a deliverable someone can actually use.
Why one bench
Not at the schematic. Not at the layout. At the seam between the people who own each layer — where everyone's piece works and the system doesn't.
Every seam is a place for a spec to get lost, and every fix crosses three invoices.
Fewer people is a real constraint on throughput. It's also why the seams don't leak.
How it runs · five legs
Hardware punishes surprises. Every leg ends with something you can hold, read, or run before the next one starts.
What it has to do, where it has to survive, what it can weigh, and what it can cost per unit.
Parts chosen for availability and compliance, not just spec. Costed across tiers before layout starts.
Routing, DFM review, boards ordered and assembled. Lead times are what they are and you'll see them up front.
Power on rail by rail, then drivers, then the application layer. Documented as it happens.
At real range, in real rain, on real water. Bench results are a hypothesis until then.
Straight answer
Hardware is slower and more expensive than software. That isn't a sales problem, it's physics.
A code revision costs an afternoon. A board revision costs weeks, a minimum order, and another round of bring-up. So the first question I'll ask is whether your problem can be solved with software on hardware that already exists — an off-the-shelf flight controller, a commercial sensor, someone else's radio. Often it can, and I'll say so.
Custom silicon earns its keep when the off-the-shelf part doesn't exist, can't be sourced compliantly, costs too much at volume, or won't survive where you're putting it. Those are real and I've hit all four. They're just rarer than people expect.
Start a conversation
Napkin sketch or half-finished prototype, both are fine. First conversation is free and ends with an honest read on feasibility, rough cost band, and whether custom hardware is the right answer at all.
I've got it. I'll reply within one business day with a first read and a few questions worth answering before we talk.
Napkin sketch to flying prototype.
Start