I build software with a bias toward usefulness.

My day job is principal-level RAN design — the engineering behind large-scale wireless networks, and about as complex and unforgiving as systems get. For the better part of fifteen years I’ve worked at the seam where that deep engineering meets the standards, tooling, and product decisions that make it usable at scale. The same instinct carries into the products I build on my own time.

From engineering to product

My background is heavy engineering, but my center of gravity has been shifting toward product for a while now. Years of RAN design taught me how systems actually behave under real constraints — cost, deployment, performance, the messy operational truth — and that turns out to be exactly the judgment good product decisions need. I’m most useful where a sound technical call and a sound product call are the same call, and where the hard part isn’t building something that works, but deciding what’s worth building and why.

What I like working on

I’m drawn to problems that are genuinely complex, a little operationally messy, and easy to overbuild — and to making the result useful for the people who rely on it, not just functional. That holds whether it’s tooling used by hundreds of engineers, a product for homeowners, or something quieter for families.

A lot of my best work is unglamorous: noticing where time and attention leak away, then closing the gap with tooling, automation, or a clearer design. It rarely makes a dramatic story, but it compounds.

A little about me

I grew up in Houston, came to Oklahoma for college, and stayed once the job was here. It’s home now — family and all. Off the clock I’m usually building something small and practical; I’ve been known to wire up a sensor just to answer a question nobody else was asking. Same instinct as the day job, lower stakes.