Flight Dispatch and Operational Flight Planning Software: Where Your Fuel Policy Quietly Leaks Money

Why the release is a legal document assembled under time pressure

A dispatcher has eleven flights to release before the shift changes. For each one they merge forecast winds, significant weather, NOTAMs on the route and destination, runway condition, the registration and its current defects, payload, alternate selection, and a fuel figure that must satisfy the operations manual and survive scrutiny if anything goes wrong. Under a US Part 121 operation the dispatcher shares responsibility for that release with the captain. The document they produce is not paperwork, it is the legal basis on which the flight departs.

The tools exist and they are good. Jeppesen JetPlan, Lufthansa Systems Lido Flight 4D, NAVBLUE N-Flight Planning, ForeFlight Dispatch and Sabre Flight Plan Manager all compute routes against real weather and real aircraft performance, and that computation is serious engineering nobody should casually rebuild. Aerodynamic models, global weather ingestion, airspace structures, overflight charge data: decades of accumulated work, and the licence fee is cheap against it.

The gap sits on either side of the computation. On one side is your fuel policy, written in your operations manual in language your regulator approved and applied through whatever configuration the vendor offers. On the other is everything that happens afterwards: how the dispatcher reviews the plan, what goes into the briefing package, how the defect list affects performance, how the numbers reach the flight deck and the load controller. That is where the money leaks, and it is the part vendors treat as configuration rather than product.

Problem 1: the fuel policy in your manual is not the fuel policy the system applies

Every operator has fuel policy rules that go beyond the regulatory minimum. Extra fuel for particular destinations known for holding. A standard uplift at stations where the refueller is unreliable. A captain's discretion allowance that is theoretically discretionary and practically standard on certain routes. Statistical contingency arrangements where they are approved. These rules exist, they are known to the fuel team, and they are applied inconsistently because they live in a manual rather than in the plan.

Vendor systems allow configuration of fuel policy, and for the common cases it works. The awkwardness starts with rules that are conditional on things the planning engine does not model: a specific station's history, a season, a particular aircraft's known fuel burn deviation from the book figures, a captain's individual pattern of adding fuel. Those get handled by the dispatcher, or not at all.

What a custom build does: express fuel policy as versioned, testable rules on top of the computed plan. The engine returns the burn and the regulatory minimums. Your layer applies your policy explicitly and records why each component was added. The dispatcher sees a breakdown that says trip fuel from the engine, contingency per policy, alternate fuel for this specific alternate, plus a named discretionary component with its reason attached. When the fuel director asks where the extra tonnage across the network came from last month, the answer exists as data rather than as a theory.

Problem 2: tankering is decided in a spreadsheet nobody has updated since fuel prices moved

Tankering, carrying fuel from a cheap station to avoid buying at an expensive one, is worth real money and it is genuinely finely balanced, because carrying fuel costs fuel. Getting it right requires the price at both ends including into-plane fees and contract terms, the aircraft's actual burn characteristics, the payload for the sector, and the turnaround plan. Most operators calculate it in a spreadsheet maintained by one analyst, updated when someone remembers, and applied by dispatchers who may or may not trust it.

Some planning systems offer tankering computation, usually from a fuel price table you maintain inside their system, which drifts from your contracted prices and knows nothing about your into-plane fees or the stations where uplift is operationally awkward regardless of price.

What a custom build does: connect the tankering decision to your actual fuel procurement data, refreshed automatically rather than typed, and compute per sector against the plan the engine has already produced. Then surface it as a recommendation with the number attached, so a dispatcher can see that this sector saves a specific amount by tankering and this one does not. Just as importantly, log the recommendation and the outcome, so after three months you know whether your tankering programme is capturing what it claims. Fuel programmes that cannot be measured have a habit of quietly degrading.

Problem 3: the defect list leaves the loop and takes performance with it

An aircraft with an inoperative item under the minimum equipment list or a missing panel under the configuration deviation list often carries a performance penalty: increased fuel burn, a speed restriction, a systems limitation that affects alternate requirements. That penalty lives in the MEL document and in maintenance systems. The flight plan is built against a clean aircraft unless the dispatcher knows to apply it.

This is one of the clearest process gaps in dispatch, and it is not usually the planning vendor's fault, because the defect data belongs to maintenance and the interface between them is often a phone call or a daily email.

What a custom build does: pull the current defect list per registration from the maintenance system and apply the associated planning penalties automatically, so the plan reflects the aircraft as it actually is. Where the penalty requires judgement, it prompts rather than assumes. This is a safety improvement and a fuel accuracy improvement at once, and it is one of the few places where the integration work is straightforward and the benefit is immediate.

Problem 4: alternates and ETOPS rules are yours, and the generic version is expensive

Alternate selection is where operator-specific policy is heaviest: weather minima, company restrictions on particular airports, handling and customs availability at the hour of a possible diversion, runway length on a wet or contaminated surface, and for extended operations the approval limits and adequate airports along the route with their weather validity windows.

Planning systems select alternates against configurable criteria. The friction is that operators embed judgement in the choice, such as preferring a station with company handling over one marginally closer, or avoiding an airport when customs is closed. Without that, the dispatcher overrides the system regularly, which makes the system's choice decoration.

What a custom build does: encode the operator's own alternate preference logic as ranked rules with the reasons attached, so the recommended alternate is the one your operation would actually pick and the dispatcher's job becomes confirmation rather than correction. For extended operations, validate the diversion airports against the weather validity window and the approval, and show the dispatcher what fails rather than simply excluding it.

Problem 5: the release is only half the job, the briefing package is the other half

After the plan comes the package: the operational flight plan itself, weather, NOTAMs filtered to relevance, the release signature, and whatever else your operations specification requires, delivered to the flight deck through an electronic flight bag or on paper, then to load control, then filed with air traffic services. NOTAM filtering deserves particular attention, because unfiltered NOTAMs are a known safety problem: a crew handed forty pages will not read all of them, and the item that matters is on page thirty-one.

What a custom build does: assemble the package once, filter NOTAMs by relevance to the actual route, altitude and time window, and deliver it to the flight bag with acknowledgement recorded. Changes after release, which happen constantly, push an update rather than requiring a phone call. The handover to load control passes the planned figures rather than having them retyped, which removes a transcription step from a safety-critical chain. None of this is glamorous. All of it is where dispatcher hours go.

What this costs and how long it takes

A first release covering the policy layer over a licensed planning engine, meaning fuel policy rules, tankering economics from live procurement data, MEL and CDL penalty application, alternate preference logic and the dispatcher release workflow, runs $150,000 to $350,000 and ships in 20 to 30 weeks. A full platform adding briefing package assembly with NOTAM filtering, electronic flight bag and ACARS integration, load control handover and post-flight fuel analytics runs $500,000 to $1,200,000 phased over 12 to 24 months.

What drives cost up in dispatch specifically: the number of fleet types, because performance handling and MEL penalties differ per type. Extended operations approval, which adds validation logic and evidence requirements. ACARS and flight bag integration, since each is a distinct interface with its own message formats and failure modes. Regulatory scope, because an operation under both FAA and EASA oversight carries two sets of documentation expectations. And the item that surprises people, which is verification: because the output supports a legal release, the testing effort against the incumbent system is larger than for ordinary software and it is not a place to economise.

What holds cost down: keeping the licensed engine and building only the policy and workflow layer. Operators who try to replace the engine as well spend two years reproducing wind interpolation.

Build versus buy, and the split we recommend

Buy outright if you operate a small fleet on short sectors with straightforward alternates and no meaningful tankering opportunity. ForeFlight Dispatch or a standard JetPlan arrangement will serve you well and a build would be an expensive hobby.

Buy the engine always. Route computation against global weather with real aircraft performance data is not a thing to rebuild, and any developer who offers to is either misunderstanding the problem or hoping you do.

Build the layer when two or more of these are true. Your fuel policy is documented in the operations manual and applied inconsistently in practice, so you cannot explain last month's fuel variance. Tankering is decided from a spreadsheet and nobody has measured whether the programme works. Your MEL penalties reach the dispatcher by phone. Your dispatchers routinely override the recommended alternate, which means your selection logic is not in the system. Or your briefing packages are assembled manually and NOTAM filtering is a dispatcher's judgement performed eleven times a shift.

Our position: dispatch is the clearest example in aviation of a category where the correct build is narrow and deep rather than broad. The computation is a commodity you should rent. The policy, the economics and the workflow are yours, they are where the money is, and they are exactly what vendors treat as configuration.

How to choose a developer for flight planning and dispatch software

Ask them what they would not build. If they do not immediately say the computation engine, they have not understood the domain and you are funding their education.

Ask how they will validate against the incumbent. The right answer is a parallel period where every plan is computed both ways and differences are adjudicated by your chief dispatcher, with a documented sign-off before the new system releases a single flight.

Ask what they have integrated in aviation, naming the specific system: ACARS, an electronic flight bag, a maintenance system for defects and a fuel procurement source are four separate interfaces. Ask what happens when a feed fails mid-shift, because the answer must never be a silently stale figure on a release.

Ask how fuel policy rules will be changed after handover. If the answer is a developer ticket, your fuel team will go back to the spreadsheet within a year. It needs to be configurable by your own people with versioning and an approval step.

Ask who owns the code and settle it before kickoff. You should hold the repository, the infrastructure accounts and the right to bring in another firm. At Digital Heroes the client owns the code from the first commit. In dispatch this is a regulatory point as well as a commercial one, because the system participates in producing a legal release document and you must be able to demonstrate control over how it works.