Build vs. buy: where should your travel infrastructure end?
The useful question is not whether your team can call a supplier API. It is which parts of the travel lifecycle should become your permanent responsibility.
Building a travel product can look deceptively finite on a roadmap. Add search. Show offers. Take payment. Return a confirmation.
That is the visible path, but it is not the operating system. A flight changes after ticketing. Two hotel suppliers describe the same room differently. A refund crosses currencies and accounting periods. A traveller needs an answer while the supplier is still deciding what happened.
The real build-versus-buy decision is therefore not API or no API. It is where your product should end and where specialist travel infrastructure should begin.
Start with the responsibility, not the feature
A team can build an excellent interface without wanting to own airline recertification, supplier reconciliation or disruption queues. Conversely, a mature travel seller may need direct control over supply contracts, ranking and servicing policy because those capabilities are its differentiation.
Before comparing vendors or estimating engineering time, write down what your company intends to keep owning as the product expands:
- The customer relationship and brand experience
- Offer ranking, merchandising and loyalty logic
- Supplier integrations and their changing schemas
- Booking state and post-booking workflows
- Collection, supplier payment and reconciliation
- Travel operations, escalation and support tooling
- Market-specific legal, tax and disclosure work
Anything on that list can be built. The question is whether maintaining it creates a durable advantage for your business.
The lifecycle test
Most build estimates stop at the first confirmed booking. A more honest estimate follows an order through its whole life:
- Discover: search across sources, normalise content and compare like with like.
- Commit: recheck availability, collect traveller details, take payment and confirm every component. The travel cart essay shows why this stage alone is a distributed transaction, not a checkout form.
- Service: change, cancel, exchange, rebook or refund while preserving a reliable state.
- Settle: pay suppliers, recognise margin, account for FX and match every movement to the order.
- Learn: expose events and outcomes to support, finance, product and analytics teams.
If a proposed architecture cannot explain each stage, it is not a booking platform yet. It is a checkout demo.
Build, buy or compose?
The choice is rarely binary. A useful model has three lanes.
| Approach | You own | A partner owns | Best when |
|---|---|---|---|
| Build the stack | Supply adapters, normalisation, booking state, servicing, money movement and operations | Only upstream inventory or payment rails | Travel infrastructure is itself your core product and you can fund a permanent specialist team |
| Buy a packaged experience | Brand configuration, placement and customer acquisition | Most UI, supply, booking and servicing | Speed and low operating overhead matter more than unique interaction design |
| Compose on infrastructure | Customer experience, ranking and the differentiating product rules | Normalised supply, order primitives, servicing and travel-aware payments | You want a native product without inheriting every supplier seam |
OnArrival is designed for the third lane: APIs and composable surfaces for the product you want customers to see, backed by common offer, order, servicing and payment primitives. The platform overview shows how those pieces relate.
Costs that do not appear in the first estimate
The first estimate usually prices the discover stage and half of the commit stage. The other three stages arrive later, on a schedule of their own, and they compound. Plotted honestly, the two cost curves have very different shapes: composing pays its integration cost early and then flattens, while building starts cheap at the demo and steepens every time the operation grows a new obligation.
The rest of this section itemises what pulls the build curve upward.
Supplier change is continuous
Connecting once is not the same as staying connected. Supplier versions, authentication, certification requirements, content quirks and failure modes change. Every direct connection becomes a small product with a backlog.
Count what one roadmap line actually expands into before estimating it:
| Roadmap line | What it expands into | The maintained surface at maturity |
|---|---|---|
| "Flights" | NDC dialects that differ per carrier, GDS session management, direct LCC APIs with no hold state | 517+ carriers, 140+ of them low-cost, each with its own change cadence and certification cycle |
| "Hotels" | Multiple sources describing the same physical rooms in different words, currencies and rate structures | A mapping problem across 2M+ properties; the working bar is roughly 97% auto-resolution with under 0.1% duplicates |
| "Ground and experiences" | Operator churn, station identity, seat maps and capacity checks with no standard schema | A long tail of small APIs that change without notice |
None of those columns appear in a demo. All of them appear in year one. The hotel column alone is a pipeline, not a connector, and how room mapping actually gets solved shows how much machinery sits behind that one row.
Normalisation is product work
Different sources disagree about names, inclusions, cancellation rules and price components. A list of raw responses is not a useful comparison surface. Flights need a consistent offer model; hotels need property and room mapping; ground products need station identity. Normalisation directly shapes conversion and customer comprehension.
The exception path is the main path at scale
Travel is purchased in advance and fulfilled by other parties. That gap creates changes, delays and cancellations. A system needs idempotent actions, event history, clear ownership and a safe handoff to people when automation reaches uncertainty. The order lifecycle essay walks through the states that system has to hold.
Then staff it. Schedule changes file whenever airlines decide, which includes 3 a.m. in your timezone, and a stranded traveller cannot wait for office hours. Covering a single around-the-clock servicing seat takes roughly five people once shifts, weekends and leave are counted honestly. That is the floor before volume adds a second seat, and it is a permanent line in the budget, not a launch cost.
Finance inherits the architecture
One customer payment may fund several suppliers on different schedules. A partial cancellation may change margin without cancelling the rest of the trip. If the order model and ledger do not share identifiers, finance will rebuild the truth in spreadsheets. The payments and reconciliation essay traces what that join has to look like at settlement.
Payments can pull you into PCI scope
Decide early whether a card number ever touches a server you operate. A hosted or redirected checkout keeps you in the lightest self-assessment tier: a short questionnaire, mostly about your provider. The moment the PAN transits your backend, for example because a supplier expects the card forwarded for a merchant-of-record pass-through booking, you are in the long-form tier: hundreds of controls, network segmentation, quarterly scans and an assessment that recurs every year. Teams that build the stack often discover this after the architecture is fixed. Teams that compose can keep card data inside the infrastructure provider's scope, or use virtual cards for supplier payment, so the PAN never enters their estate at all.
A decision scorecard
Score each capability from one to five on two axes: strategic differentiation and operational burden.
- High differentiation, low burden: build and own it.
- High differentiation, high burden: own the rules; use infrastructure underneath.
- Low differentiation, low burden: choose whichever path reduces complexity.
- Low differentiation, high burden: buy it unless a hard constraint prevents you.
For many non-travel brands, experience design, member pricing, rewards and contextual distribution score high on differentiation. Supplier adapters, refund execution and settlement reconciliation score high on burden. That naturally produces a composable boundary.
Questions to ask a potential infrastructure partner
Do not stop at coverage lists. Ask how the system behaves under pressure.
- Is there one stable offer and order model across products and sources?
- What happens when the price changes between search and booking?
- Can a customer change or cancel one component without corrupting the trip?
- How are supplier events delivered, retried and audited?
- Which post-booking actions are APIs, and which become support tickets?
- Can we own the front end without forking the underlying workflow?
- How does a refund connect to the original charge, supplier settlement and ledger entry?
- Can we bring our own supplier relationships later?
- What data can our support and finance teams inspect without engineering help?
The developer quickstart is a useful first look at OnArrival’s integration surface. For the operating layer, inspect Payments and the product-specific servicing sections for Flights and Hotels.
A sensible migration path
You do not need to decide the final architecture on day one. Start with one product, one market and a bounded customer cohort. Keep the ownership line explicit. Instrument every step from search to resolution, not only checkout. Then expand only when the order and operating model survive real exceptions.
A good infrastructure decision preserves options. You should be able to deepen the experience, bring differentiated supply, change ranking rules or move from components to headless APIs without replacing the order beneath it. If the more basic question is whether travel belongs in the product at all, use the travel readiness framework before drawing the technical boundary.
Build what makes your product unmistakably yours. Buy the machinery whose highest achievement is that customers never have to notice it.
