I build tools
people want
to use.

I grew up around computers. My stepfather was an IBM systems analyst, and I was the kid skipping the DOS boot floppy on a PC Jr. to write BASIC directly to memory. Nothing saved, nothing elaborate, but the curiosity was always there. I ultimately went on to pursue a career in other fields, but that curiosity never went away, and computing became a serious hobby long before it became something I built real products with.

Over time those problems got more specific: a fleet that needed better reporting tools, a market that needed better data dashboards, a business that needed a platform to sell them, and all the other little tools, sites, and apps along the way. Each one taught me something the last one didn't. I've built things that never fully worked as envisioned, over-engineered things that could've been simple, and assumed I knew what users needed without asking. Those failures are more instructive than any course, and I've become a better developer for it.

Twenty years in aviation operations — as a pilot, fleet/resource manager, and daily user of systems spanning maintenance, dispatch, scheduling, regulators, etc., to make real-time decisions affecting real outcomes. The result is a different kind of product intuition than I'd suspect most developers to have. I understand systems under pressure, the cost of bad information at the wrong moment, and the importance of building something that people can depend on rather than just use. This is the context that shapes how I approach product design even when the domain has nothing to do with aircraft.

Good software does what the user actually needs, gets out of the way, and doesn't make them feel stupid for using it. That's a low bar that a surprising number of products fail to clear. My mission has never been about fixing bad software as much as not adding to the pile.