TravelUnder NDA
Flight booking engine on Sabre GDS
Tourism company
One Angular booking engine on Sabre GDS, embedded into several travel portals and talking to each of them, with every control built from scratch.
Results
1
Booking engine shared by every portal
A change ships everywhere at once
0
Third-party UI packages
Every control built in-house
100s
Itineraries per search
Rendered progressively, never all at once
The challenge
A tourism company needed flight search and booking on Sabre GDS across several separate portals. Rebuilding the same search inside each portal would have meant four copies of the same logic to maintain, and four places for a fare-rule change to go wrong. Sabre also returns large result sets, and the interface had to stay instant while filtering hundreds of itineraries.
What mattered most
- 1One engine for several portals
- 2Hundreds of results per search
- 3No third-party UI packages
What we built
01Architecture
Built once, embedded everywhere
Instead of reimplementing Sabre search in every portal, we built it once and embedded it. Each host system talks to the same booking surface in both directions, so a fix or a fare-rule change reaches all of them at once.
02Components
No UI packages: every component is ours
The date-range calendar, the airport picker, the traveller selector, the filter rail and the itinerary cards were all written for this product. That kept the bundle small and left no third-party upgrade to block the roadmap.
03UX
A from/to calendar built from scratch
Two months in view, one continuous range across them, fully keyboard operable, and aware of booking rules: a return cannot precede a departure, and disabled days still read correctly to assistive technology.
04Search
An airport picker that actually searches
It matches city, country, airport name and IATA code at once, so "new york", "JFK" and "Kennedy" all reach the same result, and it is debounced rather than firing a request on every keystroke.
05Performance
Tuned for the volume Sabre returns
Debounced inputs and throttled scrolling keep the main thread free, signals give fine-grained updates instead of broad change detection, and infinite scroll renders hundreds of itineraries progressively rather than all at once.
The outcome
One engine instead of a copy per portal: changes ship everywhere at once, and a search that returns hundreds of itineraries stays responsive. The product is under NDA, and we are happy to demo it on a call.
Inside the project
The search panel at rest: trip type, route, dates and travellers in a single row. 
The date-range calendar: two months and one continuous from/to selection, written from scratch. 
Traveller and cabin selection: adults, children, infants with and without a seat, and four cabin classes. 
An expanded itinerary with segments, amenities, baggage allowance, fare breakdown and fare rules.
