What autonomous aircraft taught me about shipping products

I spent the first part of my career building systems where a wrong answer can put an aircraft in the wrong airspace. The second part has been building web and mobile products. People keep asking how different they are. The honest answer: the math is different, the discipline transfers almost entirely — and the products are better for it.

1. A number without a confidence is a guess

In autonomy, a point estimate with no uncertainty attached is considered unfinished. So when my client dashboards show a metric, they increasingly show its behavior too — ranges, not single pixels. A forecast of "60 minutes of legal flight" beats a green light that flickers whenever the wind model updates.

2. Latency is a material, like wood or steel

A reaction the operator can perceive is a reaction that must be designed. The same attention that goes into a 40 ms control loop goes into a 300 ms hover state: users read when something moves as fluently as what it says.

3. Write the failure mode first

Before any feature ships, autonomy teams ask: what does this do when the sensor lies? Translated to products: what does this do when the API is slow, the network dies, the input is hostile? The CollectKit sync queue exists because the honest answer to "what happens with no signal" was once "bad things."

4. Verification is not a phase, it's the product

Autonomy doesn't ship on "it flew once." Yet web teams ship on "the demo looked good." The eval harness I wrote about is the same instinct on the web side: a merge gate that asks did this make the system's claims true or false?

5. Calm interfaces survive long flights

Cockpit design learned, the hard way, that every extra animated element steals one unit of attention from the anomaly that matters. So the UI language I keep building toward is quiet by default and loud on signal. Green pulses only when a human would sign for the status. Progress bars only when the wait is real. Color when it means something.

Safety-critical engineering is just product engineering with the stakes admitted out loud.

If you're working on something with the stakes admitted out loud, I'd like to hear about it.