AIsle0

Aircraft turnarounds are one of the most logistically dense moments in aviation. In the window between a plane landing and taking off again, you have ground crews handling fueling and baggage, flight crews running pre-departure checks, and service teams working in parallel, all on the same aircraft at the same time. The problem is that these groups rarely have a shared, flight-specific way to communicate. They rely on fragmented tools, radio calls, and assumptions, which leaves a lot of room for delays, equipment conflicts, and missed steps.

AIsle0 was our attempt to close that gap. The idea was simple: connect every worker to their flight number and give everyone a live view of what is happening across the turnaround. Fueling in progress, baggage loaded, equipment checks pending, all visible in real time across both web and mobile. When one crew updates their status, every other crew on that flight sees it instantly.

On the frontend, we built a web dashboard in React and TypeScript using Vite, and a mobile app in React Native with Expo so ground crews could get updates directly on their phones while out on the tarmac. Both clients pulled from the same backend, which was built entirely on Supabase, handling authentication, the Postgres database, WebSocket connections, and edge functions. For hosting we used Render, we integrated the American Airlines API to pull live flight data, and we wired in the ElevenLabs API so crews could hear task updates read aloud hands-free while working on the tarmac.

The data model was designed around inspection sessions tied to a specific flight number. Each session tracked individual step instances, so multiple crews could update their own tasks simultaneously without interfering with each other. Every step had its own status, photo reference, and an AI-generated severity tag that came from our OpenAI integration.

The hardest technical challenge was real-time synchronization. Supabase has built-in real-time features, but they did not map cleanly to what we needed for this kind of multi-client, multi-crew workflow. We ended up building custom WebSocket logic to make sure the web and mobile clients stayed in a consistent shared state even when several crews were updating tasks at once. On the design side, we leaned into custom illustrations and GIFs to make the interface feel approachable, because airline operations involve a lot of dense procedural information and we wanted the UI to communicate that clearly without feeling like enterprise software.

Rather than a single prompt-and-response setup, we broke the intelligence into three separate agents, each with a distinct responsibility, all running inside Supabase Edge Functions and powered by OpenAI.

Ambiguous state is not just a UX problem, it is a safety problem.

• Analysis was the first to run whenever a crew member submitted an inspection update. It took the raw input and made sense of it in the context of the broader turnaround, understanding what had already been completed and what the current step was reporting. The goal was to turn unstructured field input into something the rest of the system could reason over.
• Planning used that output to think about sequencing. Turnarounds have dependencies, and certain tasks cannot happen simultaneously. The planning agent looked at the current inspection state and surfaced what crews should prioritize next, helping teams get ahead of bottlenecks before they happened.
• Risk & Tagging ran in parallel with a narrower focus. It evaluated each step for potential hazards and assigned a severity tag that persisted in the database and showed up across the dashboard in real time. Supervisors could immediately see where risk was accumulating without reading through every update manually.

Together the three agents worked silently in the background. Crews just did their jobs, and the system handled the rest.

Going into this, we underestimated how complex real operational software actually is. When you are building for environments where safety constraints are real, teams are working in parallel under time pressure, and the cost of miscommunication is a delayed flight, every design decision carries more weight.

From a technical standpoint, building real-time systems under a 24-hour deadline taught us a lot about making fast architecture decisions and committing to them. We did not have the luxury of iterating slowly, so we had to get the data model right early and build confidently from there. It also pushed us to get comfortable with WebSockets, database synchronization, and cross-platform development all at once, which was a lot to hold in your head but genuinely rewarding to ship.

Full turnaround task coverage beyond fueling and baggage, role-based permissions per crew type, an analytics dashboard to surface bottlenecks, and maybe even a million dollars in funding, who knows :)