Last week we announced that Guanacaste Airport in Costa Rica, part of the VINCI Airports network, completed its digital transformation on the AirportLabs suite. SkyCore AODB, Allegra RMS, VisionAir FIDS and the Airport Community App, deployed in phases, without disrupting a single day of operations.
Whenever we announce a deployment at one of the world’s busiest hubs, people congratulate us on the engineering achievement. When we announce an airport serving two million passengers a year, the reaction is warm but different, as if the hard work happened elsewhere. I want to argue the opposite. Making enterprise airport software work at a small airport, at a price that is fair to that airport, is in some ways the harder architectural problem. And the industry’s failure to solve it has quietly cost small airports for decades.
Regulation does not scale down#
Here is the uncomfortable arithmetic of running a small airport. The international safety and security requirements that govern a two-million-passenger airport are essentially the same ones that govern a seventy-million-passenger hub. Researchers studying regional airport economics found that these requirements, virtually identical for small and large airports, translate into high fixed costs, and that an airport below roughly 200,000 annual passengers typically cannot cover its operational costs at all (Kazda et al., Transportation Research Procedia).
The same asymmetry applies to operational software. A small airport still needs a source of truth for flight data. It still needs to allocate stands, gates and check-in desks. It still needs accurate passenger information on every screen and coordinated teams on the ground. The functional surface of the problem barely shrinks. What shrinks, dramatically, is everything the traditional vendor model depends on: the budget, the IT department, the appetite for an eighteen-month implementation project.
Who has been paying for whom#
The major platforms in our industry were architected for hubs, because that is where the prestige projects and the large contracts were. The economics of that choice are visible in the market data. Analysts consistently identify budget constraints at small and medium airports as a primary restraint on adoption, with many facilities recognizing the value of modern systems but unable to justify the upfront costs (Fortune Business Insights). At the same time, high R&D requirements keep driving vendor consolidation into an increasingly concentrated market (Marketintelo), which does nothing good for the negotiating position of a small airport.
Now add the way this software has traditionally been priced: implementation projects, professional services, on-premise infrastructure, change requests. Most of that cost does not scale with passenger volume. A hub amortizes it across tens of millions of passengers. A regional airport absorbs it across two million, or two hundred thousand.
So a small airport buying a system architected for hubs pays far more per passenger, for complexity built to someone else’s requirements. In that sense small airports have been carrying part of the cost of an industry that engineered for the big end of the market. The R&D roadmap chased the hub, and the resulting weight was then sold down-market at prices those airports could barely bear. The alternative most small airports chose was simpler: spreadsheets, whiteboards and heroic individuals. That was not a technology preference. It was a pricing verdict.
Why scaling down is harder#
After building for both ends of the market, my conclusion is that scaling up is mostly a known engineering discipline. You shard, you cache, you queue, you throw hardware at throughput. The problems are hard but they are well-charted, and the customer’s budget grows with them.
Scaling down is a design discipline, and it is far less forgiving. At a hub, complexity has somewhere to hide. There is a systems integrator, a dedicated IT department, a training budget, a project office. At a small airport there is nowhere to hide anything. The same product has to install without an army of consultants, configure itself with sensible defaults, run without a resident database administrator, and be operable by a duty manager who also handles three other jobs. Every feature we ship at AirportLabs has to pass a quiet test: does this still work for an operations team of two?
That constraint reaches deep into architecture. Multi-tenant cloud infrastructure, so a small airport shares the platform instead of buying its own. Configuration over customization, because deployment has to be measured in weeks, not fiscal years. Open data models and APIs, because the airport should never be hostage to us for its next integration. None of this can be bolted on afterwards. A monolith designed for a hub cannot be discounted into a small-airport product, because the cost it needs to shed is architectural, not commercial.
Fair pricing is an architectural outcome#
This is the point I care about most. Fair pricing for small airports is not generosity. It is only sustainable if the marginal cost of serving a small airport is genuinely small. If deploying your product requires six months of professional services, no pricing model can rescue you; someone eats the cost, and eventually it is the customer. If deploying your product is largely self-service on shared infrastructure, then a price proportional to the airport’s size is simply honest accounting.
This is also how to spot the outsourcing companies masquerading as product companies, and small airports are their favorite prey. The pitch comes with a product name, a brochure and a roadmap. Behind it sits a demo and a team billing hours, so every feature the airport actually needs arrives as a change request on someone’s timesheet. A small airport signing that contract is not buying software. It is hiring a development team it cannot afford, one invoice at a time.
We chose the other path a long time ago. AirportLabs has been serving small and medium airports for over ten years, and today tens of them run their operations on our suite. Guanacaste is a milestone, not a first. The constraints that shaped the architecture were learned at airports like these, over a decade: the two-person operations team, the deployment measured in weeks, the price that has to survive a small airport’s budget review. They made the product better for the hubs too.
That is what makes Guanacaste satisfying to me, beyond the announcement itself. The airport runs the same code as our largest customers, not a lite edition or a legacy fork. The phased rollout of AODB, RMS, FIDS and the community app happened alongside live operations, and the airport’s cost reflects its scale, not a hub’s requirements amortized onto its books.
We architected for scalability from the beginning, and I have always meant that word in both directions. The industry measured itself for years by the size of the airports it could serve. I think the better measure is the size of the airports it can serve fairly.