When I try to explain what we are building with Constellation, the part I find hardest to convey is how much of the company sits underneath the holiday a customer sees on the screen.
A flight, a few hotel nights, some activities and a car can look like a collection of services that should be straightforward to connect, particularly when suppliers already offer APIs for each of them. Those connections are substantial projects in themselves, but the work we have had to take on extends into everything that allows a holiday business to put the services together, sell them under its own commercial terms and look after the customer once the booking exists.
That has drawn us into data engineering, recommendations, supplier infrastructure, pricing and the operational tools needed for quotations, orders, payments and reporting. I often describe it as building several startups inside one company because each area could sustain a product, a team and a roadmap of its own, while our customer needs them to work together as one dependable service.
To give that scope a familiar setting, I will follow the same family through these three essays: two adults and two children travelling from Delhi to Bangkok for three nights, then Pattaya for four, over 10–17 May. They have already chosen the route, and the work ahead of us is to turn their plans into a holiday they can buy and rely on. It is an ordinary request, which makes it a useful way to explain how much has to happen underneath it.
Building a shared view of the journey
Our suppliers describe travel through the records they need to run their own businesses. The airline works with airports and flight segments, the hotel supplier identifies properties through its own codes, and the transfer company has a catalogue of pickup points and destinations it serves. Alongside those systems, a holiday business may have direct contracts for hotels and local experiences that it knows well and wants to offer its customers.
Bringing that supply together means establishing how all those records relate to the same places and services. We need enough consistency to connect a flight arrival to a car pickup and then to the correct hotel, even when the providers use different names and identifiers.
We encountered a revealing example with Pattaya. Its nearest airport is UTP, while the family in our example arrives at BKK, which also serves the destination. We held both facts in our data, but a transfer search matched only the primary airport and therefore returned no Pattaya. The query needed the complete list of airports serving the destination, rather than the one that happened to be closest.
Resolving that distinction is part of maintaining the travel world beneath the product: locations, airports, routes, properties, attractions, stations, ports and pickup points whose identities remain consistent as we move between services. It is work that continues as sources change. An outdated name can affect autocomplete, an airport relationship can affect the journey, and a property code attached to the wrong city can make an otherwise valid supplier response unsuitable for the trip we are building.
Understanding which hotel the customer is choosing
Hotel content is another area where we have found ourselves building a data product alongside the packaging engine. Several suppliers may describe the same property with different names, addresses, photographs and star ratings, while the source with the most useful content may be different from the one with rooms available for the family’s dates.
We retain facts under the source that supplied them, together with a reconciled house view, so we can use photographs from one provider and a bookable rate from another while keeping track of where the information came from. That approach also requires care over missing information: an unknown star rating has to remain unknown rather than become an unintended statement about the property’s quality.
The catalogue also reflects the holiday business using it. A property may belong to a curated collection, contracted supply may be available only to subscribed businesses, and a destination sold as one region may cover several underlying locations. Those relationships affect which hotels should appear and which rates the business can offer.
We have had to handle cases where adding a location constraint to an already known hotel id removed a valid property from a regional package. Yet location remains important when a supplier code is ambiguous and could otherwise attach a rate to the wrong hotel. Both situations have to be understood in the query, which is why this work requires more judgment than a general rule to match all the ids.
As a founder, I see these decisions as part of the responsibility we take on when we present a property for sale. We need to understand what we know about it, where that knowledge came from and how confidently it identifies the service the customer expects to receive.
We built the way a travel business actually operates
The relationships a holiday business has built with hotels and local partners are central to what it offers. Its directly negotiated Pattaya stay may be the right option for this family, and a local partner may have an experience or a complete itinerary that gives the holiday its character. Supporting that expertise is a foundation of the product we are building.
We bring contracted inventory into the same searchable world as live supply, with the properties, rooms, rates, assets and access permissions it needs to be sold. It also has to resolve to the same location identities, so a stay from a direct contract can connect to transport and activities as reliably as one returned by a live supplier.
This creates continuing work in importing data, validating it, keeping it current and applying the right commercial rules. It is an investment in letting our customers sell the holidays they know how to deliver, including the supplier relationships they have developed themselves.
The same principle shapes how we handle a trip that is still being completed. Our pickup catalogue includes options for a hotel that has not yet been booked, a property outside the catalogue and an address to be supplied later. These reflect situations a holiday business encounters naturally: the family may want to secure the Bangkok airport car before settling on a hotel, or may be staying at a villa whose details will follow.
Representing those situations means we have to carry unfinished information forward and collect it at the right point. It gives the business room to work with its customer while the system keeps track of what is still needed to deliver the service.
Understanding the request is a product in its own right
I have given our example family a specific route to make this account easier to follow, although real requests often arrive through a conversation, a photograph or a PDF. Vector and Prism have to understand whether that input contains a choice of holidays, an agreed itinerary or an edit to a trip already being discussed.
A request to make Bangkok four nights needs to preserve the other decisions the customer has made and identify what still needs to be resolved in the dates. Once live inventory is available, a recommendation also has to refer to an offer we actually hold for the relevant property and city. Those requirements introduce their own work in language understanding, document interpretation and memory before the packaging engine can begin assembling the journey.
Owning the work over time
What stays with me as a founder is the difference between resolving one of these problems for an example and owning it across a growing product. We have to preserve the meaning of the data as suppliers change, inventory expands and different holiday businesses bring their own catalogues and commercial practices into the system.
A new source adds useful availability, together with identifiers, content differences, permissions and behaviours that we will have to support. The integrations therefore become the beginning of a continuing relationship between our systems and the supply they depend on.
Before we have searched for this family’s flight, we are already maintaining a travel data product, a catalogue and a way for our customers to sell their own supply. In the next essay, I will turn to the judgment needed to select a worthwhile holiday from that world of options, and the infrastructure required to keep the process reliable while the answers arrive.