Build vs. buy: you are estimating the demo, not the business
Search, offers, payment, confirmation. Two quarters, and the number is honest. It is also a price for the demo, not for the operations company the demo turns into. The real decision is which parts of the lifecycle become permanent headcount.
A travel product is not a checkout with inventory behind it. It is an operations business with a checkout in front of it, and most build-versus-buy decisions get made before anyone notices the difference.
The estimate that starts the debate is usually careful and usually a price for the wrong thing. Add search. Show offers. Take payment. Return a confirmation. Two quarters, maybe three. That is a fair estimate of the demo, not of what the demo becomes: a flight that changes after ticketing, two suppliers describing the same room in different words, a refund crossing a currency and an accounting period, a traveller who needs an answer while the supplier is still deciding what happened.
So the decision is not API or no API. It is which parts of the lifecycle become your company's permanent responsibility, with permanent people attached.
Start with the responsibility, not the feature
A team can build an excellent interface without wanting to own airline recertification, supplier reconciliation or a disruption queue. The reverse holds too: a mature travel seller may need direct control over supply contracts, ranking and servicing policy, because those are what it competes on.
Before comparing vendors, write down what your company intends to still be maintaining in three years:
- 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 which items, once built, make your product harder to copy, and which are a tax that arrives every quarter forever.
The lifecycle test
Most build estimates stop at the first confirmed booking. An 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. It is a checkout demo with good taste.
Build, buy or compose?
The choice is rarely binary, and treating it as binary is how teams end up building the expensive half and buying the differentiating half.
| 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 |
We built OnArrival 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 prices the discover stage and half of the commit stage. The other three arrive later, on a schedule of their own, and they compound. Plotted honestly the two curves have 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.
Five things pull that build curve upward, and none of them are visible on the day the demo works.
Supplier change is continuous
Connecting once is not staying connected. Versions move, authentication changes, certification cycles come around, content quirks appear. Every direct connection is a small product with its own backlog and its own on-call.
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 row alone is a pipeline, not a connector, and how room mapping actually gets solved shows the machinery behind that one line.
Normalisation is product work, not plumbing
Sources disagree about names, inclusions, cancellation rules and price components, and a list of raw responses is not a comparison surface. It is a puzzle handed to the customer. Flights need a consistent offer model, hotels need property and room mapping, ground products need station identity. Teams file this under integration and then discover it is the thing that moves conversion.
The exception path is the main path at scale
Travel is purchased in advance and fulfilled by other parties. That gap is where changes, delays and cancellations live. The system needs idempotent actions, event history, clear ownership and a safe handoff to a person 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 budget line, 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 the ledger do not share identifiers, finance rebuilds the truth in spreadsheets, monthly, forever. 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. Teams discover this one late, because it is a compliance outcome hiding inside an architecture diagram. 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 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 most non-travel brands the scoring lands in the same place. Experience design, member pricing, rewards and contextual distribution are high differentiation. Supplier adapters, refund execution and settlement reconciliation are high burden and invisible to customers when they work. That is a composable boundary, reached from the scorecard rather than from a preference.
Questions to ask a potential infrastructure partner
Coverage lists are marketing. Ask how the system behaves on its worst day.
- 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 fifth question separates vendors. Everyone books; ask how much of servicing is an API call rather than an email to an operations desk. The developer quickstart is a useful first look at OnArrival's integration surface. For the operating layer, inspect Payments and the servicing sections for Flights and Hotels.
A sensible migration path
You do not have to settle the final architecture on day one, and teams that try settle it with the least information they will ever have. Start with one product, one market and a bounded cohort. Keep the ownership line explicit. Instrument every step from search to resolution, not only checkout. Expand when the operating model has survived real exceptions, not when the roadmap says to.
A good infrastructure decision preserves options. You should be able to deepen the experience, bring differentiated supply, change ranking rules or move 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.
