Every hotel tech company hits the same fork. A prospect asks whether you connect to their property management system, their channel manager or their CRM. You can build that connection yourself, plug in through someone else's connectivity layer, or partner with a vendor that already owns the capability. Each answer changes your roadmap, your sales cycle and your margins for years.
This comparison sets the three options side by side using public data from the platforms hotel tech vendors actually connect to, a survey of hoteliers, and published engineering and platform costs. It ends with a simple test for picking the right option for each integration on your list.
The three options, defined
Build: your engineers write and maintain a direct connection to the other system's API, usually through its partner programme and certification.
Connect through a layer: you use an intermediary, such as an iPaaS tool, a unified API or a hospitality connectivity provider, so one connection on your side reaches several systems.
Partner: you do not build the capability at all. You agree a referral, co-sell or reseller arrangement with a vendor that already does it well, and your product stays focused.
The question is not which option is best in general. It is which option is right for one specific integration, at your current stage, given how much that integration matters to buyers.
Why the choice matters more in hospitality
Hoteliers judge software by how well it fits the rest of their stack. In a Hospitality Women's Innovation Council survey of more than 300 owners, managers and technologists, conducted in May and June 2024, only 21 percent said current hotel technology does a good job for hotels and guests. 91 percent said better collaboration among technology companies around integrations should be improved, and 86 percent said better integration processes would encourage them to invest more in technology.
That is why, as covered in why integrations sell hotel software more than features do, the integration list often decides a shortlist before a demo does. The platforms have responded by opening up, and their size shows how crowded the field is:
Platform | What it publishes about its ecosystem | What it means for a vendor |
|---|---|---|
Mews | Mews passed 1,000 Marketplace integrations in November 2023; every integration is certified by its Technical Partner Success team through registration, a certification call and a pilot at a live property; many connections are plug-and-play with zero connection fees | A clear path to build, but you join a marketplace with 1,000+ alternatives |
Oracle OPERA Cloud (OHIP) | Oracle's Luis Weir quoted OHIP as having more than 1,000 partners actively building integrations, including over 500 live on the Oracle Cloud Marketplace (June 2024); per Oracle's OHIP datasheet, API consumers are billed monthly in arrears based on actual usage | Building is self-service, but API usage is a running cost that scales with your customers |
Apaleo | The Apaleo Store lists 250+ apps and integrations; Apaleo states it makes all APIs free and available for third-party apps | Low cost of entry, smaller but focused marketplace |
Build vs connect vs partner: the comparison
Factor | Build | Connect through a layer | Partner |
|---|---|---|---|
Time to first live hotel | Slowest; includes partner registration, certification and a pilot | Faster if the layer already supports the target system | Fastest; the capability already exists |
Upfront cost | Engineering hours at your loaded rate | Subscription or usage fees plus setup | Mostly commercial and enablement time |
Ongoing cost | Every API version change, bug and support ticket is yours | Fees scale with usage or connected accounts | Revenue share or referral fees, plus relationship upkeep |
Control over data and UX | Full | Partial; limited to what the layer exposes | Low; the partner owns the experience |
Depth of integration | As deep as the API allows | Often the common denominator across systems | Depends on how well the two products already work together |
Effect on sales | Strongest proof point if buyers rank it top three | Lets you tick more boxes on RFPs quickly | Adds credibility and leads, but you share the deal |
Main risk | Engineers maintain connectors instead of building product | Dependency and lock-in to the layer's roadmap | Partner changes direction or competes with you later |
What building really costs
Most build estimates count the happy path and miss the rest. According to a 2026 breakdown of in-house integration costs, the hidden work is error handling, webhook infrastructure, authentication and API versioning. Its worked arithmetic uses the US Bureau of Labor Statistics median software developer wage of $65.38 an hour; with wages at about 70 percent of employer cost, that is a loaded cost of about $93 an hour, so every 100 engineering hours costs about $9,300 in-house. US development firms listed on Clutch typically charge $50 to $99 an hour.
The same piece cites MuleSoft's 2026 survey of 1,050 IT leaders, in which IT teams said they spend an average of 36 percent of their time designing, building and testing new custom integrations. That sample is large enterprises, not hotel tech start-ups, but the lesson carries over: integrations are a standing cost, not a one-off project.
What connecting through a layer costs
Intermediaries trade control for speed. General-purpose unified API platforms publish list prices, which give a sense of scale: as of September 2026, Merge listed $650 a month for up to 10 linked accounts and $65 per linked account after that, and Apideck listed $599 a month for its Launch plan, according to the same breakdown. These are horizontal tools for categories such as CRM, HR and accounting rather than PMS connectivity, so for hospitality systems you would be comparing hospitality-specific connectivity providers, whose pricing is usually quoted, not published.
When each option wins
Build when the integration is your product's spine
Buyers rank this connection in their top three requirements, and losing it would lose deals.
Your value depends on real-time or deep data, such as rates, inventory or folio detail, that a generic layer flattens.
You have, or can fund, an owner for the connector after launch, not just for the build.
Connect through a layer when breadth matters more than depth
Prospects list ten different systems and you need to say yes to most of them this year.
The data you need is common and simple, such as reservations or guest profiles, rather than deep operational detail.
You are pre-product-market fit and cannot justify dedicated integration engineers.
Partner when the capability is not why customers choose you
Hoteliers already have a preferred vendor for this job, and replicating it would put you in a feature race you do not need.
A partner has distribution you lack, such as relationships with management companies or a strong marketplace position.
You can agree clear terms on lead sharing, support boundaries and who owns the customer relationship.
Partnering is a distribution choice as much as a product one, so weigh it alongside the trade-offs in choosing between direct sales and channel partners in hospitality.
A four-question test for each integration
How often does it come up? Count how many lost or stalled deals in the last two quarters named this system. If you do not track it, start tagging it in your CRM now.
How deep does it need to be? If a read-only sync of common objects is enough, a layer or partner will do. If the integration is the workflow, build.
Who will own it after launch? If no one, do not build. An unowned connector breaks quietly and surfaces as churn.
What does it cost over three years? Put your build hours at the loaded rate plus maintenance next to the layer's fees at your expected customer count, and next to the revenue share a partner would take.
Most vendors end up with a mix: build the two or three integrations that define the product, connect through a layer for the long tail of systems, and partner for adjacent capabilities they will never be best at.
Whichever route you take, prove it in a live property before you put it in your sales deck. A structured pilot, as in how to run a hotel tech pilot that converts, shows whether the integration holds up with real data and real staff.
The takeaway
Build the integrations buyers rank in their top three and that need depth; connect through a layer when you need breadth quickly; partner for capabilities that are not why hotels choose you. The platforms make building easier than ever, with Oracle Hospitality Integration Platform offering self-service APIs and Mews and Apaleo running large marketplaces, but that also means a listing alone no longer sets you apart. Decide integration by integration, with deal data and a three-year cost, not by what the loudest prospect asked for this week.
If deals keep stalling on integration questions, the problem may sit earlier in the funnel, in positioning or segment choice. A free revenue leak audit shows where.
Frequently Asked Questions
Should a hotel tech startup build its own PMS integrations?
How much does it cost to build an integration in-house?
Is it free to integrate with Mews, Apaleo or Oracle OPERA Cloud?
What is the risk of using a unified API or middleware?
When should a hotel tech vendor partner instead of building a feature?
Get the latest strategies, trends, and expert advice to help your hotel tech business stay competitive and grow.
Where is your revenue actually leaking?
Twelve questions, about twenty minutes, on your own funnel. The same audit I run on day one of an engagement. No call required.
Get the free leak audit
