About

Eighteen years in aviation software taught me what not to build — and exactly what had to exist instead.

I spent the first part of my career building the previous generation of this software — operational platforms for regional airlines and aviation operators. I built it, scaled it to production, and exited. Then I watched what came after.

What I learned is that the architecture was always the ceiling. The all-in-one monolith is seductive because everything knows everything — and that is also exactly why it fails: every customer's exceptions accumulate inside the same organism, until the customisation that built the moat becomes the trap that prevents change. Every new customer becomes a migration project. Every demand surge becomes a risk event. Every integration becomes a custom build that someone else has to maintain.

That's not a vendor problem. It's a structural one. And the lesson was not that integration is wrong — it is that integration has to happen around a durable domain model, not by putting every capability into one application. In a distributed, AI-shaped world, the alternative is a dead end no amount of new paint fixes.

I didn't decide to start a travel software company. I spent thirty years being handed the problem in pieces — workflow systems for major corporates in the 1990s, then two decades of operational software for airlines and remote-operations flying, including humanitarian air services into places with no commercial schedules, then a client relationship now in its second decade whose changing operation kept demanding what conventional travel technology structurally could not model. UnityTrip is what that accumulation was always converging on: one canonical model of workforce movement, built by someone who had watched every partial answer fail first.

Neil Middleton — Co-founder, UnityTrip