What Flight Training in Italy Taught Me About Building Products

Flight training in Italy costs roughly EUR 50,000 for a commercial license. That's for the minimum hours. Most students need more than the minimum. At EUR 200-300 per flight hour, every inefficiency (a cancelled lesson, a failed check ride, a misunderstood concept) costs real money.

This economic pressure creates a specific kind of student: one who treats every study session as critical, every flight hour as precious, and every mistake as expensive. It also creates a specific kind of frustration: the tools available to students are terrible relative to the stakes involved.

That frustration became the foundation for everything I've built since.

The Italian Aviation System

Italy's aviation authority, ENAC, follows EASA (European Union Aviation Safety Agency) regulations. The licensing path is standardized across Europe, but the training culture varies by country.

In Italy, flight training is deeply traditional. Theory courses happen in classrooms with textbooks. Exam preparation means reading and re-reading dense regulatory material. Communication between students and schools relies on phone calls and paper scheduling. Progress tracking is manual: logbooks and instructor notes.

This isn't because Italian flight schools are backward. Many are excellent. It's because the regulatory framework doesn't incentivize digital innovation, and the market is small enough that no one has built better tools.

Coming from a generation that grew up with the internet, the gap between how I learned everything else (digitally, interactively, on-demand) and how I was expected to learn aviation (physically, passively, on-schedule) was jarring.

What I Learned About Constraints

Flight training operates under severe constraints:

Weather constraints. You can't fly when the weather is bad. In Italy, particularly during winter, this means weeks where training stalls. Students lose momentum. Skills degrade. Costs accumulate without progress.

Scheduling constraints. Aircraft availability, instructor availability, and weather windows must align. Three-way scheduling is inherently difficult. A booking cancelled by weather can't always be rescheduled the same week.

Cognitive constraints. Aviation theory is dense. The EASA syllabus covers meteorology, navigation, air law, human performance, flight planning, aircraft systems, and more. Each subject has hundreds of pages of material. Retaining it all while simultaneously learning to fly requires structured study habits.

Financial constraints. Every hour counts. Students who don't optimize their study (arriving unprepared for flights, needing extra theory hours, failing check rides) pay literally for their inefficiency.

These constraints taught me something that no startup book ever articulated as clearly: constraints are features, not bugs. When resources are limited, every decision matters more. When every decision matters, quality improves.

In product building, I deliberately maintain constraints. I build alone, which means I can't build everything. I have to choose the most important features. I use a simple tech stack, which means I can't use every new tool. I have to use what I know works. I ship fast, which means I can't polish everything. I have to prioritize what users actually need.

These constraints aren't accidents. They're the product-building equivalent of a flight training budget: a forcing function that makes every hour count.

The Study Problem

The specific pain point that bothered me most during training was exam preparation.

EASA theoretical knowledge exams are standardized across Europe. Every student pilot taking the ATPL (Airline Transport Pilot License) exam answers questions from the same question bank. The questions are known, or at least, the topics are known. The preparation material is available.

But the preparation experience was miserable. Textbooks were dense and dry. Practice question banks were either outdated or poorly organized. There was no adaptive learning. Every student worked through the same material at the same pace, regardless of their strengths and weaknesses.

I was spending hours studying topics I already understood and not enough time on topics I didn't. The study process was linear when it should have been adaptive. It was passive when it should have been interactive. It was isolated when it should have been social.

This problem (bad study tools for high-stakes aviation exams) is exactly why I built Aviation Infinity. The frustration was planted during training, and by 2014 it had grown into a full product on the App Store. Three years later, it's serving students across multiple countries — all because someone needed to build better tools for pilot students. And "someone" turned out to be me.

The Human Factor

One of the most fascinating subjects in the EASA syllabus is Human Performance and Limitations. It covers how humans make decisions, how fatigue affects performance, how stress impacts judgment, and how group dynamics influence cockpit behavior.

The subject exists because aviation learned, through decades of accidents, that most crashes aren't caused by mechanical failure. They're caused by human error: miscommunication, tunnel vision, confirmation bias, authority gradients, fatigue.

Studying human factors changed how I think about building products.

Confirmation bias is why users don't read error messages. They see what they expect to see, not what's actually on the screen. Good product design accounts for this by making critical information impossible to miss, not just visible.

Authority gradients explain why junior developers don't challenge senior developers' code, even when they see problems. Good engineering culture flattens the gradient so anyone can flag an issue.

Fatigue and workload affect digital work just like cockpit work. The cognitive load of a complex UI degrades user performance the same way a busy cockpit degrades pilot performance. Simplicity isn't aesthetic. It's a human-factors principle.

Stress and decision-making explain why users make bad choices during checkout flows or form submissions. They're stressed about the outcome (spending money, committing to a service) and stress narrows attention. Good UX reduces stress by providing clarity and reversibility.

Aviation's human factors curriculum is a masterclass in user psychology. Every product builder should study it.

Learning in a Second Language

I grew up in Rome, speaking Italian. Aviation in Europe operates in English: radio communications, technical documentation, exams, and international operations all use English.

Learning to fly meant learning technical English simultaneously. Not conversational English (I already had that) but technical English. The specific vocabulary of aviation: altimeter settings, instrument approaches, minimum descent altitudes, decision heights, missed approach procedures.

This dual learning experience (mastering a domain while mastering the language of that domain) taught me something about product localization that I apply to every product I build.

Language isn't just translation. The words used in a specific domain carry meaning beyond their dictionary definitions. "Decision height" in aviation means something very specific. It's not just "the height where you decide." Building products for international markets requires understanding domain-specific language, not just general translation.

Context determines comprehension. An Italian pilot reading English technical documentation understands it because the context is familiar. They know the subject, so the language is interpretable. A non-pilot reading the same documentation would be lost. Good product copy works the same way: it needs to match the user's context, not just their language.

Multilingual users switch modes. When I'm flying, I think in English. When I'm coding, I think in English. When I'm talking to my family, I think in Italian. Multilingual users don't need products translated. They need products that respect the mode they're in. An aviation product used by Italian pilots should be in English, because that's the language of aviation, even in Italy.

The Instructor Relationship

The relationship between a student pilot and their flight instructor is one of the most consequential mentorships I've experienced.

A good flight instructor doesn't just teach you to fly. They teach you to think like a pilot. To see risks before they develop. To maintain situational awareness. To trust instruments when your senses disagree. To communicate precisely. To admit when you don't know something.

The best instructor I had never told me the answer to a question. He asked counter-questions until I found the answer myself. "What's the stall speed in this configuration?" I'd answer. "And if we add 10 degrees of bank?" I'd calculate. "And if we're at maximum gross weight?" I'd think harder.

This instructional style (guiding discovery rather than delivering information) influenced how I think about product onboarding. The best products don't dump a user manual on new users. They guide users through discovery, revealing features in context, at the moment they're relevant.

The Foundation

Flight training didn't teach me to code. It didn't teach me about startups or product-market fit or growth hacking. It taught me something more fundamental: how to operate under constraints, how to think in systems, how to make decisions with incomplete information, and how to respect the people who use the tools I build.

Everything I've built since (every product, every feature, every design decision) carries the fingerprints of that training. The discipline. The respect for process. The understanding that tools exist to serve the people who use them, and that the best tools are the ones that disappear into the workflow.

Flight training in Italy cost me EUR 50,000 and two years. It also gave me the operating system I've used for everything since.