Flight Dispatch and Planning Software: Build or Buy, and the Split We Recommend

When is off the shelf genuinely the right call here?

Buy the engine, always. Jeppesen JetPlan, Lufthansa Systems Lido Flight 4D, NAVBLUE N-Flight Planning, ForeFlight Dispatch and Sabre Flight Plan Manager compute routes against real weather using real aerodynamic performance, airspace structure and overflight charge data. That is decades of accumulated engineering and the licence fee is trivial against reproducing it. There is no operator for whom rebuilding route computation is correct, and a developer who offers to either misunderstands the problem or hopes you do.

Buy the whole thing, engine and workflow, if you operate a small fleet on short sectors with straightforward alternates and no meaningful tankering opportunity. Under roughly fifteen aircraft, ForeFlight Dispatch or a standard JetPlan arrangement will serve you properly, and a custom layer is an expensive hobby with a regulator watching.

Buy if your fuel policy is genuinely simple and consistently applied. Some operators really do fly one type on one network under one policy, and for them the vendor's configuration is sufficient. Test that honestly before assuming otherwise: ask your fuel director whether last month's variance between planned and uplifted fuel can be attributed to named policy components, stations or captains. If it can, you do not have the problem this build solves.

Buy if what is broken is process rather than software. Dispatchers overriding the recommended alternate every shift might mean your selection logic is not in the system, or it might mean nobody has updated the airport restrictions in three years. Check the second before funding a fix for the first.

When does a custom build actually pay off?

The build case sits on either side of the computation, never inside it. 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 after the plan: dispatcher review, briefing package assembly, defect handling, delivery to the flight deck and handover to load control. Vendors treat both as configuration. That is where the money is.

These are the signals worth acting on:

• You cannot explain last month's fuel variance. Extra fuel for holding-prone destinations, standard uplift where refuelling is unreliable, and habitual captain's discretion on particular routes all happen outside the configured policy.
• Tankering is decided from a spreadsheet updated when somebody remembers, so nobody knows whether the programme captures what it claims.
• Minimum equipment list and configuration deviation list penalties reach the dispatcher by phone call or daily email, which means plans are sometimes built against a cleaner aircraft than the one at the gate.
• Dispatchers routinely override the recommended alternate, so the system's choice is decoration.
• Briefing packages are assembled by hand and notice filtering is a judgement call made eleven times a shift.

Two or more of those, at fifteen aircraft or above, is the point where the layer pays back. One of them on its own usually has a cheaper fix.

How do they compare on the things that matter in this industry?

On computation, buy wins and it is not close. Wind interpolation, performance modelling and airspace structure are commodities you should rent.

On fuel policy, the build wins where your rules are conditional on things the engine does not model: a station's history, a season, an individual aircraft's known burn deviation, a captain's pattern. Expressing policy as versioned, testable rules layered over the computed plan, with each fuel component carrying a named reason, turns the monthly variance question into a query rather than a theory.

On tankering, the build wins on data rather than mathematics. Vendor tankering usually runs from a fuel price table you maintain inside their system, which drifts from your contracted prices and knows nothing about into-plane fees or stations where uplift is operationally awkward regardless of price.

On defect penalties, the build wins because the data belongs to maintenance rather than to the planning vendor. Pulling the current defect list per registration and applying the associated penalties automatically is one of the few integrations here that is straightforward to build and improves both safety and fuel accuracy at once.

On alternates, the build wins on judgement. Operators embed preferences the configuration cannot express, such as favouring a station with company handling over one marginally closer, or avoiding an airport when customs is closed.

On integration burden and per seat economics, buy wins. Every interface you take on, meaning aircraft communications addressing and reporting system messaging usually shortened to ACARS, the electronic flight bag, maintenance and fuel procurement, is a counterparty with its own formats and its own failure modes, and each needs a defined behaviour when the feed dies mid-shift.

What does total cost of ownership look like at your scale?

The policy layer over a licensed engine, covering fuel policy rules, tankering economics against live procurement data, defect penalties, alternate preference logic and the dispatcher release workflow, runs $150,000 to $350,000 and ships in 20 to 30 weeks in Digital Heroes delivery experience. A full platform adding briefing package assembly with relevance-filtered notices, flight bag and ACARS integration, load control handover and post-flight fuel analytics runs $500,000 to $1,200,000 across 12 to 24 months.

The floor is higher than most categories because of verification. The output supports a legal release document, so expect a parallel period where every plan is computed both ways and differences are adjudicated by your chief dispatcher before a documented sign-off. That typically runs 30 to 35 per cent of the project. Any proposal treating it as a two-week test cycle has not built for a regulated operation.

The other drivers are fleet type count, since performance handling and defect penalties differ per type, extended operations approval, and supervision under two regulators with two documentation regimes. Adding a second fleet type later costs 25 to 40 per cent of the original layer, because the policy rules and workflow are reusable and the performance handling is not.

Running costs are 15 to 20 per cent of build cost annually, with an unusually large share going on integration upkeep because those four feeds change on somebody else's schedule. The planning engine licence continues as a permanent line and typically scales with fleet and sector volume. Budget re-verification as recurring work too, at smaller scale than the original, because a material change to how fuel is computed deserves a proportionate revalidation rather than a Friday deployment.

Do not frame this comparison against the planning subscription, because you are keeping it. Frame it against fuel. Start with the variance you cannot currently explain, and be clear that the build does not by itself reduce that number, it makes it attributable, which is the precondition for reducing it. Then add the tankering programme you have never measured and the dispatcher hours spent on manual policy application, alternate correction and package assembly, eleven times a shift. What you take on in exchange is verification, regulatory maintenance and responsibility for how a legal release document is computed, which should be a deliberate assumption made with your chief dispatcher in the room rather than by a procurement committee.

What does the hybrid look like, and when is it the honest answer?

In dispatch the hybrid is not a compromise, it is the only sane architecture. You are always buying the platform and building the thin layer you actually need. The only real question is how thin.

The thinnest version worth funding is the fuel policy rule engine plus the defect list integration, sitting alongside your existing release process. Policy rules make the variance attributable and the maintenance feed makes the plan reflect the aircraft as it is. Both are inside the lower half of the first band, and together they address the two items a fuel director and a safety manager will each recognise immediately.

Sequence the rest deliberately. Start with the fleet type flying your most fuel-sensitive network. Take the defect integration early, because it is cheap and it makes the rest of the project easier to fund. Leave briefing package assembly, flight bag delivery and ACARS to phase two, because dispatchers can keep assembling packages the way they do for another six months. What they cannot keep doing is applying a fuel policy nobody can audit.

Do the fuel policy extraction before the project starts. Sitting your chief dispatcher and fuel director down to write out every rule that currently lives in the operations manual, in habit, or in one captain's practice is a week of their time and it removes the largest source of mid-project discovery.

Which should you choose, by operator size and stage?

Under fifteen aircraft, short sectors, simple alternates: buy outright. ForeFlight Dispatch or a standard JetPlan arrangement, configured properly, and put the money into operations rather than software.

Fifteen to thirty aircraft, one type, meaningful fuel price variation across the network: stay bought, but run the measurement. Count the variance you cannot attribute and check whether anybody has measured the tankering programme. Those two numbers decide whether the next stage applies to you.

Thirty to sixty aircraft, one or two types, a documented fuel policy applied inconsistently: this is the crossover. Commission the policy layer at $150,000 to $350,000, keep the engine, and plan verification as a third of the project rather than a test phase.

Above sixty aircraft, multiple types, extended operations approval or two regulators: build the platform layer over 12 to 24 months, phased, with the policy engine first and the flight bag and ACARS work only after a full season has run through the new rules.

At every stage, ask a prospective developer 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. Then ask how fuel policy rules will be changed after handover. If the answer is a developer ticket, your fuel team will be back on their spreadsheet within a year.

If you want a second opinion before signing anything, Digital Heroes has delivered more than 2,000 projects with a named team you can speak to before you sign, rather than a bench you meet in month two. Nothing about that commits you to the build.