Resources
Build vs. buy, argued fairly
We sell the buy side, so treat this page with appropriate suspicion — and then read the section on when building is genuinely right, which is the part most vendors leave out.
Should I build travel technology or buy a platform?
Build when distribution itself is your product, when you have exactly one supplier and always will, when your volume makes per-booking fees dominate, or when your product shape is one no platform models. Buy when the technology is a cost of doing business rather than the thing customers choose you for. Both answers are legitimate.
| Area | Building in-house | On infrastructure |
|---|---|---|
| First supplier integration | Six to twelve weeks for the first, including learning the supplier's rate model, content shape and cancellation grammar. | Configuration plus a mapping run. The supplier's peculiarities are already absorbed. |
| Each additional supplier | Rarely faster than the first by as much as teams expect. Every supplier is different in a new way. | Connector configuration and a mapping pass. |
| Hotel mapping | A product in its own right. Companies exist that do only this. It is never finished, because supply changes. | Included, with a human review queue for the uncertain band. |
| Booking correctness | Idempotency, timeout reconciliation and refund arithmetic are usually learned by getting them wrong in production. | Already encoded, including the unknown-outcome path. |
| Pricing changes | Often a code change and a release, because margin logic starts life in the storefront. | A rule change in the admin, versioned and effective-dated. |
| Team required | Distribution engineers, a data engineer for mapping, and someone who owns supplier relationships technically. | Product and front-end engineering on the layer that differentiates you. |
| What you own at the end | Everything, including the maintenance burden and the parts that will never differentiate you. | Your brand, your customers, your supplier contracts and your data. Not the plumbing. |
| Switching cost later | None — it is yours. This is a genuine advantage and should not be dismissed. | Real. Mitigated by documented data export and by keeping supplier contracts in your own name, but real. |
The other side
When you should build it yourself
There are real cases where buying infrastructure is the wrong call, and a vendor who will not name them is not being straight with you.
Distribution is your product
If your differentiation is the connectivity itself — you are building a bedbank or an aggregator — then buying the layer you intend to sell makes no sense.
You have one supplier and will always have one
A single direct contract with no ambition to add more does not need an aggregation layer. Integrate it directly and keep your money.
Your volume makes the per-booking cost dominant
Above a certain scale, infrastructure fees exceed the cost of a team. If you already know your volume is there, model both.
You need something no platform models
An unusual product shape that no infrastructure supports will be a fight against the platform forever. Better to build it than to bend someone else's model.