Engineering for operations that never stop moving.
Loyalty programmes, booking flows and operational systems for airlines, travel and hospitality — where downtime is measured in stranded passengers.
- Estate walk and constraints
- Contracts and a thin live slice
- Build against the real load shape
- Peak rehearsal and degradation drill
- Operate to SLOs
Travel systems live at brutal intersections.
Travel systems live at brutal intersections: legacy GDS protocols meet mobile-first customers; seasonal peaks meet fixed capacity; loyalty economics meet real-time redemption.
The difficulty is rarely the feature. It is that the system of record was designed in another era and cannot be replaced this quarter. A passenger service system holds the inventory and the fare rules; a departure control system owns the flight once it closes; a revenue accounting system decides what the flight was actually worth. Each speaks its own dialect, most answer in seconds rather than milliseconds, and none of them were built to serve an app that a customer opens while standing at a gate. Modern travel engineering is the discipline of putting a fast, well-contracted layer in front of slow systems of record without lying about what the record says.
Then there is the shape of the load. Traffic in this sector is not a smooth curve — it is a schedule change, a fare sale, a storm front and a public holiday, and three of those arrive without warning. A platform that is comfortable at the median and falls over at the peak has failed at the only moment that counted. We design for the peak first and treat the quiet Tuesday as the easy case.
Four areas we work in.
We build in this sector as a services team and we offer a loyalty platform for airline and hospitality programmes.
Loyalty & frequent-flyer
Earning, tiers, redemption and partner ecosystems on our Loyalty & Retention engine — configured for airline economics. Accrual on flown segments, fare class and partner activity; tier qualification on miles, segments or spend with soft landings as configuration; redemption against seat inventory, upgrades, ancillaries and partner catalogues. Every movement carries its rule version and source reference, which is what makes the liability number one finance can sign.
Booking & ancillary flows
Conversion-focused booking UX over PSS/GDS integrations, with ancillary revenue engineered into the flow rather than bolted onto the confirmation page. We isolate the availability, pricing and ticketing calls behind contracts with explicit timeouts and fallbacks, cache what is safe to cache, and design the failure states — because on a search-heavy funnel the difference between a fast answer and a slow one is measured in abandoned baskets.
Operational systems
Crew, disruption and turnaround tooling — the software that decides whether a delay cascades. Ground and control-centre tools have a different brief from consumer apps: they are used under pressure by people who cannot look twice, so the interface has to make the next action obvious and the system has to stay usable when an upstream feed is late or wrong.
Guest experience
Hospitality CRM, check-in flows and personalisation that respects both service and privacy. Profiles unify across property management systems, booking channels and the loyalty ledger, so a guest is recognised without an operator re-keying anything — and consent, preference and residency rules travel with the profile rather than living in a spreadsheet beside it.
What we build, in detail.
A tier ladder you can change without a release.
Frequent-flyer economics change every year, and in most programmes changing them means a project. On our loyalty engine the ladder is a versioned document: qualification metric, thresholds, qualification window, soft-landing rules and the earn multiplier each tier carries. You simulate a proposed ladder against last year’s real activity, see exactly who moves up, who falls and what the change costs in liability, then schedule it. The programme rules and the member ledger are the same system, so a tier that changes on Thursday reprices earning on Thursday — with the old rule version still attached to every movement it produced.
- Qualification on miles, segments, spend or a combination — configured, with a full version history
- Simulation against historical activity before any change reaches a member
- Status extensions, soft landings and manual adjustments recorded with actor and reason on the audit trail
A booking funnel built for the fare sale.
Search is where travel platforms fall over. One customer generates dozens of availability calls, a fare sale multiplies that, and the system of record behind it was never sized for the traffic a mobile app can produce. We put a service layer in front of the PSS or GDS that shapes the load: request coalescing so identical searches hit the source once, short-lived caches on the calls where staleness is acceptable, hard timeouts with a degraded-but-honest response on the calls where it is not, and back-pressure that protects the source instead of hammering it. The funnel is instrumented step by step, so a conversion drop is traced to the call that got slower rather than argued about.
- Load modelled from your real search-to-book curves, then rehearsed against a synthetic peak before the season
- Ancillaries priced and presented in the same flow as the fare, with the same latency budget
- Every step measured — search, select, pay, ticket — so a regression is visible early, not at the month-end review
Disruption handled as a designed state, not an outage.
Every travel platform has a bad day: a feed stops, a schedule changes en masse, an upstream system takes ten seconds to answer. The question is whether the software has a plan for it. We design the degraded mode alongside the happy path — which functions stay live, which go read-only, what the customer is told, and what the operations team can still do by hand. Disruption events fan out on an event backbone, so rebooking, notification, lounge and loyalty consumers each react at their own pace and a slow one becomes a backlog rather than a failure. Events are queued rather than dropped, and the queue is visible.
- Named degradation levels with agreed behaviour per level, rehearsed before the season rather than improvised at 04:00
- Events published once and consumed independently by rebooking, notification and compensation flows
- Replay for late or corrected feeds — a corrected schedule reprocesses instead of being re-keyed
Three businesses, one engineering problem.
Fast layers over a system of record you are not replacing.
The PSS holds inventory, fares and the passenger name record, and it is not going anywhere this year. Our work is the service layer around it — booking and self-service front ends, the frequent-flyer programme, disruption tooling — with contracts that isolate the source system’s latency and quirks. Where the record has to move, it moves under strangler-pattern modernisation with parallel-run validation, not a big-bang cutover.
- Availability, pricing and ticketing behind explicit contracts with timeouts and fallbacks
- Frequent-flyer earning, tiers and redemption on a platform configured for airline programmes
- Revenue accounting and settlement flows reconciled to source, not estimated
One guest profile across properties and channels.
In a multi-property group the same guest tends to exist several times over — once in each property management system, again in the channel manager, again in the booking engine. We build the profile and consent layer that unifies them, then the guest-facing flows on top: booking, check-in, upsell and a loyalty programme that recognises stays and spend across the estate. Preference and residency rules live with the profile, so a personalised offer cannot outrun the consent that permits it.
- Property management and channel integrations normalised into one guest record
- Stay, spend and ancillary activity earning on the same ledger as any partner activity
- Consent, preference and residency enforced at the point of use, with an audit record
Margin engineering for OTAs and tour operators.
For a seller, the platform is the business: search performance sets conversion, supplier mix sets margin, and a failed payment or a mis-priced ancillary is a direct loss. We build search and checkout around a latency budget for campaign traffic, supplier abstraction so a new source is a configuration exercise rather than a rewrite, and the reporting that shows margin by supplier, route and channel on numbers finance recognises.
- Supplier abstraction with per-source timeouts, health checks and automatic fallback
- PCI-aware payment flows with tokenisation, 3-D Secure and clean refund and chargeback paths
- Margin and attribution reporting built on governed data models, not exports
The estate a travel business actually runs on.
PSS / GDS
Amadeus- and Sabre-class systems behind service contracts — availability, pricing, PNR and ticketing with per-call timeouts and coalesced reads
Departure control
Flight close, boarding and baggage status consumed as events so downstream systems react without polling
Revenue accounting
Coupon, proration and settlement files matched to booking and loyalty records; differences reported rather than absorbed
Property management
Hotel PMS and channel-manager feeds normalised into one guest and stay record across the estate
Payments
PCI-aware tokenised flows, 3-D Secure, multi-currency, refunds and chargebacks linked back to the original booking
Partner loyalty
Mile and point transfer with per-partner rates, caps and settlement statements on a shared ledger
CRM & campaign
Segment sync and delivery through email, push and SMS providers with consent enforced at dispatch
Data warehouse & BI
Booking, operations and ledger events exported to Snowflake, BigQuery or your lakehouse; Power BI models on top
The habits we bring to a travel engagement.
- IATA/GDS integration — Amadeus- and Sabre-class systems. We measure how these systems answer, how they fail and what they cost per call, so the service layer is designed around their real behaviour rather than around their documentation.
- Peak-load engineering for seasonal surges. Load is modelled from your own curves, not a generic profile; autoscaling and cache behaviour are rehearsed against a synthetic peak before the season, and the results are written down.
- PCI-aware payment flows. Tokenisation, scope reduction and a clean separation between the systems that touch card data and the systems that do not — with refunds, voids and chargebacks designed as first-class paths.
- Disruption-mode design: degraded-service UX planned, not improvised. Every customer-facing flow has a defined behaviour for the day an upstream system is slow or silent, agreed with operations and tested.
- Reconciliation on anything that carries value. Miles, points, fares and ancillaries are money in a different unit. Movements are keyed, replay-safe and traceable to the source event, so a difference is a report rather than an argument.
- Contracts before code at every boundary. Interfaces to PSS, DCS, payment and partner systems are versioned and contract-tested in CI, which is what lets product teams move without waiting on the estate.
- Observability from the first sprint. OpenTelemetry traces across the funnel and the event backbone, with latency budgets per step and alerting on the steps that convert.
- Region-pinned data handling, KVKK and GDPR compliant. Residency, retention and consent are design inputs, documented for auditors rather than reconstructed for them — see security & compliance.
From the estate walk to peak season.
Estate walk and constraints
We map the systems of record, their protocols, their latency and their failure modes with your architects, and agree what may not move. The output is a written integration map, a latency budget per flow and the list of assumptions we intend to test first.
Contracts and a thin live slice
The service layer goes in behind versioned contracts and one flow runs end to end on real integrations — usually a search or an earning path. Small, but real: production connectivity, real data shapes, real timing.
Build against the real load shape
Feature work proceeds while load tests run against your own curves. Where a programme is migrating, the new engine shadows the old one on live traffic and the outputs are compared movement by movement until they agree.
Peak rehearsal and degradation drill
A synthetic peak is run against the full estate, degradation levels are exercised deliberately, and the runbooks are rehearsed with your operations team. Findings are addressed before the season, not during it.
Operate to SLOs
Dashboards, alert policies and incident handling against agreed SLOs, with cover to the hours the run contract sets. Post-peak, the load model is updated with what actually happened.
Frequently asked questions
Neighbouring sectors we work in.
Bring us a problem from your industry.
Describe what is going wrong today. An engineer reads it and replies in writing with a concrete path.