The buildout
Western economies are rebuilding domestic energy and resource capacity — gas processing, critical-minerals extraction, generation, transmission — and the deposits and sites are mostly remote. Remote capacity means rotational workforces: crews moved on schedules the operation sets, not schedules an airline sells. The demand is not only Western — energy capacity is being locked in globally this decade — and that carries a second consequence for Western operators: the systems that run critical workforce logistics increasingly need to sit in Western jurisdictions, on Western clouds.
This holds whichever energy future arrives. A renewables-heavy grid needs critical minerals mined in remote places and transmission built across them. An energy-security posture needs gas produced, processed, and shipped from home territory. Electrification and AI are driving the largest electricity demand growth in decades, which needs all of the above. Every path through the 2020s runs through remote-site construction, and remote sites run on rotational workforces. The thesis does not require taking a side in the energy debate; every side builds.
Each new site is a workforce-mobility problem that lasts the life of the asset. Construction crews first, then decades of operating rotations. The mobility spend is committed the day the project is sanctioned; the only question is how much of it is wasted.
The gap
Workforce mobility for the buildout runs on systems designed for something else. Corporate travel tools were built for office workers and expense compliance. Airline systems were built to sell the airline's own inventory at maximum yield. Rotational logistics sits in a no-man's land between the two: organisations hand it to carriers and charter brokers who have no systems for managing a client's demand against leased capacity — no demand-shaping, no visibility of budget leakage, no passenger experience when things go wrong.
The result is measurable. Comparable small-fleet operations average roughly 40% seat utilisation on capacity that is paid for whether or not anyone boards. The waste is not a procurement problem; it is a missing-software problem.
Disruption is the operating condition
In this vertical, disruption is not the exception — weather, route closures, medical evacuations, and pandemics are the normal operating environment of remote-site work. The COVID record is the proof case: scheduled commercial aviation collapsed by more than 90%, while resource-sector rotation traffic intensified — charter air bridges, essential-industry exemptions, relocated workforces. Organisations that controlled their own transport kept operating; organisations that depended on commercial schedules stopped.
When the system fragments, spend migrates from seat volume to coordination complexity. The coordination layer is what a platform monetizes — and black-swan interruptions to commercial travel push more organisations toward leased capacity each cycle, not fewer.
The thesis
The winner in this category is whoever builds demand-side management on infrastructure that holds under surge.
An adjacent category exists — camp-and-crew logistics platforms that manage charter manifests and bolt commercial bookings alongside, and thin FIFO booking portals. What we have found nobody building is the unification: one booking engine, one PNR, one policy layer across leased and commercial content, with enterprise finance integration running in production. Beyond that category sit the two old answers — a bespoke one-off from a Big-Five consultancy at the cost and timeline that implies, or a conventional travel SaaS whose fixed roadmap cannot bend to one company's rules. UnityTrip is configurable to the operation like the bespoke build, and operated as a product like the SaaS. The adjacent products prove the demand; the seam between them is the opportunity.
The booking layer shift
We expect the booking interface itself to commoditize. Agentic booking assistants — AI agents acting for individual travellers — are already emerging for commercial travel, and their adoption case in the enterprise is direct: they replace team travel arrangers, a visible cost line. We expect rotational travel to follow.
When an agent books on a traveller's behalf, the scarce capability is not the interface. It is the layer the agent must call: who is entitled to which seat, in what priority, against which quota, with what consequence for a no-show — decided deterministically, identically every time, and explainable when the answer is no. UnityTrip already runs that layer in production. Our policies are machine-readable by design, the engine is deterministic by design, and an agent is just another client of it. That layer is the operational ontology of the business — the structured model of entitlements, assets, and rules that any interface, human or agentic, must consult.
That is why this shift is our tailwind rather than our risk: we do not need to own the booking interface, and we intend to partner with agentic front-ends rather than compete with them. The interface can change hands; the allocation layer is where the operational truth lives.
Proof one: the demand-side machinery exists, and it is ours
Neither incumbent category — corporate-travel software nor airline systems — has machinery for shaping demand against leased capacity. UnityTrip's is in production: a priority matrix ranking passenger types and trip reasons, per-rule quotas and booking windows, penalty points scaled to departure proximity, displacement rules for full flights, and go-show automation that fills a freed seat minutes before departure. In production it lifts leased-fleet utilisation from the ~40% industry average to around 90%, cuts no-shows by roughly half, and brings the bulk of logistics once considered too complex to automate under policy-governed workflow. The levers behind it are set out in our utilisation benchmarks.
The same machinery is public as a free tool: the Leased Travel Policy Builder turns an organisation's rules into a machine-readable policy a booking engine can execute. We published the category's demand-side logic before incumbents had a name for it.
Proof two: architecture built for the worst day
Look-to-book surges correlate exactly with disruption events. A cyclone closes a site, a roster blows up, and every affected worker and coordinator searches simultaneously — many times normal load, at precisely the moment the service must not degrade. Look-to-book ratios and their surge multiples are publicly documented across the travel industry, and agentic booking will push them higher still: agents shop exhaustively and never get tired. A booking system's worst load day is its client's worst operational day, and that day decides the renewal.
UnityTrip is event-sourced and natively distributed — Azure Container Apps over Cosmos DB, work queued and streamed rather than contended in a single database — designed to absorb surges of 10 to 1000 times normal activity. Several platforms claim distributed architecture; a useful test is to read their engineering job advertisements and see what their systems are actually made of.
Consider the failure mode directly. A single rogue automation inside a customer's trusted network — a misconfigured script, or increasingly a misbehaving AI agent — can hammer a platform with more than 400,000 requests in a few hours, roughly twenty times its normal baseline. An architecture that relies on perimeter security faces a binary choice at that moment, because it cannot see which identity inside the trusted perimeter is responsible: block all of the customer's traffic and stay up, or stay open and go down. UnityTrip is built to do neither. Cosmos DB autoscale absorbs the surge — throughput expands automatically at negligible marginal cost, with data partitioned to avoid hotspots — while per-identity observability isolates the offending identity in real time, down to the individual account, so the disruptor is stopped without blocking the customer. Neither answer is available to a SQL monolith behind a perimeter. In an agentic world, per-identity observability and cheap surge headroom stop being architectural preferences and become the product.
Posture
UnityTrip is incorporated in New Zealand and runs on Microsoft Azure with regional data residency — critical workforce logistics sitting in a Western jurisdiction, on a Western cloud, as the buildout increasingly requires. A quiet asset for clients who care about vendor neutrality and data sovereignty, stated plainly rather than sold.
The architecture is also the cost structure. Infrastructure as code — BICEP, automated tenant provisioning — makes a new client configuration rather than an implementation project, and automation does the work that legacy SaaS carries as expensive, unwieldy headcount. UnityTrip is a lean layer by construction: low cost per transaction, low headcount per tenant, onboarding measured in weeks. The same amplification applies to the build itself — experienced consultancy amplified by frontier AI does the design and delivery work legacy vendors staff with teams. Frontier AI at build time; determinism at run time. The platform argument in full — one canonical model of workforce movement, projected per tenant and executed deterministically — is stated in the platform thesis.
Because the platform is defined in code, each client chooses where to sit on the cost-and-resilience curve: a lean single-region footprint, or fault-tolerant, geo-replicated, active-active regions that cost more and fail over without interruption. The same codebase provisions either, and a client can move along the curve as its needs change. Across that range, infrastructure runs as much as one to two orders of magnitude below the SQL-backed platforms this category has historically required — a structural cost position, not a promotional discount, and the source of the margin that funds the company without outside capital.
The company is founder and customer funded and cash-flow positive on long-term contracts. We are not dependent on raising; we are selective about capital and partners who understand the structural position. The conversations we want are with people who read this page and recognised the shape of it.
Talk to us
If you think in these terms — the buildout, the gap, the surge problem, the agentic shift — we would like to hear from you.