The Coming Reckoning in Private Aviation Software

Notes from inside the cockpit of the back office. Why the platforms running charter, maintenance, and dispatch are sitting on the most valuable data in business aviation and treating it like a museum exhibit, and what comes next.

The industry that looks like the future and runs like 1998

I have spent the last several years inside private aviation. Not as a passenger flipping through the in flight magazine. Inside it. Charter sales. Maintenance. Tech ops. Accounting. Pilot management. SaaS development for booking and flight management. ETL pipelines pulling aircraft maintenance data out of Oracle and into Amazon RDS. Running the entire marketing spectrum for aviation companies.

From the outside, the business looks like the future. Carbon composite airframes. Avionics packages that cost more than a starter home. Cabins finished by craftsmen who have been bending sheet metal and stitching leather since their grandfathers did it. Hangar walks where the cheapest thing in the building is the coffee.

From the inside, the back office looks like a regional insurance broker that has not been audited since the Clinton administration. PDFs. Faxes. (yes, faxes!) Emails with attachments named "Final_v3_USE_THIS_ONE.xlsx." Dispatchers retyping the same trip into three systems because none of them speak to each other. Maintenance controllers exporting CAMP reports into Excel so they can pivot the data the way they actually need to see it. Charter sales reps tabbing between Avinode, the operator's flight management system, a CRM that nobody finishes setting up, and a Slack channel that functions as the real source of truth.

This is the industry that moves billionaires, fortune 500 executives, organ transplants, and presidential candidates. And the software running its operational core would embarrass a mid market trucking company.

It is also, in my opinion, on the clock.

What I actually did, and why I am writing this

The ontology lesson, learned in a factory

Before any of this I was in manufacturing. My employer was a supplier into a Department of Defense prime contractor, which means our shop floor and our shipping dock and our quality system all had to plug into a much bigger machine on the prime's side. That is where I cut my teeth on real operational technology problems. Not marketing problems. The kind of problem where a bad data flow does not cost you a campaign. It costs you a missed delivery on a program that has the government as its customer, and the conversation that follows is not pleasant.

The prime had built its entire operational backbone on a then largely unknown provider called Palantir.

The name carries weight now. It did not then. Outside a narrow circle of defense and intelligence work, almost nobody had heard of them. To me, sitting on the supplier side of a contract, they were the strange thing the customer used. My job was to make our data flow into their picture of the program. The polite phrase for what I did next is that I observed their methodology closely. The honest phrase is that I leeched of how they were doing things.

What I learned was a worldview, not a product. The single idea organizing everything they did was the ontology.

The methodology is simple to state and brutally hard to execute. You take every siloed piece of data across an enterprise. Every system of record. Every spreadsheet. Every PDF. Every export. Every dark database in a closet somewhere that one guy in operations knows the password to. You extract all of it into one unified semantic layer. Not a data lake. Not a warehouse with the same silos rebuilt in a new location. An ontology. Entities, relationships, properties, modeled to match how the business actually thinks about itself.

Once that work is done, and only once that work is done, the real work begins. Because from there any business logic, any workflow, any analytical question, any automation, any agent, can be built on top of a single coherent picture of the operation. The ontology is the unlock. Everything else is downstream.

I took that lesson back to my own employer. I applied what I could in a manufacturing context that had never thought about itself that way. And I have carried that thought process with me ever since. The forward deployed engineer title did not exist yet, but the job did. The job was sitting with staff and personnel day in and day out. Watching how they actually worked, not how the org chart said they worked. Mapping where information lived, where it broke, where it got retyped, where it died. Automating across departments that had spent years convincing themselves they were too different to integrate. The job was never the technology. The job was the patient anthropology of an operation, and then the engineering to make the operation coherent.

Aviation, where the silos hide behind a hangar door

That is the lens I brought into aviation. Twenty plus years across multiple industries, and a methodology that says the data is already there, the silos are a choice, and the unlock is the ontology.

My first deep operational exposure to the industry was at Noble Air Charter.

I was hired to handle marketing. Within a few months I was doing what every technically inclined person at every operator in this country ends up doing, which is quietly building the connective tissue the vendors refused to build. The clearest single afternoon of my aviation career was the one I spent sitting next to the Director of Maintenance, watching him input aircraft data.

Component serial numbers. Cycle counts. Time since overhaul. AD compliance. Inspection due dates. Every field entered by hand, into platforms designed in an era when fax machines were still considered an upgrade. The equipment being tracked was multi million dollar pressurized metal flying at 41,000 feet. The interface tracking it looked like a county clerk's office in 1998.

That afternoon is when I understood what was actually broken. The data was not missing. The data was being captured by a human typing into a form that nobody had touched the UX of in fifteen years, and then captured a second time by a different human typing into a different form in a different platform, because the two platforms that both billed the operator a fortune still refused to talk to each other.

So I went and built.

The single piece of work I am most proud of from Noble, and the one I went on to carry to every other operator I worked with that used the same platform, was a custom data ingestion mechanism I built against JetInsight. The vendor refused to publish an API. Refused. A platform sitting at the operational core of charter operators across the country, holding trip data, scheduling data, dispatch data, post flight data, and the company would not let an operator programmatically pull its own data out in real time. So I built the alternative. An unofficial real-time API. A custom ingestion layer that captured JetInsight data as it changed, normalized it, and made it queryable against every other system the operator ran. The platform did not have a webhook. The platform did not have anything resembling a developer story. And I built one anyway, because the operation needed it and waiting on the vendor's roadmap was not a strategy.

The interesting part is that I did not invent the technique to do this. I brought it in. The architecture and the data ingestion patterns I used were tech I had been running in other industries on systems that were orders of magnitude more complex than a charter scheduling tool. Manufacturing programs with real time data flowing between supplier and prime. Operational environments where you did not have the option of waiting on a vendor's roadmap. Applying that same playbook to JetInsight was, frankly, a Tuesday. The fact that it was novel inside aviation, and the fact that I ended up bringing the same tech to every JetInsight shop I touched afterward including FlyUSA, tells you everything about how low the technical bar is in this industry. I was not doing anything clever. I was doing what any infrastructure engineer would do in any other vertical on a Tuesday. The work felt heroic only because aviation has been graded on a curve for so long.

From the same place came the rest. I wrote more unofficial APIs against more platforms that did not want to be queried. I built a MEL tracking system, because the minimum equipment list workflow was living in a spreadsheet, a binder, and the maintenance controller's memory, and that is not a system, that is a liability. I built a squawk manager, because pilot squawks were coming in by text, by email, by phone call to the DOM, and by post flight debrief, and nothing was tying them together against the airframe, the deferral status, and the next planned maintenance event. I built the data extraction layer that made all of it queryable. And I ran all of the marketing on top of that, because at an operator the size of Noble the person who can do both ends up doing both.

That experience taught me the lesson everything I have done since has been built on. The vendors are not going to save you. The integrations you need do not exist. The data you need is in the system somewhere, and the path to it runs through whoever on staff is willing to read the network tab, parse the export, and write the glue.

Volato, and watching legacy software try to keep up with an IPO

Then came Volato. I was there during the sprint to go public, running marketing and managing the Controller listings for the sales teams. From the outside it looked like a rocket. From the inside it was a fractional and charter operator trying to scale through a public listing while still running on the same legacy software the rest of the industry runs on. If anything, the speed made the gaps in the underlying platforms more obvious, not less. Public company timelines do not tolerate dispatch systems that need to be retyped into accounting systems. They get exposed. And Volato proved that you could raise all the money in the world in this space, and it won't matter.

I will come back to Controller in a moment, because that platform deserves its own paragraph, and because Volato is where it first became impossible to ignore.

FlyUSA, where the surface area got real

I took the Noble posture to FlyUSA, where the surface area was bigger and the stakes were higher. I was the Director of Marketing and then the Director of Technology at a Part 135 and 91 charter operation co founded by Barry Shevlin and William Holtz, an Inc. 5000 honoree with a real fleet and a real operational footprint. SEO. PPC. Web. The FlyUSA app. Owner portals. Financial data integration. Social. Video reels. A complete rebrand of the operation at Clearwater Airpark which is now Clearwater Executive Airport. The marketing job description on day one. The technology job description by month six.

What ended up consuming most of my time was not the marketing. It was the seams between systems. The places where data was supposed to flow and did not. The places where humans were copy pasting between two SaaS platforms that were both billing the company five and six figures a year, and where neither vendor would build a bridge between them, because the silo was the business model.

The first thing I did at FlyUSA, before the marketing campaigns and before the app work, was bring the JetInsight ingestion mechanism with me. The same unofficial real-time API I had built at Noble, redeployed against FlyUSA's instance, plugged into FlyUSA's data infrastructure. The vendor still refused to publish an API. The operation still needed one. The playbook was already proven. The only work was adapting it to a larger operation with more aircraft, more trips, more crews, and more downstream systems that needed the data flowing into them. That work took weeks, not months, because the hard thinking had already been done. That is what reusable tech actually looks like when it is built right the first time.

Coming from where I came from, from systems that were orders of magnitude more complex than a charter scheduling tool, this should not have been the part I was most proud of. It should have been routine. The fact that the same ingestion mechanism kept being novel at every operator I brought it to tells you everything about how low the technical bar is in this industry.

Around that ingestion layer I built the rest at FlyUSA. I squeezed JetInsight down to its core and extracted the data the flight ops team actually needed to run the daily operational tempo. Custom tools and webhooks for scheduling. Fuel integrations. The dozen small workflow gaps between what the platform did out of the box and what dispatch actually needed at 5 AM when the day was already going sideways. The point was never to replace JetInsight. The point was to stop letting JetInsight be the ceiling on what the operation could do with its own data.

I designed ETL pipelines to drag aircraft maintenance data out of Corridor, which sits on Oracle, and land it in Amazon RDS so we could actually query it. I stood up local LLM testing infrastructure with Ollama and Docker to ingest AirMail data, because I wanted to see what was possible before vendors decided to charge us per seat for the privilege of accessing the patterns inside our own communications.

Controller.com, the storefront for billions

Now Controller. At every aviation company I worked for, Noble, Volato, and FlyUSA, I managed the Controller listings. This is the platform the industry uses to list and shop for aircraft. The marketplace where the line items are multi million and tens of millions of dollars of pressurized aluminum and composite.

The back end where those listings are managed is horrifically outdated.

The flow for getting a Gulfstream or a Citation in front of a qualified buyer in 2026 still involves a UI and a workflow that feels like a 2008 classified ad portal. Photo uploads that fight you. Spec sheets that have to be entered in shapes that do not match how brokers actually describe aircraft. No meaningful API surface for syndication. No AI assist on listing copy, on spec normalization, on buyer matching, on price benchmarking against comparable transactions. This is the storefront for an asset class measured in the billions. And the storefront was apparently built and abandoned in the era when nobody thought it would need to evolve.

Every operator I have ever worked for has paid this platform real money and gotten back a portal that an intern could rebuild in a weekend with modern tools.

The conclusion

I poked at every legacy platform an operator of that size has to use. I came away with one conclusion that I want to put on the record now, in public, with my name attached.

The legacy aviation software incumbents are sitting on a generational data asset, and they are squandering it.

Not by accident. By design. And the design is going to kill them.

The roll up, and why it matters

Let me ground this in the structure of the market today, because most people outside the industry do not understand what has happened in the last 24 months.

The Hearst Corporation, through its CAMP Systems subsidiary, has been quietly assembling the most consequential software rollup in business aviation history. Avinode, the dominant B2B marketplace where roughly 80 percent of charter brokers and operators source lift, is now owned by CAMP Systems, a Hearst subsidiary. Acquisition closed in May 2024. CORRIDOR, the maintenance software running across hundreds of MROs and service centers, is also a CAMP Systems product line. CAMP itself, the maintenance tracking platform that essentially owns the inspection and component tracking layer for the global business aviation fleet, is the parent.

Put it together. The marketplace where charter is bought and sold. The system tracking when every airframe, engine, and component is due for maintenance. The software running the shop floor at the MRO doing the work. All under one corporate umbrella.

That is not a coincidence. That is a strategy. Whoever owns the maintenance data owns the residual value conversation, the dispatch reliability conversation, the insurance conversation, the financing conversation, and now, with the marketplace, the revenue conversation. It is a vertical stack of the operational truth about every airframe in the fleet.

And the people running it are about to learn that owning the data is not the same as being able to use it.

The Blockbuster comparison is too easy. The real one is worse.

Every think piece reaches for Blockbuster and Netflix. I will, briefly, because the structural lesson holds. Blockbuster did not lose because Netflix was cheaper. Blockbuster lost because its entire revenue architecture depended on late fees, on physical inventory turning over in stores, on a relationship with the customer mediated by a counter and a teenager in a polo shirt. When the format shifted, every advantage Blockbuster had became a liability. The stores became rent. The inventory became dead weight. The late fees became the reason customers hated them.

The aviation software incumbents have the same structural problem, and they do not seem to know it. Their only advantages today are:

• Long term contracts with operators who cannot easily migrate off because the switching cost is operationally violent.
• Proprietary data schemas that lock customers in.
• Closed or no APIs, or APIs that exist on paper but are gated by sales teams and integration fees.
• A workflow that requires humans to do the integration work the software refuses to do.

Now look at what happens when AI capable platforms enter the picture and treat data as something that should move, not something that should be hoarded. Every one of those advantages becomes a target. The lock in becomes the reason operators leave the moment a credible alternative exists. The proprietary schema becomes a parsing problem that an LLM solves in an afternoon. The closed API becomes a screen scraping target. The human in the loop becomes the cost line item that gets cut first.

The better historical comparison is not Blockbuster. It is what happened to the on premise enterprise software stack between 2008 and 2015, when Salesforce, Workday, and a wave of category specific SaaS players walked into industries that thought they were too specialized, too regulated, or too entrenched to disrupt. Oracle and SAP did not vanish. They got smaller, slower, and less relevant. The new money went elsewhere.

Aviation software is in 2008. The Salesforce of charter operations has not been built yet. The Workday of pilot scheduling has not been built yet. The Plaid of maintenance data has not been built yet. The Stripe of charter payments has not been built yet. They are coming, and the incumbents are going to fight them by buying competitors and stapling logos onto press releases instead of fixing their architecture.

Let us name names

I am going to be specific. This is not a vibes essay. I have used these platforms. I have integrated against these platforms. I have sat in rooms with operators who were furious at these platforms. Here is the honest assessment.

Avinode

Avinode is the marketplace that ate the industry. It works, in the narrow sense that it does what a 2005 era B2B sourcing platform does. A broker enters a trip request. Operators get pinged. Quotes come back. Deals get done. The annual access fees run between five and 30 thousand euros depending on tier, and roughly 80 percent of business aviation professionals use the platform.

It is also, in 2026, still fundamentally a request for quote tool wrapped in a directory. The data Avinode sits on, real time fleet availability, pricing behavior across thousands of operators, repositioning patterns, broker preferences, route demand by season and weekday, is one of the most valuable datasets in business aviation. What does Avinode do with it? It sells "business intelligence reports" back to the operators who generated the data. It is the Bloomberg terminal model applied to a market that does not need a terminal. It needs an API and an agent.

What Avinode should be: a programmatic interface where an operator's dispatch system, sales team, and AI agent can interrogate the entire marketplace in real time, find the optimal sub charter, price it dynamically against current market conditions, and contract it without a human typing a single field. What it actually is: a web app with an iOS companion and a salesperson who wants to talk to you about your tier.

They have no moat as it's extremely easy now and more so in the near future to build what they have.

Controller.com

I covered the operator pain with Controller earlier in this piece, but it belongs in this section too, because as a platform it is the most mind boggling case study of the whole industry. Controller is the dominant marketplace for buying and selling business aircraft. Multi million and tens of millions of dollar transactions, every day, run through this site. It is, by sheer transaction volume and listing concentration, an industry giant.

And the only reason it is an industry giant is that it has been there a long time.

Not because it serves any technological value. Not because it solves a problem better than any alternative could. Not because it has built any differentiated capability since the Bush administration. The platform persists because brokers and operators got into the habit of listing there twenty years ago and nobody has yet built the credible alternative that breaks the habit. That is incumbency. That is not a product moat. That is a calendar moat, and calendar moats erode the moment somebody shows up with a real product.

What should a 2026 aircraft marketplace look like? Listings auto-populated from the operator's maintenance and ownership records, not retyped from a binder. Spec sheets normalized to a schema brokers can actually query against. Photo pipelines that handle high resolution interior and exterior assets without fighting the user. AI generated listing copy that the broker reviews and approves rather than writes from scratch. Buyer matching against historical transaction comparables. Price benchmarking against the actual market. APIs for syndication, so an aircraft listing flows automatically to every relevant surface. Document management for logbooks, AD compliance, and pre-buy inspections built into the listing itself.

None of that is theoretical. None of that is hard. All of that has been solved in adjacent verticals, including residential real estate, which is somehow ahead of business aviation on most of these dimensions despite the average transaction being a fraction of the size. The fact that a Citation listing is harder to manage than a Zillow listing is the punchline that everyone in the industry has stopped laughing at because they got used to it.

This is the perfect example of the broader thesis. The legacy aviation incumbents do not survive on merit. They survive on inertia, on switching costs, on the fact that nobody has built the alternative yet. The moment somebody does, the calendar moat evaporates.

JetInsight, FL3XX, and the FMS layer

Flight management systems. The operational backbone of a charter operator. Trip building, crew scheduling, dispatch, post flight reconciliation, invoicing. JetInsight is the platform a lot of US operators run on. FL3XX has grabbed share, particularly internationally. Leon is in there. A handful of others.

These platforms do an enormous amount of work. They are also, with rare exceptions, closed boxes with documentation that reads like it was written for the auditor, not the developer. Integration with the maintenance platform requires a human. Integration with the sales platform requires a human. Integration with accounting requires a human. Integration with the pilot's iPad requires a human. The flight management system is the spine, and every connection to the spine is a vertebra that someone in operations has to align by hand, every day.

If you are building a flight management system in 2026 and your story is not "every entity in our system has a webhook, an event stream, a clean REST or GraphQL API, and a documented schema that an LLM can introspect," you are building a 2012 product. The market will reward whoever builds the first FMS that treats itself as a platform instead of as a destination.

The FBO, fuel, and ground services layer

This is the one that drives operators crazy on a daily basis, and it almost never gets written about, because it is unglamorous and because the people who know how broken it is are too busy keeping flights moving to write LinkedIn posts about it.

Every charter trip involves a stack of vendors on the ground at both ends. The FBO that handles the aircraft. The fuel provider. The ground transportation operator. The catering vendor. The deicing crew in the winter. The handler coordinating slot times at the busy airports. The customs and immigration paperwork for international legs. Each of these touches the trip and each of these generates a charge that has to be reconciled back to the right tail number, the right trip, and the right customer.

The platforms in this space are a museum. Universal Weather. World Fuel Services. Colt International. Signature. Atlantic. FBOOne for some FBOs, custom hairballs for others. AvFuel. Each of these operates as if no other vendor exists. Fuel quotes still come back over email in a lot of cases. Slot coordination for slot controlled airports is run over phone and text. Handling requests are forms. Catering orders are forms. Customs paperwork is forms. And the prices, particularly fuel prices, vary wildly between providers at the same airport on the same day, with no easy way for an operator to comparison shop across the stack programmatically.

I touched this layer at FlyUSA. The fuel integration work I did was not glamorous and it was not finished, because the surface area is enormous and every provider has a different idea of what an integration means, which usually means "we will send you a CSV by email on Thursdays." I built what I could. I left understanding that the operator who solves this layer programmatically across the major providers wins back real margin per trip, because the inefficiencies in fuel pricing alone are large enough to fund the integration work several times over.

The dysfunction here is also where AI agents are going to look most obviously useful first. Comparison shopping across fuel providers at a given airport for a given trip is a textbook agent task. Coordinating handling, customs, and ground transportation across a multi leg international trip is a textbook agent task. Reconciling the resulting invoices back to the right trip and the right customer is a textbook agent task. The data is messy and unstructured today, which is exactly the kind of problem language models are good at, and which the incumbents in this space have been protected from caring about because the messy unstructured workflow was the moat. It was never a moat. It was a wall keeping the rest of the world out, and somebody is about to walk right through it.

CAMP and CORRIDOR

This is the maintenance side and this is where it gets interesting. CAMP tracks airframes, engines, components, and inspection intervals across most of the global business aviation fleet. CORRIDOR runs the shop floor at MROs. Both are now under the same Hearst umbrella, and in late 2025 CAMP announced its AI Operations Manager, launched with West Star Aviation and quickly extended to ACI Jet, applying predictive intelligence to maintenance planning at MROs.

Credit where it is due. That is the right direction. Predictive scheduling, labor forecasting, turn time optimization. Real problems, real value, applied to the data the company already holds.

Here is the criticism. It is being delivered inside the walled garden. The AI Operations Manager is a feature of CORRIDOR for service centers that already pay CAMP for everything else. The intelligence is not exposed as an API that an operator's flight management system can call. It is not exposed to the broker pricing a charter who wants to know whether the aircraft is actually going to be available on the date the operator says it will. It is not exposed to the insurance underwriter pricing the hull policy. It is not exposed to the lender financing the airframe. It is a CAMP product, sold to CAMP customers, locked inside the CAMP UI.

The unlock is not predictive maintenance for the MRO. The unlock is making the maintenance signal liquid across the entire business aviation economic stack. Until that happens, CAMP is monetizing a feature when it could be monetizing a market.

The accounting and billing layer

Quickbooks, mostly. Sometimes Sage. Sometimes a custom hairball that an accountant built in 2014 and refuses to touch. Charter invoicing in this industry still goes out as PDF attachments to emails. Reconciliation of broker payments, fuel charges, FET, segment fees, deicing, catering, and crew expenses is mostly a human in front of a spreadsheet at the end of every month. There is no Stripe for charter. There is no Brex for FBO charges. There is no Ramp for crew expenses, despite Ramp being available in every other vertical on earth.

The opportunity here is not glamorous. It is enormous.

The pilot and crew layer

Crew scheduling lives in the FMS or in a bolt on platform. Pilot certification, recurrent training, currency tracking, line check schedules, medical certificates, passport expirations. All of this is tracked. None of it is integrated with anything that would let a human or an agent reason across it. Want to ask "who can fly the Sarasota to Aspen trip on Tuesday that meets the customer's preference for a captain with more than 500 hours in type and is also legal under FAR 117 rest rules?" Good luck. That answer lives in three systems and the head of the chief pilot.

What it taught me

The most useful thing I did across Noble and FlyUSA was not any single feature. It was a posture. The posture was this: do not accept the silo as a constraint of physics. Treat every vendor's API as a starting position to negotiate from, every export as raw material, every PDF as a parsing problem, and every "we do not support that integration" as a sales objection rather than a technical fact.

The MEL tracker, the squawk manager, and the unofficial APIs at Noble taught me the first lesson. The data the operation needs to actually run is almost always already being captured somewhere. It is just being captured in a form the vendor does not want to expose, in a place the vendor does not want to query, in a schema the vendor does not want to document. The work is not generating the data. The work is liberating it.

The Corridor ETL pipeline at FlyUSA taught me the second lesson. Once the data is liberated and landed in a schema that matches how the operations team thinks about the fleet, the questions that used to take a week of back and forth between the DOM, the chief pilot, and the head of charter become dashboard queries. The data had always been there. It had just been imprisoned inside a vendor's UI.

The FlyUSA app and the owner portals taught me the third lesson. The customer experience layer is the easy part. The hard part is the back end making promises the operational systems can actually keep. If the customer books a trip in the app and the trip request lands in three separate systems that none of the operations staff trust, the app is theater. The win is not in the app. The win is in making the back end coherent enough that the app can stop lying.

The JetInsight work taught me the fourth lesson. You do not have to rip out the incumbent to beat the incumbent. An unofficial real-time API built against a platform that explicitly refused to offer one will, in practice, do more for an operator's operational tempo than five years of waiting for the vendor's roadmap to catch up. Webhooks, custom ingestion, fuel integrations, and a willingness to read the network tab will let you bend a closed platform into something the operation can actually use. The vendor's product becomes a component in your architecture instead of the architecture itself.

The Ollama and Docker setup, ingesting AirMail data inside the firewall, taught me the fifth lesson, and this is the one that matters most for what comes next. Every operator that wants to do something useful with AI in the next three years is going to face the same fork. Hand the data to a vendor's hosted LLM and pay per seat for the privilege of being inside their walled garden. Or run it yourself, own the IP, own the patterns, and own the agent layer that gets built on top of it. There is no right answer for everyone. There is a right answer for each operator. Most of them have not done the work to figure out which one is theirs.

Forward deployed engineer is the phrase the industry is using now. What it means in practice is the person who shows up, learns the business, learns the people, learns the data, and refuses to leave until the silos start leaking. That is not a job description. That is a posture, and it is the only posture that produces software an operations team will actually use.

What this industry actually needs is a protocol

If I zoom all the way out, past the named platforms and the specific operators and the war stories, the deepest thing this industry is missing is a protocol.

Not a product. Not a platform. A protocol. A shared standard for how aviation operational data is structured, identified, and exchanged across systems and across companies. An aviation equivalent of what FIX did for financial trading, what SWIFT did for interbank settlement, what HL7 and FHIR are doing for healthcare records, what EDI did for logistics before the API-first generation modernized it, and what RESO is trying to do for real estate listings. Each of those industries spent years in the same swamp business aviation is in right now. Siloed data. Vendors monetizing the silo. Customers paying the cost of the silo. And in every case, the breakthrough that unlocked the next era of value creation was not a single dominant platform crowning itself the winner. It was an agreed protocol that let everyone build on a common semantic layer.

The shape of an aviation protocol is clear if you have lived inside the operation. Common identifiers for airframes, components, trips, crews, certifications, work orders, listings, quotes, and invoices, so that the same entity referenced in the FMS, the maintenance system, the marketplace, and the accounting platform is provably the same entity. A shared event vocabulary so that "aircraft returned to service" or "trip released" or "MEL deferral added" means the same thing in every system it touches. A defined exchange layer so that operators, MROs, brokers, lenders, and insurers can subscribe to the events they care about without needing a bilateral integration project for each pair of systems. The unglamorous middle of this is governance and adoption, which is where every prior industry standard either won or died, and which is where aviation is going to face its hardest fight.

I have seen what this kind of standard does in other industries. The companies that win after the protocol stabilizes are not the ones that owned the largest silo before the protocol. They are the ones that built on top of the protocol fastest, with the most thoughtful applications, against the most operationally aware understanding of the data. That is the moment business aviation is heading into, and most of the incumbents are going to be on the wrong side of it because their entire business model assumes the data stays inside their UI.

I have more to say about what this protocol should actually look like, who could realistically convene it, what the failure modes are, and why the current consolidation under Hearst makes it less likely to come from inside the industry rather than more. That is a separate article and I am going to write it. For now I will just plant the flag. The next era of business aviation software is going to be built on a protocol layer, and the people who see that early are going to build the companies that matter.

The agentic layer is the actual disruption

Even before the protocol arrives, and it will arrive, something else is going to start eating the incumbents from the inside. Predictive maintenance is a feature. Dynamic pricing is a feature. Better dashboards are a feature. None of these is the disruption.

The disruption is agentic. It is the moment when an operator can stand up an agent that has read access to the FMS, the maintenance platform, the marketplace, the accounting system, the crew database, and the customer CRM, and can answer questions and take actions across all of them in natural language. The agent does not care that the FMS is on REST and the maintenance platform is on SOAP and the accounting system is a CSV export and the marketplace is a web scrape. The agent normalizes. The agent reasons. The agent acts.

Once that capability exists at one operator, the cost of replicating it at the next operator collapses. Once the cost collapses, the vendors who built the silos start looking like Oracle in 2010. Still huge, still profitable, still entrenched, and absolutely not where the new money is going.

The aviation incumbents have two ways to play this. Option one is to become the platform. Open the APIs, publish the schemas, make the data movable, and charge for the data and the intelligence layer instead of the UI. Option two is to keep the walls up, ship AI features inside the walled garden, and harvest the existing book of business until a credible alternative shows up.

The CAMP and Avinode rollup under Hearst is telegraphing option two. The AI Operations Manager is option two. The continued treatment of operational data as a captive asset rather than a market is option two. I understand the logic. I also understand what happened to every enterprise software incumbent that picked option two in every prior cycle.

The conversation that confirmed the diagnosis

Not long ago I had a conversation with the co-founder of one of the largest private aviation membership companies in the world. The kind of company whose name shows up in every market map of business aviation, in every analyst report, in every conversation about where the industry is going. The conversation was casual. It also happened to be one of the clearest moments of validation I have had since I started thinking about all of this seriously.

He asked me, basically, how hard is it to build a JetInsight class tool from scratch today. The honest version of the question. Not pitching anything. Just asking.

The answer was not what an outsider would expect. The answer was that it is not hard. Not technically. With deep cloud engineering experience and a real engineering team, with the modern data and orchestration stack, with the way good engineers are leveraging AI in their development loops right now, building a JetInsight class platform is not the hard part. The platform that the entire US charter industry runs on, that every operator pays five and six figures a year for, that every dispatcher curses at and every developer wishes had an API, is not actually a difficult piece of software to rebuild in 2026. It is a known shape of system. It is solved problems on a stack that did not exist when the incumbent was built.

So if the build is not the hard part, what is.

The hard part is being in a position where you do not have to ask for permission to ship.

That is the actual constraint. Not the engineering. Not the cloud architecture. Not the data ingestion. Not the agent orchestration. The constraint is organizational. It is being inside a company where, when you see the problem, you can build the solution, deploy the solution, and tell the operation it is going to use the solution. Most aviation companies do not work that way. Most aviation companies work the other way. You see the problem. You write the memo. You build the case. You wait for budget. You wait for a vendor to bid on it. You wait for someone to schedule the meeting where the decision gets made. You wait for the decision to get unmade in the next meeting. You watch the problem stay broken for another year while the platform that should have solved it sends a quarterly invoice.

The day I am in a position where I do not have to ask for permission to deploy a thought, a feature, or an idea, where I can spot the problem, build the solution, deploy it, and tell the operation it is going to use it, is the day this whole picture changes. Not because the technology suddenly works. The technology already works. Because the organizational latency between problem and shipped solution finally collapses to something close to zero. That is the difference between an operator running on the legacy stack and an operator running on the right stack. The technology is downstream of the authority. The authority is the thing.

What I am building next, and what I am looking for

I am building, and I am looking for the right people to build with.

The thesis is straightforward, and at this point it should sound familiar. Business aviation needs an ontology. Not a metaphor, the actual architectural pattern. A semantic layer that sits across the existing operational systems, models the entities the industry already runs on, airframes, components, trips, crews, customers, work orders, quotes, invoices, listings, and exposes the result as a unified interface that operators, brokers, MROs, lenders, and insurers can all reason and act against. Once that layer exists, the agentic tooling on top of it is straightforward engineering. The hard work, the work nobody in the industry has done yet, is the ontology itself. Not a rip and replace of JetInsight or CAMP or Corridor or Controller. A connective tissue play that lets the existing systems keep running while the real intelligence layer gets built where it belongs, which is above all of them, not inside any one of them.

I am looking for two kinds of conversations.

The first is with operators, in the Florida region or beyond, who want a forward deployed engineer inside their organization on an equity or profit participation structure. I have done the work at a Part 135 and Part 91 operation. I know the back office. I know where the leverage points are. I know how to ship software that the dispatchers and the maintenance controllers and the chief pilot will actually use, because I have done it, and I have done it as the person on the hangar floor figuring out what was broken before writing the code to fix it.

The second is with founders and investors who see the same opportunity I see and want to build the connective tissue layer for business aviation. Not another flight management system. Not another marketplace. The integration and agent layer that makes the existing systems behave like one system. The team that wins this is going to be small, technical, deeply embedded with operators, and unafraid to call the incumbents what they are.

And to be transparent about where I am on this, I am not coming to that conversation with a deck and a vibe. I am writing the operating thesis right now. A two hundred to two hundred and fifty page document that walks through the entire argument, names the protocol layer, names the agentic architecture on top of it, and lands on a concrete first move. The first move is small on purpose. Three King Air class aircraft. A live, operating, real-world Part 135 footprint that becomes the laboratory and the proof. From that footprint, every claim I have made in this article gets demonstrated on actual airframes, with actual trips, with actual maintenance events, with actual customers. The protocol gets built because the operation needs it. The agentic systems get built because they make the operation more efficient. The adversarial agents get built because the operation needs to stress test its own pricing, its own dispatch logic, and its own customer experience the way no operator today can. The integrations get built because there is no other way to run the operation the way we intend to run it.

The thesis behind picking that starting point is straightforward. You do not need a hundred aircraft to prove the architecture works. You need three aircraft, the right team, and the discipline to build the data layer correctly from day one rather than bolting it on after a year of operational compromises. Once it works on three, the marginal cost of layering on the next ten, and the next thirty, drops by an order of magnitude, because the connective tissue is already in place. That is the inverse of how every other charter operator scales, which is part of why charter operators have never scaled well.

And let me name the harder truth that sits under all of this. You almost never see a Part 135 operator get sold off at a meaningful multiple. The exit math for charter is brutal. Margins are thin, fleets are heterogeneous, the data is unstructured, the customer relationships sit with individual sales reps rather than with the company, and any acquirer doing diligence finds a tangle of operational debt rather than a clean asset. The reason 135 operators do not get sold for profit is not because the business is bad. It is because the back end of the business is incoherent. The thesis I am building is, at one level, an aviation operating company. At another level, it is a deliberate exercise in proving that a 135 operator built on the right data architecture is a fundamentally different kind of asset than a 135 operator built on the legacy stack. Same airframes. Same regulations. Same customers. Completely different enterprise value, because the data layer is the asset.

If that thesis lands for you, whether you are a builder, an investor, or an operator with capital and frustration in equal measure, that is the conversation I want to have. The document is in progress. The first reader slots are not.

If you are at Avinode or CAMP or CORRIDOR or JetInsight or FL3XX and you read this and you disagree, I would actually love that conversation. Tell me where I am wrong. Tell me what you are shipping that I do not know about. Tell me which APIs you are opening up and when. And I will tell you, in return, exactly what every single operator I have worked with has said to me about your platform in private. The complaints. The workarounds. The line items in the renewal conversation that the account manager talked their way past. The features that were promised on a roadmap call two years ago and have not shipped. The integration requests that died in a ticket queue. The data exports that come back malformed. The reasons the dispatcher cried at her desk during a busy holiday week. I have heard it all, across multiple operators, in multiple roles, in rooms where the vendor was not present and the gloves were off.