The pitch is that tools such as Claude Code, Cursor and Lovable have collapsed the cost of building custom software to almost nothing, and that any operator still paying software-as-a-service (SaaS) fees is leaving money and competitive advantage on the table.
The pitch is partly true. AI coding tools have changed what a small team can produce. The number of hoteliers experimenting with internal builds is rising, and Amadeus' Travel Dreams 2026 Report found that 499 of 500 surveyed hoteliers plan to invest in AI capabilities, with one in five expecting to spend more than $500,000 per property.
The question is not whether hotels should use AI. It is where they should use it. For most independent operators, boutique groups and even mid-sized portfolios, building proprietary versions of core hotel software is the wrong place to direct that investment. The property management system illustrates why most clearly, but the same logic applies to channel managers, revenue tools, customer relationship management (CRM) systems and guest messaging platforms.
This is not an argument against AI in hospitality. It is an argument against confusing AI fluency with running a hotel.
The work AI tools do well is not the work that limits hotel performance.
AI coding tools are effective at well-structured, low-stakes tasks. They produce visible artifacts quickly. A dashboard that shows current occupancy, a script that reformats a guest list, an internal page that summarizes daily arrivals—these can be generated in an afternoon.
The factors that actually limit a hotel's performance are different. They include rate parity discipline, competitive set positioning, channel mix, ancillary revenue capture, labor productivity, capital allocation and the operational decisions that follow from each. None of these produces a clean artifact at the end of a Saturday.
A custom-built internal tool does. The result is that AI coding pulls owner attention toward the visible work and away from the structural work. The build feels productive. Revenue per available room does not move.
A PMS is not a database with a nice interface
The most common vibe-coding ambition reported by operators is the property management system (PMS). The reasoning is straightforward: A PMS is expensive on a per-room basis, the underlying data model looks tractable and AI assistants can generate large amounts of working code quickly.
The reasoning breaks down on contact with what a PMS actually does. A property management system controls which rooms are available, what prices they are sold for, which discounts apply, how taxes are calculated by occupancy night and jurisdiction, how deposits and incidentals are held, how folios split across guests and corporate accounts, how the night audit reconciles to the general ledger and how reservations stay synchronized across Booking.com, Expedia, the brand site and the GDS.
Each of these has failure modes that are immediate and financial.
Incorrect availability produces double bookings. Incorrect tax calculation produces penalties. A broken channel sync produces overbookings during compression. A folio that fails to balance at night audit prevents the hotel from closing its books.
The visible portion of a PMS—the rooms grid, the arrivals list, the rate calendar—is a small fraction of the actual product.
The remainder is integrations, reconciliation logic and edge-case handling that has been refined across thousands of properties. AI-assisted code produces the visible portion confidently. It produces the remainder confidently and, often, incorrectly.
The economics favor the commercial vendor
For a 40-room independent hotel, a modern cloud PMS typically runs between $400 and $1,200 per month inclusive of standard integrations. At the midpoint, that is roughly $9,600 per year.
A serious DIY alternative carries costs that are easy to undercount. An initial build sufficient to replace a commercial PMS at a single property generally requires several hundred hours of focused work, even with AI assistance, before integrations are considered.
Channel manager, payment processor and accounting integrations each add development and ongoing maintenance burden. Tax rule changes, online travel agency (OTA) application program interface (API) changes and payment processor updates do not stop arriving once the build is "done."
The commercial vendor amortizes these costs across thousands of properties. A platform such as Mews, which processed approximately $19.7 billion in transaction volume across its system in 2025 and supported more than 42 million guest check-ins, can fund integration engineering, compliance work and 24/7 support at a scale no single property can match. The per-room fee a hotel pays is the mechanism that makes that scale economical.
Build-versus-buy math for core hotel systems rarely favors the build and it favors it less the longer the time horizon under consideration.
The pattern repeats across the stack
The PMS is the clearest case, but the same logic applies to adjacent categories. Channel managers depend on real-time API contracts with two-sided commercial dependencies.
Revenue management systems require trained models, market data subscriptions and historical demand databases that take years to assemble. CRMs require deliverability infrastructure, suppression list management and integration with the PMS. Guest messaging platforms require carrier relationships, opt-in compliance and multilingual handling.
Each of these looks tractable at the prototype level. Each carries operational obligations that compound once it is in production. A hotel owner who builds one of these systems becomes responsible for those obligations indefinitely, in addition to running the hotel.
The argument is not that internal builds are never appropriate.
There are clear cases where a property's workflow is unusual enough that no commercial product fits and a thin custom layer makes sense. The argument is that the cases are narrower than current AI messaging suggests, and that the decision to build should be made on operational grounds rather than on the appeal of the tools.
What AI is genuinely useful for inside a hotel
The productive use of AI in most hotels is not building replacement software. It is using frontier models as analytical and operational support on work that previously required outside consultants or did not get done at all.
Concrete examples that operators are reporting good results on: pricing strategy analysis using competitive set data, review theme extraction at scale across multiple platforms, draft generation and tightening of standard operating procedures, financial modeling for renovation and brand conversion decisions, labor scheduling scenario analysis,and structured preparation for ownership meetings or lender conversations. These are tasks where AI compounds for an operator without requiring the operator to take on the role of a software vendor.
The Amadeus survey data is consistent with this distribution of value. The hoteliers planning the largest AI investments are concentrating spend in revenue intelligence, forecasting and automation layered onto existing systems, not in replacing the systems themselves.
What this means for operators and tech companies
For hotel operators, the practical guidance is to separate two questions that AI messaging has blended together.
The first is whether AI should be part of the operation. For most properties, the answer is yes, and the higher tiers of frontier models are inexpensive relative to the analytical work they make possible.
The second is whether AI should be used to replace core systems. For most properties, the answer is no, and the cost of getting that question wrong is paid in operational failures that surface months after the initial build feels complete.
For hotel technology companies, the implication is the inverse.
The defensible position is not the interface. It is depth in inventory accuracy, payment reconciliation, channel sync reliability and integration breadth. Vendors that strengthen those layers and expose them cleanly to AI workflows will be more durable than those competing on AI-branded features at the surface.
The hotels that benefit most from AI over the next several years will not be the ones that built their own PMS over a weekend. They will be the ones that paid attention to where AI compounds and where it does not and made the corresponding investments in the parts of the stack that actually move revenue.
