MTOW FAC

A captain of the Colombian Air Force reached out to me after an aircraft accident brought attention to a fragile part of the pre-flight routine: crews were computing the maximum takeoff weight (MTOW) of the C-295 aircraft by hand, reading values off printed performance charts and interpolating between them under time pressure. In aviation, a takeoff computation error does not forgive.

He explained the operational problem, and gave me the official performance data and the exact computation methods used by the Air Force for the C-295. My job was to turn that material into a tool that was fast enough to be used in the cockpit and faithful enough to be trusted: same inputs, same numbers as the charts, every time.

An application the pilot opens, fills in with the conditions of the day, and reads a decision from. The pilot picks the aerodrome, enters the outside air temperature, the pressure altitude, the available runway length and the wind component, and states whether the runway is dry or wet. The application immediately returns the authorized takeoff weight, which factor is limiting it, the required runway length, and the other figures needed to validate the takeoff.

Key features I put in place:

• Three takeoff modes : Normal takeoff, Short field takeoff, and CAPS 2017, which reads directly from the Air Force's technical charts. Each mode has its own data, its own thresholds and its own rules.
• Calculation engine : The engine reproduces the manual procedure step by step using the official formulas and tables. It is fully typed, versioned, and tested, so the results are always correct and traceable to the source.
• Limiting factor and operational status : Beyond the number, the application tells the pilot why the weight is limited (runway, climb gradient, both, or neither) and shows a color indicator.
• Data extraction from the official spreadsheets : The charts were delivered as Excel workbooks. I converted them into typed, versioned data tables embedded in the application.
• Cockpit-oriented interface : Dark theme, large touch targets, high-contrast readouts, and results laid out so the decisive number is the first thing seen.
• One codebase, three platforms : iOS, Android and browser from the same source. In practice it is used as a web application: no installation, no app store, and an update reaching every pilot instantly.
• Deployment : Deployed on Vercel as a static web build, connected to the repository so every change is published automatically.

The captain uses the application on a daily basis. It then spread on its own: first to the pilots of his crew, then to other crews. What used to take several minutes of manual chart reading, with a real risk of error, now takes a few seconds.

This was also a good opportunity for me to work in a domain I did not know. Since I had no aviation background, a big part of the work was reading the Air Force's charts and procedures until I could state the rule precisely enough to encode it, and going back to the pilot whenever a chart was ambiguous, rather than guessing.

The project was a reminder that software engineering is not just about writing code. It is about understanding the problem, the context, and the people who will use the solution. It is about making decisions that balance technical constraints with human factors, and about delivering a product that is not only functional but also usable and trustworthy.

Most of my projects, at INSA Lyon or elsewhere, are academic or client work. Building something that active pilots rely on to secure a takeoff is a different kind of responsibility, and it is the project that reminded me most clearly why I chose computer engineering.