Flight Dispatch and Planning Software Problems: The 7 That Burn Fuel and Time, and How to Avoid Them

Why does rebuilding the planning engine keep getting proposed?

Because it is the visible part. An operator describes frustration with their planning system, a developer looks at the output, sees a route, a burn figure and a set of alternates, and concludes that the system computes something they could compute. The proposal that follows quotes a platform rather than a layer, and it is usually cheaper on paper than the honest version, which makes it persuasive.

What is not visible in the output is the accumulated work behind it. Aerodynamic models per type and per configuration, global weather ingestion and interpolation, airspace structure that changes constantly, overflight charge data, and years of correction against real world outcomes. Jeppesen JetPlan, Lido Flight 4D, N-Flight Planning, ForeFlight Dispatch and Sabre Flight Plan Manager all carry that behind them.

The fix is a scoping question you ask on the first call. Ask a prospective developer what they would not build. If the computation engine is not the first thing out of their mouth, they have not understood the domain and you are funding their education at your own risk. The correct architecture licenses the engine and builds the layer around it: your fuel policy rules, your tankering economics, your defect penalties, your alternate preference logic and your dispatcher workflow. That is a $150,000 to $350,000 first release over 20 to 30 weeks in Digital Heroes delivery experience, against a rebuild that has no honest upper bound.

What goes wrong when you migrate fuel policy and station data?

Nobody has ever written the policy down completely, which is the finding rather than the obstacle. The operations manual holds the approved framework. Practice holds a great deal more: 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, and a known burn deviation on one airframe that experienced dispatchers quietly allow for.

Collecting that is an interview exercise across your dispatch office, and it will produce contradictions. Two senior dispatchers will describe the same route differently, and both will be describing something that has worked.

Treat the contradictions as the deliverable. Every rule gets written down with its trigger, its magnitude and its justification, and then your chief dispatcher and fuel director decide which version is policy. That decision, made deliberately rather than by whoever is on shift, is often worth more than the software. Station and aircraft data needs the same discipline: handling and customs hours, runway condition sources and company restrictions per airport are frequently held in a personal spreadsheet and should be migrated as governed records with owners. Then reconcile before you rely on anything, by recomputing a month of historical sectors and comparing planned fuel against what was actually uplifted.

Why do maintenance, fuel price and flight bag integrations break after launch?

Each has a different failure and only one of them is loud. The maintenance feed for the minimum equipment list and configuration deviation list breaks when the maintenance system is upgraded or when a defect is recorded against a component rather than an aircraft, so the penalty never reaches the plan. Fuel price feeds break when a supplier contract changes or when into plane fees move to a different schedule, and the effect is a tankering recommendation that is confidently wrong. Electronic flight bag and aircraft communications addressing and reporting system interfaces break in transit, where a message is sent and never acknowledged.

The consequence in every case is the same and it is unacceptable in this domain: a stale figure presented as current on a document that supports a legal release.

So the rule is that the system never shows a value without knowing how old it is, and it never silently substitutes a default. If the defect list is more than a defined age, the plan says so and the dispatcher acknowledges it. If a fuel price is stale, tankering advice is suppressed rather than computed on an old number. If a flight bag delivery is not acknowledged, the dispatcher sees an unacknowledged state rather than assuming receipt. Ask any prospective developer what happens when a feed fails mid shift. The answer must never be a stale figure on a release, and if they have to think about it, they have not built for aviation.

What happens when NOTAM filtering and release evidence are not covered?

You get a package nobody reads. Unfiltered notices to air missions are a known safety problem: hand a crew forty pages and they will not read all of them, and the item that matters is on page thirty one. If the build stops at the plan and leaves the package assembly manual, a dispatcher performs that filtering by judgement eleven times a shift, under time pressure, which is exactly the condition under which judgement degrades.

The release evidence gap is quieter. The release is a legal document, and under a United States Part 121 operation the dispatcher shares responsibility for it with the captain. If the system cannot show which version of the plan was released, what changed after release, who acknowledged the change and when, then the record of a routine day is fine and the record of a bad day is not.

Build both into the scope rather than the wish list. Filter notices by relevance to the actual route, altitude and time window, and record what was filtered out as well as what was shown, because the filtering logic is itself something you may have to justify. Assemble the package once and deliver it to the flight bag with acknowledgement recorded. Push updates after release rather than making a phone call. And pass planned figures to load control directly rather than having them retyped, since removing a transcription step from a safety critical chain is worth doing on its own merits.

Should you build custom or configure what you already own?

Buy outright and build nothing 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 at that scale is an expensive hobby with a regulatory surface attached.

Buy the engine always, regardless of your size. This is the one recommendation in the category that does not have exceptions.

Build the layer around it 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 captures what it claims. Minimum equipment list penalties reach the dispatcher by phone call or daily email, which means some plans are built against a cleaner aircraft than the one at the gate. Your dispatchers routinely override the recommended alternate, which means your selection logic is not in the system and the system's choice is decoration. Or your briefing packages are assembled by hand. Dispatch is the clearest example in aviation of a category where the correct build is narrow and deep rather than broad.

How do hidden costs get into the quote?

Verification is the one that surprises operators, and it is not a place to economise. Because the output supports a legal release document, the testing effort against the incumbent system is materially larger than for ordinary business software. Expect 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. That period needs dispatcher time on both systems and it is frequently costed at zero.

Fleet type count is the second, since performance handling and defect penalties differ per type and each type is its own configuration and its own test set. Extended operations approval is the third, adding validation logic, diversion airport weather validity windows and evidence requirements.

Then two integration items. Flight bag and aircraft messaging are distinct interfaces with their own message formats and failure modes, and neither is a small piece of work. And regulatory scope, because an operation under both FAA and EASA oversight carries two sets of documentation expectations rather than one. The full platform adding package assembly with notice filtering, flight bag and messaging integration, load control handover and post flight fuel analytics runs $500,000 to $1,200,000 phased over 12 to 24 months, and phasing it is what keeps the verification burden manageable.

What separates a build that works from one that fails here?

The first marker is that fuel policy rules are configurable by your own people, with versioning and an approval step. If changing a rule requires a developer ticket, your fuel team returns to their spreadsheet within a year and the system drifts from the manual again, which is the exact problem you paid to solve. Ask this directly during selection, because the answer tells you whether a developer is building a product for you or a project for themselves.

The second is that every fuel component carries a named reason. Trip fuel from the engine, contingency per policy, alternate fuel for this specific alternate, and any discretionary component with its justification attached. When the fuel director asks where last month's extra tonnage came from, the answer is a query rather than a theory, and that capability alone usually pays for the layer.

The third is that tankering recommendations are logged with their outcomes. An unmeasured fuel programme degrades quietly, so record what was recommended, what was uplifted and what the sector actually cost, then review it quarterly. Recommendations dispatchers do not trust get ignored, and you want to know that within a month rather than a year.

The fourth is ownership of the code, the repository and the infrastructure accounts, with the right to bring in another firm. In dispatch this is regulatory as well as commercial, because the system participates in producing a legal release document and you must be able to demonstrate control over how it computes and what changed when.