The Licence Fee Is the Smallest Number in the Deal

What a quote can cover, and what it structurally cannot

A vendor can put a price on the licence because the licence is the only part of the arrangement the vendor controls. How inconsistent your existing records are, how many exceptions your processes have accumulated, how much slack your team has this quarter, how quickly particular people take to unfamiliar software — all of that belongs to you, and nobody could price it honestly from the outside.

So a quote is not dishonest. It is partial, in a direction that happens to be consistent: the costs it omits scale with how much platform there is and how far it sits from the way you already work. Two systems can be a licence-fee match and be nowhere near each other on everything the licence fee excludes.

It helps to stop thinking of these as hidden costs, which sounds like something being concealed, and start thinking of them as deferred ones. They arrive on a schedule.

Costs that land before go-live

Implementation gets described in weeks, which frames it as a scheduling question. It is a staffing question. Specifically, it is a question about the availability of the few people who know how the operation actually runs as opposed to how it is documented to run.

The person who can explain why your duty calculations have always been applied a particular way, which fields on a trip sheet genuinely matter, and what the maintenance forecast is really tracking, is the same person currently holding three trips together. That knowledge cannot be delegated to a junior for the duration, because the knowledge is the deliverable. The operation therefore runs at reduced capacity for the length of the project, and that shows up as slower responses and tireder staff rather than as anything you could point at in a budget.

Then there is the stretch where the old way and the new way are both kept alive, because nobody is yet willing to rely on the new one alone. Every hour of that is spent twice by definition. It is worth asking a vendor directly how long its customers typically run both in parallel — the answer describes the true cost of getting live far better than the headline timeline does.

Migration also has a habit of surfacing every inconsistency your previous arrangement quietly tolerated: the two spellings of a client name, the aircraft whose hours never quite reconciled, the certificates recorded in three different formats. None of that is the new platform's fault. All of it becomes somebody's job in the weeks before launch.

Costs that land in the first year

There is a dip after go-live that almost nobody budgets for, because it is uncomfortable to forecast: for a while, a competent team gets worse at its job. People who could do something in two minutes take ten. The dip is temporary and entirely normal, but it is paid in service quality during the period your clients are most likely to notice.

Breadth lengthens that dip in a way worth being precise about. New users do not simply learn the part of a system they need. They learn to navigate the whole of it well enough to reliably find that part — which menus are irrelevant, which settings do not apply, which warnings can be disregarded. Those are two different quantities of work, and a broad platform charges the second one to every person who ever uses it.

The first year also produces decisions with unusually long tails. Permissions, categories, reference data and workflow choices all get set early, under time pressure, by people who do not yet understand the consequences. Some of those choices will still be shaping how the operation works three years later, long after anyone remembers making them.

Costs that never stop

Training is budgeted as a launch activity, on the implied assumption that the team which learns the system is the team that will always use it. That assumption fails on ordinary staff turnover. Every departure means bringing a replacement to competence again, and every substantial release means people who had stopped thinking about the software start thinking about it again.

Then there is the role nobody plans for. A platform with real depth needs an owner inside the business: someone to manage access, keep reference data tidy, work out what a vendor change means for you, investigate things that misbehave, and translate between the team and support. In a large operator that is a job with a title. In a small one it becomes an unofficial second job belonging to whoever engaged most during implementation. It is rarely acknowledged and never resourced, and when that person is away, small things stop working in ways nobody else can explain.

Finally, capability you do not use is not neutral. It has to be configured around at setup, navigated past daily, kept from being misconfigured by someone exploring, and explained to each new starter as something to ignore. Dormant complexity still charges rent, just quietly.

The cost you only meet on the way out

Every month a platform holds your operating history, the cost of leaving it rises. There is nothing sinister in that — it is simply what happens as records accumulate. But it has a commercial consequence worth stating plainly: by the second or third renewal, you are discussing price from a position that is no longer symmetrical.

An operator who has concluded the platform is heavier than the operation needs will frequently keep paying regardless, because the alternative is extracting years of history, rebuilding workflows and retraining everyone, all while continuing to fly. The barrier does not need to be insurmountable to be decisive. It only needs to exceed the appetite of a team that is already fully committed.

The moment to address this is before signing, while you still have something to trade. How is data extracted, in what format, and how complete is it? Is that self-service and documented, or does it need a support request and a quote? A vendor that is confident about the fit will answer that without flinching.

When breadth is the requirement, not the overhead

It would be convenient to finish by concluding that large platforms are overpriced for everybody. That is not true, and the opposite error is the more expensive one.

If you hold several certificates, answer to more than one regulator at a time, integrate deeply into corporate finance or HR systems, or are growing quickly enough that this year's complexity is a poor guide to next year's, then depth is not overhead. It is the specification. Discovering mid-contract that you have outgrown a platform is a worse and costlier position than having paid for headroom you eventually grew into.

The failure mode is narrower than “enterprise software is expensive”. It is buying for a complexity you do not have and cannot articulate a path to acquiring, on the assumption that surplus capability is harmless. Everything above is the reason it is not.

Working it out for your own operation

Ahead of the next renewal or evaluation, do this once properly. It takes an afternoon and it tends to settle arguments.

• Write down the Tuesday list — what the team genuinely touches in an ordinary week. Demos are built to impress; this is the list that matters
• Convert the implementation estimate into names — which people, how many hours each, and how long both systems run side by side
• Make training an annual line — expected departures multiplied by time-to-competence, plus relearning after major releases
• Say out loud who administers it — if you cannot name them, it defaults to your most capable person and the hours come out of operations
• Ask the exit question while you still have leverage — what extraction costs, in whose hours, and whether it is documented
• Divide by what you use — the annual total over the capabilities on the Tuesday list. That number, not the licence, is what belongs in a comparison

An illustration with entirely invented figures, which you should replace with your own: four people each losing a day a week for six weeks to implementation and parallel running have spent twenty-four working days before the platform has produced a single useful thing. Add a few days per new starter after that, and a couple of hours a week of unofficial administration indefinitely. Put your own rates against it and set the result beside twelve months of licence. The shape of the answer tends to survive whatever numbers go in, which is rather the point.

The useful question was never whether a platform is expensive. It is whether you are paying for depth you have, or depth somebody else has.