Deep in the mechanics of British aviation policy sits a piece of software doing critical work that almost nobody notices. The National Aviation Passenger Allocation Model (NAPAM) runs the calculations that help shape where billions in transport investment flows. It forecasts which airports passengers will choose, across 29 UK locations and four major European hubs that British travellers favour.
This month, the Department for Transport posted a tender seeking a programmer willing to keep NAPAM alive for the next three years. The price: up to £100,000. The job involves technical support for what amounts to 10,000 lines of C++ code written in a Microsoft .NET environment, with Excel spreadsheets for data input and output.
What strikes you first about this tender is not the cost, but how modest it seems for work this vital. The supplier will spend just £33,000 per year, before VAT, to maintain software that informs policy affecting the entire UK aviation sector. The contract even includes a caveat: This budget is non-committal; therefore the Authority cannot guarantee volume and spend.
NAPAM has been running since at least 2010, when it underwent independent peer review. It has been updated in 2017, 2022, and 2024, with the Civil Aviation Authority providing passenger survey data to calibrate where travellers are likely to depart from. The software's longevity is not a sign of excellence; it is evidence of institutional inertia.
The tender reveals something less comfortable about how government procures and maintains critical technology. A single programmer cannot reasonably become expert enough in a 16-year-old system to deliver reliable work for a fraction of a consultant's annual fee. The department is not buying sustainable support. It is buying time.
This story fits a much larger pattern. According to research tracking public sector technology spending, the UK government allocates nearly £2.3 billion annually to maintaining outdated systems. That sum represents almost half the government's entire IT budget, resources that cannot be redeployed toward innovation, better services, or defending against modern cybersecurity threats. Over a quarter of digital systems in central government are outdated, with some departments reporting more than 70% legacy infrastructure.
The argument for keeping NAPAM on life support is pragmatic: it works. It has been peer reviewed and validated for policy development. Rebuilding it from scratch would be costly, risky, and time-consuming. Replacing proven systems requires not just new software but retraining staff, validating results, and managing the uncertainty of transition.
But this reasoning becomes self-defeating. Each repair, each patch, each new contract to find someone willing to work with obsolete tools makes modernisation more daunting and expensive. The hidden costs accumulate: the increasing difficulty of hiring developers who know C++, the inflexibility to adapt to new policy needs, the security vulnerabilities inherent in older code bases, the opportunity cost of resources locked into maintenance rather than innovation.
The Department for Transport faces a genuine trade-off. Immediate modernisation could cost millions and take years. Keeping NAPAM running costs relatively little now but postpones a more fundamental reckoning. There is no simple answer. Yet the tender itself suggests how thin that postponement has become. Only a single coder, at a fraction of their time, keeping the lights on. That is not a sustainable solution; it is a temporary patch masquerading as one.
The Department has published its aviation modelling framework setting out how NAPAM fits within broader forecasting strategy. Reading such documents is one thing. Maintaining the decades-old systems they describe is another.