Frontline Flight Ops
No one was trying to tackle the complexities of staffing airline ground operations
With little more than a wing and a prayer (plus a Replit license) I built a full-scale agentic operations platform.
Situation
The Industry Acceleration Team was stood up under the premise that we would work with our own client teams to solve industry problems no one else had. Client teams would come to us as with problems that their clients were facing. We would find solutions using rapid prototypes, MVPs, or actual builds to productize their problems into something real they could invest in.
The team that came to me was working within the airline industry with a direct ask from Emirates Airlines. They had many different products for organizing and staffing day-of and future planning for what's called "under the wing" work.
What is "under the wing"?
"Under the wing" refers to any work done while the aircraft is on the ground: catering, maintenance, flight planning, fueling, cleaning, and more. It excludes anything that happens while the plane is in the air: cabin crew, pilots, etc.
Brand new toolset:
Coming from the government and public sector, the commerical side of the house was able to use all the fun tools. Immediantly I pivoted the team off Figma Make and over to Replit. Knowing Make credit limits were coming, we needed an unlimited tool that had higher quality code output. My toolbox and working patterns evolved quickly:
- Claude - Initial industry research and processes. I was able to tell the client team how Emirates catering worked within hours.
- Google Stitch - Initial design ideation and direction. While it can come out a little bat-shit-crazy sometimes, Stitch pushes new UI direction rather than the stale ideas from Claude and Replit.
- Whispr Flow - For dictation. I don't design with a mouse anymore, I talk. All fuckin day. I needed a solid dictation tool to clean up my 'um's and 'like's.
Task
Airline ground operations is a rapidly changing industry where applications need to take large inflow of data and constantly rework to optimize, all without causing disruption to the teams using to app.
Being that it was around January 2026 (this will be important later), Emirates was in full swing and needed this new application. They were very interested in seeing what we could come up with for a prototype in the short term.
The initial ask was very simple: a modular Gantt chart to take a reactive approach to delayed flights, see how delays cascade across other flights, and a proactive approach to change gates very quickly. That simple Gantt chart request turned into something much larger.
Action
From Gantt chart to staffing platform
The modular gantt chart was easy enough. A click and drag to add, flights movable between the gates, conflict call outs. Bing bang boom, lookin' good! As the project ramped up, more senior folks joined and I found out the real problem to solve for wasn't flight arrangement, but staffing optimization.
Based around staffing availability and employee skills, the system would look at a multitude of variables to determine how to best assign each flight enough people to turn the plane around and get it ready for the next flight within the available time frame at that gate.
To do this, I needed to come up with tiered modules that the system could use to stack data together into a comprehensive task list for every flight.
Application architecture
Everything that could need to be done to a flight was created at the task level, from cleaning the bathrooms to pulling meals out of the freezer. Each task was assigned:
- Time frames: fixed or variable depending on the task. Is that variable dependent on passenger count?
- Required skills: What are the skills or certifications needed to perform this task?
- Staffing limits: how many people could realistically be assigned (is it faster with more staff, or is there a limit to how many people you can throw at the task?)
Flight templates
From there, templates were created for each type of flight (short or long haul, international, domestic, or regional) and aircraft type. The system needed to understand: This is the list of tasks that go into this particular aircraft for this particular type of flight.
Predictive task assignment
The agentic staffing system would take those tasks, put them into the templates, and with real flight data flowing in, match that data to the correct template to generate a predictive task list, ready to assign to staff before the flight ever lands.
Templates applied and confidence levels would be visible to planners to make manual adjustments, or apply a different template.
Agentic elements
Placeholder
Staffing variables
The system considered outages, skill sets, current workload, and physical location of employees when determining assignments. The goal: no employee walking back and forth across the entire airport multiple times in a shift.
Employee mobile app
Employees would use a mobile app rather than the desktop platform. Checking off tasks, viewing their daily workload, and communicating with leadership through their phone.
To reduce the overhead of constantly pulling out their phone, I added a work area check-in, which automatically surfaced the location check-in when the last task in one location was completed. It was a fine line between having the right metrics to optimize the system and having an Amazon big-brother situation with automatic tracking and peeing in bottles. I also added a lock screen widget using Apple's Live Activities, so employees could see their next task, check its status, and take quick actions, all without ever opening the app.
Location and asset tracking roadmap
Our map feature wasn't fully fleshed out due to time constraints, but understanding physical locations of people and assets is important in assignment optimization.
Example: if an employee is driving a high-loader that's low on fuel, the system could account for that and avoid immediately staffing them on a new flight, giving them time to refuel first.
As a proof of concept, I added a Leaflet map themed to the app colors with indicators for people, gates, concourses, facilities and assets. Replit was unable to get the gates in the correct locations, so I built out manual positioning and adding of indicators.
Proposed enhancements
- Staff location updates on map
- NFC tracking for smaller assets to provide real-time inventory updates
- GPS tracking for vehicles to monitor location and IoT sensors for health and maintenance status
- Predictive maintenance alerts and automated work order creation based on sensor data
Demo scenario triggers
For demos I added scenario triggers to show the system in action. Since the application was fully functional at this point, there was no live data inflow, making it appear static during client presentations. These triggers let the team show how the system would react in real time to scenarios like a sandstorm in the Middle East, a staffing callout, or an incoming flight delay.
The pivot
About halfway through the project, geopolitical events in the Middle East slowed, and eventually stopped, the Emirates use case entirely. However, Southwest Airlines had been going through tough times and reached out for help optimizing their workforce. The application switched from Emirates to Southwest.
To future-proof against future airline switches and make the product resellable, the application was also migrated to a generic airline identity, so it could be demoed to any carrier at any time.
The Replit challenge
The largest ongoing challenge was working with Replit. The platform enables quick prototyping but often prescribes mediocre design patterns and inconsistent workflows. A lot of time was spent going back through the design to bring patterns into alignment and make the application feel like a cohesive product.
Simple things like accessibility, color contrast ratios, responsive cards, became items that were iterated on multiple times. Despite migrating to an existing platform's design system, these issues persisted. The eventual fix was generating .md files that dictated which patterns to use when the system could interpret as it wanted versus when it needed to use a specific component.
Result
With the conflict in the Middle East, the Emirates project was cancelled and put on hold, Southwest saw our demo and "decided to build something internally". Which I think means they wanted to steal our idea and get it cheaper. Best of luck SWA! Call me if you need help. As of publishing, Delta is the next demo, so we'll see if they bite.
$15M+ in pipeline sales
resulting from the demo
3 major airlines
pitched to
Reflections
This was a difficult project, my first large-scale rapid prototype using Replit. I had made smaller throwaway applications before, but this one became so complex and realistic that Replit eventually turned it into an actual product. That changed how even a rapid prototype should be approached from a design standpoint.
Ready, fire, aim
The process became a ready-fire-aim approach, with heavy emphasis on the re-aiming and re-firing. Lots of rework. Lots of iteration. This surfaced new conversations about what timelines can and should be with rapid prototypes, especially when the application shifts from dummy data toward realistic, live functionality. The testing phase started feeling more like an actual QA cycle than a design review.
Feedback at 60mph
Unbiased design feedback became a real challenge. Going from zero to a fully functioning application meant leadership and clients were suddenly shown a polished, working product with no gradual ramp-up. Getting objective feedback was hard. Even I had trouble decoupling the high-fidelity working prototype from my own expectations of what a design "should" look like versus what was actually in front of me.