From Aviation to Startups: Why a Pilot Started Building Software

When people hear that I studied aviation and now build software products, they assume I changed careers. That I "left" aviation for tech. That the two chapters of my life are separate stories.

They're not. Aviation didn't lead me away from building. It led me directly to it.

The instincts that make a competent pilot (systems thinking, checklist discipline, decision-making under uncertainty, respect for constraints) are the same instincts that make a competent builder. I didn't switch careers. I translated skills from one domain to another.

Here's how that translation happened.

The Cockpit as a Systems Lab

A cockpit is a system of systems. Engine instruments, navigation displays, communication radios, flight controls, weather radar, fuel management, all interconnected. A change in one system affects others. Reduce power and you lose altitude. Change heading and you change your fuel calculation. Extend flaps and your approach speed changes.

Pilots don't manage these systems individually. They manage the relationships between them. The mental model isn't a list of instruments. It's a map of dependencies.

Software is the same thing. A web application is a system of systems: database, server, API, client, authentication, caching, CDN. Change the database schema and the API responses change. Change the API and the frontend breaks. Add caching and the consistency model shifts.

Good developers, like good pilots, think in systems. They don't fix a bug in isolation. They trace the bug through the system to understand what caused it and what else it touches. This systems thinking isn't something I learned in a computer science class. I learned it at 3,000 feet, managing a cockpit full of interdependent instruments.

Checklists and Processes

Aviation runs on checklists. Before every flight, pilots run through pre-flight checks: control surfaces, fuel quantity, oil pressure, tire condition, navigation equipment. Before every landing, another checklist: gear down, flaps set, speed correct, runway clear.

These checklists aren't for beginners. The most experienced pilots in the world (airline captains with 20,000 hours) use the same checklists as student pilots with 20 hours. The checklist isn't a learning aid. It's a safety net.

When I started building software, I instinctively created processes. Deployment checklists. Code review steps. Database backup procedures. Testing sequences. Not because I'd read about software engineering best practices, but because aviation had wired my brain to distrust memory and trust process.

The developers I've met who resist process ("I don't need a checklist, I remember everything") remind me of the pilots who skip pre-flight checks. They're fine until they're not. And when they're not, the consequences are expensive.

Decision-Making Under Uncertainty

Flying teaches you to make decisions with incomplete information.

Weather can change between your briefing and your arrival. Air traffic control can reroute you mid-flight. An instrument can fail at the worst possible moment. Turbulence can appear where the forecast said smooth air.

In every case, the pilot has to decide: continue, divert, hold, or go around. The decision can't wait for perfect information. The airplane is moving. The fuel is burning. The weather is evolving. You decide with what you have.

Building products requires the same skill. Should I build this feature or that one? Should I use this architecture or that one? Should I launch now or wait for polish? The information is always incomplete. The market is always moving. The competition isn't waiting for your analysis.

The aviation training that helps most isn't the flight training. It's the decision-making training. Aeronautical decision-making, or ADM, is a formal discipline. It teaches pilots to recognize hazardous attitudes (macho, invulnerable, impulsive, resigned, anti-authority), evaluate risk systematically, and act decisively despite uncertainty.

I use ADM principles every day in product building. When I catch myself saying "it'll be fine, ship it," that's the invulnerable attitude. When I catch myself gold-plating a feature because I'm nervous about the launch, that's resignation disguised as perfectionism. The framework is aviation-specific, but the self-awareness it builds is universal.

Respecting Constraints

In aviation, constraints are non-negotiable. You can't exceed the aircraft's maximum speed. You can't fly below minimum altitudes. You can't land on a runway that's too short. You can't fly into weather your aircraft isn't equipped for.

These constraints don't feel limiting. They feel clarifying. When the boundaries are clear, the decisions within those boundaries become easier. You don't waste time considering options that aren't available. You focus on the options that are.

Software constraints work the same way. A limited budget. A small team. A deadline. A technical limitation. The instinct is to see constraints as problems. The aviation instinct is to see them as parameters that simplify decision-making.

When I build products as a solo founder, the constraints are severe: one developer, limited budget, finite time. I don't fight these constraints. I design within them. I choose simpler architectures because I'm maintaining them alone. I ship features faster because I can't afford long development cycles. I pick proven tools because I don't have time to debug novel ones.

These constraints make my products better, not worse. They force clarity, simplicity, and focus, exactly like the constraints of a cockpit.

The Specific Moment

I can trace the shift from "I fly airplanes and sometimes code" to "I build products and sometimes fly" to a specific realization: the tools I was using as a pilot were terrible.

Flight planning software was outdated. Exam preparation platforms were clunky. Communication between pilots and flight schools was stuck in the previous century: phone calls, paper forms, bulletin boards.

I knew the domain. I knew the pain points. I'd been building iOS apps since 2008 and had recently started building for the web. The gap between "what exists" and "what should exist" was enormous.

That gap drove Aviation Infinity, which I'd been building since my aeronautical high school days. Then AvioSharing. Then New Pilot Shop. Each one started from the same place: a pilot's frustration with tools that didn't respect the pilot's time or intelligence.

What Aviation Gets Wrong About Technology

The aviation industry's relationship with technology is complicated. On one hand, aviation is one of the most technologically advanced industries in the world. Modern aircraft are flying computers. On the other hand, the ground-side tools (the software that supports training, operations, planning, and communication) are decades behind.

This isn't because aviation is anti-technology. It's because aviation is correctly cautious about change. Regulatory requirements, safety culture, and conservative institutional norms create legitimate friction for new technology. A new flight planning app needs to be right every time, not just most of the time.

But caution shouldn't mean stagnation. And that's what happened in many areas of aviation software: the tools stopped evolving because the regulatory environment made evolution difficult. The result is an industry where the aircraft have glass cockpits with synthetic vision and the training materials are PDFs from 2005.

I build products in that gap. Where the technology should be modern but isn't. Where pilots deserve better tools and the industry hasn't delivered them. Aviation taught me the constraints. Software taught me the solutions. Combining both is what I do.

The Translation

If you're in a technical field outside software (aviation, medicine, law, engineering, finance) and you're thinking about building products, the translation is more natural than you expect.

Your domain expertise is the hard-to-acquire asset. Software skills can be learned. Frameworks can be studied. Deployment platforms make shipping easy. But understanding the nuances of an industry (what the real problems are, what solutions the users will trust, what regulations constrain the design) takes years to develop.

I didn't leave aviation to become a software developer. I became a software developer because aviation needed one who actually understood aviation.

That's the advantage. Not the code. The context.