Hospitality
Software engineering for Travel & Tourism
Travel distribution is a thicket of legacy protocols, aggregators and half-standardised APIs, and the integration, not the interface, is where most of the cost and risk sits. We build booking systems that hold up under real search volume and, just as importantly, when a flight is cancelled at 6am and a thousand travellers need rebooking.
Why the domain matters
Travel software has to do something deceptively hard: take a fuzzy human intent (“a week somewhere warm in October, two adults, flexible on dates”), and turn it into real, bookable inventory priced in the customer’s currency, drawn from suppliers who each speak a different technical dialect. Behind a clean search box sits a distribution landscape assembled over decades: the global distribution systems (Amadeus, Sabre, Travelport), airline direct connections via NDC, bedbanks and hotel aggregators, low-cost carriers with their own APIs, and a long tail of suppliers reachable only through screen-scraping or overnight files. Very little of it was designed to work together.
The defining reality of building for travel is that integration dominates everything. A booking engine is only as good as the suppliers it can reach, the freshness of the availability it shows, and the correctness of the price it commits to at the moment of purchase. Search volume is punishing (a single package search can fan out into hundreds of supplier calls), and prices and availability move underneath you constantly, so caching, rate limits and “the price changed between search and book” are permanent engineering problems rather than edge cases. This is unglamorous, and it is where the real work lives.
And then there is disruption. The pandemic exposed what the industry already knew privately: most travel systems are built for the happy path of booking and are brittle the moment a trip changes. Cancellations, schedule changes, mass rebooking, partial refunds across multiple suppliers with different rules: this is where travel software falls down, where customers lose trust, and where agencies drown in manual work. We treat change and refund handling as a first-class part of the system, not an afterthought bolted on when the first storm hits. We build software we then operate, so we live with the 6am disruption queue, which is exactly why we take it seriously.
The challenges in travel & tourism
Integration is the dominant, hardest cost
Travel distribution is not one system, it is dozens of legacy ones with incompatible protocols, data models and quirks. GDS, NDC, bedbanks, airline direct, ground suppliers. The bulk of a travel project’s cost and risk is not the customer-facing product; it is reliably connecting to messy supplier systems, normalising their data, and handling their outages and rate limits. Teams that budget for a nice booking UI and treat integration as plumbing routinely blow through both timeline and budget.
Search at scale with real-time pricing and availability
A meaningful travel search fans out to many suppliers at once, each with its own latency, throttling and reliability. Doing this fast enough to feel responsive (while prices and availability shift underneath you), forces hard decisions about caching, timeouts, partial results and how stale is too stale. Cache too aggressively and you show prices you cannot honour; cache too little and you hammer suppliers into rate-limiting you.
Price integrity between search and book
The price a customer sees in search is a snapshot; the price the supplier will actually honour at booking may differ seconds later. Handling this gracefully: revalidating at the point of purchase, deciding when to absorb, re-quote or fail cleanly, is one of the defining correctness problems in travel. Get it wrong and you either lose margin silently or present customers with a jarring price change at the worst moment.
Disruption and refunds are where systems break
Most travel software is built for booking and falls apart on change. A cancelled flight, a schedule change, a supplier failure or a customer amendment triggers a cascade: rebooking options, multi-supplier refund rules, financial-protection obligations and anxious customers. When this is handled by spreadsheets and inboxes, mass disruption becomes a crisis, as an entire industry rediscovered during the pandemic.
Dynamic packaging multiplies the complexity
Combining flights, hotels, transfers and extras into a single dynamically-priced package is commercially attractive and technically brutal. Each component comes from a different supplier with its own availability, pricing and cancellation rules, and the package has to be bookable atomically (or fail cleanly), even though the underlying bookings are anything but atomic. Reconciling a half-booked package is a genuinely hard state to design for.
Multi-currency, FX and payment complexity
Customers pay in one currency, suppliers settle in others, and margins are thin enough that FX handling is a real commercial concern rather than a rounding detail. Add card payments across borders, alternative payment methods per market, chargebacks and PCI obligations, and payment becomes a system in its own right, one where a mistake shows up directly in the P&L.
What we build for travel & tourism
The systems this sector most often needs, built by engineers who understand the domain, not just the code.
Booking engines and search-and-book journeys
The core engine behind an OTA or agency site: multi-supplier search across flights, hotels and packages, results normalisation and de-duplication, real-time availability, price revalidation at booking, and a checkout that holds together across the different failure modes of the suppliers behind it. We build these to degrade gracefully (partial results beat a spinning wheel), rather than assume every supplier is always fast and up.
Dynamic packaging systems
Software that combines flights, accommodation, transfers and extras into single priced packages, with the orchestration to book multiple suppliers as close to atomically as the underlying systems allow, and clear, tested handling for the case where one leg books and another does not. We design the compensation and rollback logic up front, because a half-booked package left unhandled is a customer service incident waiting to happen.
GDS and NDC integration layers
A supplier-abstraction layer that connects to Amadeus, Sabre or Travelport and to airline NDC connections behind a consistent internal model, so the rest of your product is not rewritten every time you add or swap a source. This is conceptually the hardest and most valuable thing we build for travel. The layer that turns a dozen incompatible distribution systems into something your product can actually reason about.
Disruption, rebooking and refund tooling
The system most travel businesses wish they had before the last crisis: automated detection of schedule changes and cancellations, rebooking workflows, multi-supplier refund orchestration that respects each supplier’s rules and your financial-protection obligations, and agent tooling that turns a mass-disruption event from a fire drill into a managed queue. We treat this as core, not optional.
Mid- and back-office systems
The unglamorous engine room: booking management, supplier reconciliation, ticketing and document generation, margin and commission tracking, reporting, and the finance integrations that make sure what customers paid, what suppliers are owed and what your accounts say all agree. This is where agencies lose money quietly, and where good software quietly stops the leak.
Customer apps and self-service
Traveller-facing apps and portals: itinerary management, booking amendments, real-time trip updates, disruption notifications and self-service changes that take load off agents. Done well, self-service is not just a feature. It is what keeps a disruption event from overwhelming your contact centre, because customers can see their options without waiting on hold.
Where we help
A package search that stays responsive under fan-out
A dynamic-packaging search that queries flights and accommodation across many suppliers at once and returns useful results fast, streaming in options as suppliers respond, showing partial results rather than blocking on the slowest, and caching sensibly so you neither show phantom prices nor get rate-limited into failure. The engineering here is largely about latency, timeouts and graceful degradation.
Booking that revalidates price and books atomically
A checkout that re-checks availability and price with each supplier at the moment of purchase, decides cleanly whether to proceed, re-quote or fail, and (for packages), either commits every component or unwinds the ones it did, leaving no customer with a half-booked trip and no supplier with an orphaned reservation. This is the correctness core of a booking system.
Mass disruption handled as a queue, not a crisis
A storm grounds flights and hundreds of bookings need attention at once. Instead of agents working an overflowing inbox, the system detects the affected bookings, surfaces rebooking options, initiates refunds where required under the supplier and protection rules, and notifies travellers, so the event is a managed workflow rather than the day the phones melted.
Multi-supplier refunds that reconcile correctly
A cancelled package where the flight, hotel and transfer each have different refund rules, timelines and financial-protection treatment. We build the orchestration that applies each supplier’s rules, tracks what is owed to the customer versus recoverable from suppliers, and reconciles the money end-to-end, so refunds are correct and auditable rather than a manual spreadsheet reconstructed under pressure.
How we build for travel
We start with the supplier landscape, because it governs everything else. Which GDS, which NDC connections, which bedbanks and direct APIs, what each one’s data actually looks like, and where the gaps and unreliability are. We design the internal model and the abstraction layer first, so that adding or replacing a supplier is a contained change rather than a rewrite. Getting this layer right early is the single biggest determinant of whether the project stays sane.
We design search around the reality that suppliers are slow, flaky and rate-limited. That means concurrency, timeouts, partial results, sensible caching with honest freshness, and a clear policy for what happens when a supplier does not answer in time. We would rather show a fast, slightly incomplete result set than a complete one nobody waited for, and we make the price-freshness trade-offs explicit rather than hoping they never bite.
We treat price integrity and booking atomicity as correctness problems, not UX niceties. Prices get revalidated at the point of purchase; packages either book fully or roll back cleanly; and every booking moves through a well-defined state machine so a dropped connection or a supplier timeout leaves the system in a known state rather than an ambiguous one. Reconciling a half-booked trip after the fact is exactly the pain we design to avoid.
We build disruption handling in from the start, not after the first crisis. The data model, the booking records and the supplier integrations are designed so that changes, cancellations and refunds are first-class operations. It is much cheaper to design for the trip changing than to retrofit it into a system that only ever imagined the trip going ahead, and the difference shows the first time something goes wrong at scale.
Because we operate what we build, we design for the bad morning: the supplier outage, the mass cancellation, the payment provider having a wobble. Runbooks, alerting on supplier error rates, graceful degradation when a source is down, and a rehearsed answer to “bookings are failing, which supplier, and what now?”. Travel systems that are only tested on calm days fail on exactly the days that matter most.
The regulatory landscape
For UK package travel, financial protection is the defining obligation. ATOL covers flight-inclusive packages and requires that customers’ money is protected if the operator fails, which shapes how you hold funds, how you flag and price protected bookings, and what documentation you must issue. ABTA membership sets further consumer-protection and conduct standards for many travel businesses. These are not cosmetic. They reach directly into your booking records, your financial flows and the documents your system generates.
The Package Travel Regulations define what counts as a package and a linked travel arrangement, and attach real obligations to it: pre-contract information, liability for the whole package, and specific rights when things change or are cancelled. Dynamic packaging in particular can pull you into package-travel obligations you did not intend, so how your product combines components is a regulatory question as much as a commercial one.
Consumer rights around cancellations, refunds and refund timeliness are a live and heavily scrutinised area: the pandemic put refund practices under a spotlight, and the expectation is that customers get what they are owed, promptly and transparently. Software that cannot track and evidence refund obligations across multiple suppliers is a compliance liability, not just an operational inconvenience.
Payments bring their own regime: PCI DSS for card data, Strong Customer Authentication for many transactions, and the usual card-scheme rules on chargebacks and disputes. Travel’s cross-border, multi-currency nature and its exposure to fraud make this a serious area rather than a checkbox. Traveller data sits under UK GDPR, and travel data is unusually sensitive, passport details, dates of birth, movements and, sometimes, accessibility or medical needs.
To be clear about our lane: we are the engineering partner, not your ATOL/ABTA advisers or your compliance function. We build software that implements the protection flags, the refund-obligation tracking, the documentation and the audit trails your business and its advisers require, and that stands up to scrutiny. Confirming which obligations apply to your specific business model is work for people qualified to give that advice, and we will build to their requirements rather than improvise our own.
The travel integration stack
The GDSs (Amadeus, Sabre and Travelport), remain central to flight and multi-content distribution, and each has its own APIs, data conventions and decades of accumulated behaviour. Integrating well means respecting how each actually works, handling their quirks and error modes, and hiding that complexity behind a consistent internal model so the rest of your product does not have to know which GDS a given result came from.
NDC (New Distribution Capability) lets airlines distribute richer content and fares directly, and increasingly sits alongside (not instead of), the GDS. In practice you often need both, with the same route available through different channels at different fares and content levels. Reconciling GDS and NDC sources into one coherent set of options, without double-counting or confusing customers, is a real piece of the puzzle.
Hotel and accommodation content comes through bedbanks and aggregators as well as direct connections, each with its own availability, rate and cancellation-rule formats. Normalising this into consistent, comparable inventory (with cancellation policies your booking flow can actually reason about), is essential for both search and, critically, for handling changes later.
Low-cost and other carriers frequently sit outside the GDS entirely, reachable only via their own APIs or aggregators, each different again. Ground content (transfers, car hire, activities, extras), adds yet more suppliers. Every one of these is another integration to build, monitor and keep working as the supplier changes things underneath you, which is why the abstraction layer matters so much.
Behind the supplier connections sit payment and FX providers and your own mid- and back-office and finance systems. Payment orchestration across currencies and methods, and reconciliation between what customers paid, what suppliers are owed and what your ledgers say, is where the money is actually kept straight. We treat that reconciliation as a permanent, automated process, because when these records silently diverge in travel’s thin margins, it is a financial problem, not just a technical one.
Security for travel software
Travel systems hold two things attackers want: payment data and rich personal data. A booking record can contain names, dates of birth, passport and document numbers, contact details, travel itineraries and sometimes accessibility or medical information: a detailed picture of a person and their movements. That makes travel data genuinely sensitive under UK GDPR, and data minimisation and strict access control are baseline expectations, not extras.
On payments, the most important decision is to avoid holding raw card data at all. We design so that card numbers are captured and vaulted by your payment provider and what you store is a token, keeping your PCI DSS scope minimal rather than costly and high-risk. Travel’s cross-border card volumes and fraud exposure make disciplined payment handling and tokenisation especially worthwhile.
Fraud is a persistent problem in travel: stolen cards used to buy high-value, easily-resold inventory like flights, account takeover, and refund abuse. Real-time risk signals at booking and at refund, sensible velocity and anomaly checks, and step-up authentication where it is warranted all belong in the design from the start, not as a reaction after the first wave of chargebacks.
Encryption is a baseline: everything in transit over TLS, sensitive personal and document data encrypted at rest, and disciplined key management. Because bookings pass through so many third-party suppliers and payment providers, we are deliberate about what data crosses each boundary and minimise what leaves your control. You cannot leak to a supplier what you never sent them.
Around all of this sits operational security: least-privilege access for staff and agents, comprehensive and tamper-evident audit logging of who changed or refunded what, rehearsed incident response, and regular penetration testing. Because we operate what we build, these are the controls we depend on ourselves when a supplier is breached or a fraud pattern spikes, not documents we hand over and forget.
What changes
Search and booking that hold up under load
A search-and-book engine that stays responsive when it is fanning out to dozens of suppliers, degrades gracefully when some are slow or down, and revalidates price at purchase so you honour what you show, instead of losing margin silently or jarring customers with last-second price changes.
Disruption that is managed, not survived
Change, cancellation and refund handling built in as first-class operations, so a mass-disruption event becomes a managed workflow with rebooking options and correct multi-supplier refunds, rather than the day your agents and phone lines were overwhelmed and customers lost trust.
Money that reconciles end-to-end
Automated reconciliation across what customers paid, what suppliers are owed and what your finance systems record, with FX and refunds tracked correctly. In a business with thin margins, closing the quiet leaks in the mid- and back-office is often where the software pays for itself.
What we build for travel & tourism
From a first platform to modernising what you already run. The disciplines this sector draws on most.
How we deliver
- 01
Discover
We map the system, the constraints and the business it serves, including the parts nobody documented.
Architecture brief
- 02
Architect
Decisions get made, written down and defended before a line of production code exists.
Decision records
- 03
Build
Short cycles against working software. You see progress in the product, not in a status deck.
Shipping increments
- 04
Operate
Monitoring, incident response and iteration. The system is alive, so the engagement is too.
Runbooks & SLOs
Building something for travel & tourism?
Tell us the problem and the constraints you are working under. A senior engineer will give you a straight view on what it would take, and say so plainly if we are not the right team for it.
Technologies we work in
Chosen per problem, not per fashion. A selection of the stack we most often reach for.
Why teams in travel & tourism choose us
Senior engineers who know integration is the real work
Travel punishes teams that underestimate the distribution layer. Our people are senior engineers who understand GDS and NDC quirks, supplier fan-out, price revalidation and the specific ways multi-supplier bookings fail, because they have built and operated these systems, not just read the API docs.
We build disruption handling in, not on
We treat changes, cancellations and refunds as core from the first design, because we have seen (and the whole industry saw in the pandemic), what happens to systems that only imagined the happy path. Designing for the trip changing is far cheaper than retrofitting it during a crisis.
We operate what we build
We do not hand over a booking engine and walk away from the pager. Living with the supplier outages, the failed bookings and the 6am disruption queue is exactly why we take the unglamorous correctness, reconciliation and observability work seriously from the start.
Honest about the trade-offs
We will tell you plainly that integration will be the biggest cost, that caching is a compromise between speed and price accuracy, and where an ambition is more expensive than it looks. We would rather set an honest expectation up front than deliver a demo that quietly falls over on the first bad day.
Related sectors
Part of Hospitality. Adjacent sectors we also know.
Common questions
Why is travel software so expensive to build compared to the interface we imagine?
Because the visible product is the small part. Most of the cost and risk is in integration: connecting reliably to GDSs, NDC, bedbanks, airline and ground suppliers, each with its own protocol, data model, quirks and outages, then normalising all of it into something your product can reason about. A polished booking UI on top of a shaky supplier layer will fail on the days that matter. We are honest about this up front so the budget reflects where the real work is, rather than discovering it halfway through.
Can you integrate with Amadeus, Sabre, Travelport and airline NDC connections?
Yes. That abstraction layer is much of what we build for travel. We connect to the GDSs and to NDC direct connections behind a single consistent internal model, so the rest of your product does not have to know or care which source a given option came from, and adding or swapping a supplier is a contained change rather than a rewrite. Reconciling GDS and NDC content for the same routes without double-counting or confusing customers is part of that work, and it is exactly the kind of thing that rewards senior engineering.
How do you handle the price changing between search and booking?
We treat it as a correctness problem, not an edge case. Search results are treated as snapshots, and at the point of purchase we revalidate availability and price with each supplier and decide cleanly whether to proceed, re-quote or fail rather than committing to a price you cannot honour. How aggressively we cache in search is an explicit trade-off between speed and price freshness, and we make that decision deliberately with you rather than letting it happen by accident and surprising customers at checkout.
What can you do to help us cope with mass disruption and refunds?
This is where we think most travel software falls down, so we treat change and refund handling as core. We build detection of schedule changes and cancellations, rebooking workflows, and refund orchestration that respects each supplier’s rules and your financial-protection obligations, plus agent tooling and customer self-service so a disruption event becomes a managed queue rather than an overwhelmed inbox. Crucially, we design the data model for the trip changing from the start, retrofitting this into a booking-only system after the first crisis is painful and rarely complete.
Do you deal with ATOL, ABTA and package-travel obligations?
We build the software that implements them, protection flags on the right bookings, refund-obligation tracking across suppliers, the documents your business must issue, and the audit trails that let you evidence all of it, but we are engineers, not your ATOL or ABTA advisers. Which obligations apply to your specific model, especially where dynamic packaging is involved, is a question for people qualified to advise on it. We will build to those requirements precisely and flag where a product decision has regulatory consequences you may not have intended, rather than improvising our own interpretation.
Building for travel & tourism?
Tell us what the system has to do and what it cannot get wrong. A senior engineer reads it, and if travel & tourism is not a domain we know well enough to be useful in, we will say so rather than learn it on your budget.
- 01A senior engineer reads it. Not a form queue, and not an account manager.
- 02We reply either with questions or with a straight answer that we are not the right fit.
- 03If it looks like a fit, a technical call with the person who would actually run the delivery.
- 04Then scope, effort and risk in writing, before anyone signs anything.