Build vs Buy vs Hybrid: A Decision Framework for Tourism Tech
Almost every transport and tourism operator runs into the same fork eventually. The booking platform is creaking, the spreadsheet has grown a hundred tabs, the till is from a vendor that stopped returning emails three years ago, or the operation has outgrown whatever was set up at the start. The question on the table — usually after a long, unhappy season — is what to do about it. There are three real answers: buy a platform off the shelf, build something custom, or do a hybrid of the two.
The decision is consequential. The wrong choice locks an operation into a cost line that does not flex when the business does, a maintenance burden that quietly eats the founders' weekends, or a half-built system that does neither thing well. The right choice is rarely obvious from the outside — operator size, operational complexity, growth trajectory, and team depth all shift the answer. What follows is a framework for making the call, with costs honest and trade-offs visible.
Why operators are facing this question now
Three structural shifts have made build-vs-buy a live question for operators who would not have considered it before.
The booking-platform market has consolidated and stratified. A wave of acquisitions and consolidation through the 2010s and early 2020s left a smaller number of larger vendors, each pitched at a specific segment. The activity-and-attractions booking software space in particular has moved from a long tail of small vendors a decade ago to a handful of well-capitalised platforms operating in clear tiers. Operators in the middle — too complex for one tier, too small for another — feel the squeeze.
Legacy systems are reaching their end. Custom systems built in the early 2000s were written in technology stacks that are now expensive to maintain. The original developer has moved on, the database vendor has changed pricing, the integrations have rotted. The population of bespoke tourism booking systems written in the 2005–2015 era is now in active replacement — the founders' generation that commissioned them is moving to a buy or hybrid model rather than commissioning a successor custom build.
API-first platforms have made hybrid plausible. Twenty years ago, hybrid was theoretical — most vendors did not expose enough of their data and logic to make extension viable. The current generation of booking platforms exposes REST or GraphQL APIs, webhook event streams, and configurable business-rules engines. Hybrid — buy the core, build only what is genuinely unique — is now a real option, not a marketing claim.
The three options, framed honestly
Buy
Buying means licensing or subscribing to an existing booking and operations platform. The platform handles bookings, payments, inventory, reporting, and (depending on vendor) operations tooling. Most platforms in the transport and tourism space sit somewhere on a spectrum from "lightweight, fast to set up, narrow capability" to "deep, configurable, broader capability". The right vendor depends on where on that spectrum the operation actually sits.
What buying really costs over a five-year horizon:
Per-booking or subscription fees. Most vendors charge either a percentage of bookings or a flat subscription. Five years of fees on a growing operation often dwarfs the headline implementation cost. A platform charging 3% of bookings on a USD $4M-revenue operation pays the vendor USD $600,000 over five years.
Implementation and configuration. Even off-the-shelf platforms take weeks to configure properly. Vendor implementation fees range from USD $5,000 for a simple setup to USD $80,000+ for complex multi-vessel, multi-channel operations.
Integration burden. Connecting the platform to accounting, payment processors, marketing tools, OTA channel managers, and any custom kiosk or scanning hardware. Almost always underestimated at signing, because the edge cases in the existing systems on both sides of the integration are undocumented until someone tries to connect them.
Customisation limits. Every platform has a ceiling on what can be configured. The hard part is finding it before signing — sales demos show what works, not what doesn't.
Switching cost when you outgrow them. Real money. The Real Cost of System Migration walks through the arithmetic; migration usually costs four to six times the headline implementation number.
Where buying fails: the platform does most of what the operator needs, but the 15% of operational nuance that makes the business distinctive — the resident-card concession scheme, the multi-vessel co-op rotation, the unique package structure — cannot be modelled. The operator ends up with workarounds, spreadsheets running alongside the platform, and staff who have stopped trusting the system as the source of truth.
Build
Building means commissioning custom software — either in-house or via a contracted development firm. The system is designed around the operation rather than vice versa. Every quirk gets modelled. No per-booking commission, no customisation ceiling, no vendor product roadmap to wait on.
What building really costs:
Initial development. The number that gets quoted. A custom booking and operations platform for a mid-sized operator generally lands between USD $200,000 and USD $1,500,000, depending on scope. The Standish Group Chaos Report, which has tracked software project outcomes for three decades, consistently finds that the majority of enterprise software projects run materially over budget and deliver materially less than the originally specified feature set (Standish Group).
Ongoing maintenance. The number that does not get quoted clearly enough at signing. Industry research consistently puts maintenance at 15-20% of the initial build cost per year. The foundational benchmark is Lientz and Swanson's 1980 UCLA study, Software Maintenance Management, which surveyed 487 organisations and remains the most-cited reference in the literature (Lientz & Swanson, 1980). On a USD $500,000 build, that is USD $75,000-$100,000 every year, indefinitely, just to keep the system from rotting.
Opportunity cost. Every dollar and hour spent on internal software is not spent on vessels, marketing, or operations. The founder debugging the kiosk POS at 11pm is not running the business.
Key-person risk. The developer who built the system becomes a single point of failure. They leave, get sick, or fall out with the operator. The knowledge they hold is rarely fully documented.
Compliance overhead. PCI-DSS for card payments, GDPR or equivalent local data-protection law, accessibility standards. Off-the-shelf platforms handle these as a centre of gravity in their roadmap. Custom builds carry them as a recurring tax.
Where building fails: the initial system launches, then enters the long tail of "we never quite got around to it" features. The booking flow works but the reporting is thin. Reporting gets built but the channel integrations are missing. After five years, the operator has paid as much as they would have paid in vendor fees, has a system that does 70% of what a mature platform does, and has the entire risk concentrated in one team.
Hybrid
Hybrid means licensing a core platform for the well-understood, commodity parts of the operation — bookings, payments, inventory architecture, reporting, operational tooling — and building only the layer that is genuinely unique. The unique layer might be a custom website front-end, a proprietary pricing engine, a specialist integration with a regulator's system, or a custom packaging engine. Hybrid is enabled by platforms that expose meaningful APIs.
What hybrid really costs:
Platform fees — typically smaller than the buy-only path because the operator is not paying for capabilities they are replacing with custom layers.
Custom layer initial build — narrower scope than a full custom build. Generally USD $40,000-$300,000.
Custom layer maintenance — same 15-20%/year rule, on a smaller base. USD $6,000-$45,000/year.
Integration glue between platform and custom layer — the work the team underestimates most often. The platform's APIs evolve; the custom layer has to evolve with them.
Two vendors to manage — communication overhead, finger-pointing risk when something goes wrong at the seam.
Where hybrid fails: the platform's API does not expose what the custom layer needs. The operator ends up rebuilding capabilities the platform was supposed to provide, defeating the cost rationale. Or the custom layer balloons in scope as the team finds more places it could "just do a bit more". The original 80/20 split becomes 50/50, and the operator is paying for both a full platform AND a full custom build.
The decision framework
Below are the signals an operator weighs. Each is a directional push, not a binding rule.
Signals that push toward BUY
Operational complexity is at or below what the platform models natively. Booking flow, inventory structure, pricing rules, and operational workflows fit standard configuration.
No internal development team, and no appetite to acquire one.
Time to value matters — the need is operational in weeks, not twelve to eighteen months.
Growth trajectory is steady, not transformational. The operation is roughly the shape it will be in three years, just bigger.
Compliance burden is significant (card payments, multi-jurisdiction tax, accessibility, audit-grade reporting) — the platform absorbs this overhead.
The unique aspects of the operation are about service delivery, not booking mechanics.
Signals that push toward BUILD
The operation has a structural quirk no platform models well — multi-skipper rotation accounting, exotic inventory dimensions, regulator-specific manifest formats, a packaging structure no platform supports natively.
Booking-flow control is itself a competitive advantage.
Genuine internal engineering capability — not one developer, but a team with the depth to maintain, document, and replace key staff.
Large enough to amortise the build. As a rough heuristic, annual revenue of USD $10M+ makes the maths plausible; below that, platform economics are almost always better.
Integration burden of off-the-shelf platforms is itself the problem. The operator already runs custom kiosks, custom scanning hardware, custom regulator integrations.
Vendor lock-in is unacceptable for strategic, regulatory, or commercial reasons.
Signals that push toward HYBRID
Mostly standard, but with one or two genuinely unique components. 80% fits a platform; 20% does not.
Team can build and maintain a focused custom layer, but not a full platform.
Time to value matters for the core, but the unique layer can ship over six to twelve months.
The unique component is changing fast — a pricing strategy under active experimentation, a customer-experience layer iterated quarterly.
At least one capability the operator considers strategic enough to want full control over — typically the customer-facing booking flow or the data warehouse.
Two worked examples
Operator A. A regional tour operator running guided tours and equipment hire. Annual revenue around USD $1.8M, one owner, no internal developers. The current platform does not handle equipment hire well; the operator has been running it on a spreadsheet alongside. Growth trajectory is steady.
The framework pushes hard toward BUY, specifically toward a platform that natively handles equipment hire alongside tours. Complexity is real but bounded. Economics do not support a custom build, and a hybrid would introduce maintenance burden a one-owner operation should avoid. The right answer is the next vendor up, chosen specifically for equipment-hire depth.
Operator B. A multi-vessel vehicle ferry running a council-contracted scheduled service alongside a seasonal tourist route. Annual revenue around USD $14M, an in-house IT team of three, an existing custom-built scheduling and manifest tool that works well but is ageing. The council contract requires audit-grade reporting in a specific format.
The framework pushes toward HYBRID. The audit-grade reporting and existing scheduling tool are genuinely unique and worth keeping. The booking platform itself — tickets, vehicles, channel management, payments, customer database — is a commodity layer a mature platform handles better than a custom build will. The right answer is to license a platform with deep vehicle-ferry capabilities, integrate it with the existing scheduling tool via API, and retain the in-house team to own the council-reporting layer.
Same framework, two different answers. That is the framework working correctly. The wrong answer in tourism tech is not always build, buy, or hybrid — it is whichever option does not fit the operation's actual shape.
A 10-question diagnostic
The framework compresses to ten questions an operator can run against their own situation. Each scores 0-2, where 0 pushes toward buy, 1 toward hybrid, and 2 toward build. Add the scores; the total points to a direction.
Operational complexity. Does any one of your inventory, pricing, or business-rules requirements fall outside what mainstream booking platforms model natively? (0 = no, 1 = one component, 2 = three or more)
Annual revenue. (0 = under USD $5M, 1 = USD $5-15M, 2 = over USD $15M)
Internal engineering capability. (0 = none, 1 = one developer or contract relationship, 2 = a team of three or more)
Time to value pressure. Do you need the system live in less than four months? (0 = yes, 1 = within twelve months is fine, 2 = no time pressure)
Compliance burden. How significant are PCI-DSS, GDPR-equivalent, accessibility, and audit requirements for your operation? (0 = significant, 1 = moderate, 2 = light)
Growth trajectory. (0 = steady at current shape, 1 = some new lines planned, 2 = significant model change planned)
Vendor lock-in tolerance. (0 = high — happy to commit to a platform, 1 = moderate, 2 = low — strategic reasons to own the software)
Customer-experience differentiation. Is your booking-flow customer experience itself a competitive advantage? (0 = no, the experience is the service, 1 = somewhat, 2 = yes, the booking flow is part of the brand)
Existing custom infrastructure. How much custom kiosk, scanning, or integration code do you already own? (0 = none, 1 = some, 2 = significant)
Five-year horizon. Where do you expect to be running this from in five years? (0 = a similar platform, 1 = a similar platform with some custom layers, 2 = a fully owned system)
Scoring.
0-7: BUY. The maths and the operational shape both favour an off-the-shelf platform. Spend the effort on choosing the right one, not on building.
8-14: HYBRID. The 80/20 split is real. Buy the core, build the layer that is genuinely yours. Be ruthless about scope on the custom layer.
15-20: BUILD. The operation is large enough, distinctive enough, and well-resourced enough that custom software pays back. Hire the team properly; underestimating the maintenance line is the most common failure mode here.
The scoring is directional, not absolute. An operator scoring 9 should look at which questions pushed them there and check whether the underlying signal is durable. The diagnostic also does not capture risk tolerance — an operator at the buy/hybrid border with a low appetite for vendor lock-in should weight that toward hybrid even if the score does not quite reach it.
Where the build-vs-buy line is moving
Three trends are reshaping the decision, and operators thinking about a five-year horizon should price them in.
API-first platforms are turning more of the market into hybrid candidates. Ten years ago, hybrid was theoretical for most mid-sized operators because the platforms did not expose enough of their data and logic. That has changed materially. Platforms that expose REST or GraphQL endpoints, webhook event streams, and rules engines have made hybrid accessible to operators who would have been stuck with a buy-or-build binary in 2015.
Extensibility is becoming a feature, not a project. Visual rules builders, no-code customisation layers, and configurable pricing engines have moved from enterprise software into mid-market platforms. The work that ten years ago required a developer is now within reach of a competent operations manager. The build-side argument that "only custom can model our quirks" weakens every year as platform configurability improves.
Integration is itself becoming a product. The platforms that win in the next five years will be the ones that act as integration hubs — accounting, marketing, OTA channels, regulator reporting, hardware, and data warehouses all connected out of the box. For operators, this shifts the calculation: the value of "everything works together" is rising, and the cost of stitching a custom build into the broader operational stack is rising with it.
Build is not dying. But buy-and-hybrid will keep eating ground from build as platforms improve. Operators making the call now should test their build instinct against where the platform market will be in three years, not where it is today.
Call to discussion
The framework above is a starting point, not the answer. Every operation has signals that do not fit cleanly on the score-card — a difficult relationship with a current vendor, an internal team that is small but capable, a piece of bespoke hardware that complicates the integration story. The honest version of build-vs-buy is one part arithmetic, one part organisational fit, and one part horizon.
The operators who choose well are the ones who run the question seriously — who do the cost arithmetic over a five-year window, pressure-test platform options against the actual complexity of their operation rather than the marketing brochure, and are honest about the maintenance burden of any custom code they take on. Operators who treat it as a vendor-selection exercise tend to migrate again three years later.
If you are running the question now, useful next steps are to run the diagnostic above, read The Real Cost of System Migration for the cost arithmetic, and read Revenue Management for Beginners for a sense of the operational sophistication a mature platform can support. For operators whose complexity has been hiding inside a system not built for it, Why Booking Systems Built for Activities Struggle with Vehicle Decks covers the most common failure pattern.
The decision is rarely urgent enough to make this quarter, and almost always consequential enough to deserve a full season of clear-eyed analysis. Run the framework. Score it honestly. Where the answer is uncertain at the edges, weight the maintenance burden — the line item that quietly costs operators the most over five years, and the one most often left out of the initial spreadsheet.