Why building your own internal BI is not a good idea

There is a specific project that keeps surfacing in hotel groups right now, and it has a very logical shape. A commercial director notices a smart data analyst on the team. The analyst, given a weekend, wires up extracts from the PMS and a couple of the other core systems. A plausible dashboard appears. An AI assistant gets plugged in. For a quarter, it looks like the group has quietly solved the reporting problem for a fraction of the vendor cost.

The logic of starting the project is not wrong. The economics look clean on day one. Control stays in-house. Nobody has to negotiate with a vendor. The team feels empowered.

Then the second year arrives, and so does the question nobody budgeted for.

Integration maintenance is the first thing that breaks

PMS APIs ship changes. The sales-and-catering platform ships changes. The POS ships changes. The channel manager updates its field definitions. Each change individually is minor; collectively they add up to a background rate of integration decay the project did not plan for. Across any portfolio of a handful of properties, each running four or five core systems, that quickly compounds into dozens of integration surfaces to monitor permanently, and one analyst off on holiday away from the fix.

A specialist platform assigns a dedicated engineering team to this problem, with regression tests on every refresh and SLAs behind every data source. An internal build assigns an analyst, who also has a day job.

The data problem is bigger than the dashboard problem

Pulling data from a system is the easy part. Making it correct, comparable, and historically honest is the entire discipline, and it is where the internal build quietly stops being feasible.

Every hotel in a group names its segments differently. Rate codes change over time. Package components get added, removed, renamed. Cloud PMS data accuracy varies by extract and by release. For a chain to compare properties against each other, every one of those definitions has to be mapped once, then corrected where the source got it wrong, kept consistent as the source systems evolve, and preserved historically so last year’s number still means what it meant last year.

At Juyo we operate to a 99.9 per cent accuracy standard against the source systems. Hitting that number is engineering work, not spreadsheet work. It requires a continuous mapping layer, continuous corrections where the source got it wrong, and a snapshot architecture (SCD Type 2, in the trade) that remembers what the system believed on every historical day. Most internal builds get through the mapping, miss the corrections, and skip the snapshot entirely because they do not know it exists.

Cross-referencing data from different analytics is the next layer up. Pickup pace by segment is useful; pickup pace by segment overlaid with F&B outlet revenue by cover and labour cost per occupied room is useful in a completely different way. The dashboards that answer the questions executives actually ask combine three or four domains at once. Each combination requires the underlying semantics to be reconciled across source systems that were never designed to agree with each other. Reconciling them is a multi-year investment, not a sprint.

The AI layer the analyst just plugged in

In 2026, an internal data analyst can wire an AI assistant to the home-brew warehouse in an afternoon. The assistant will answer questions. The group will feel it has arrived at the frontier.

Three things to notice about the move.

First, the AI assistant inherits the data quality of what it is pointed at. If the segments are inconsistent and the pickup definition is wrong, the assistant will produce confident, articulate nonsense at speed. The internal build has just acquired a very fast machine for amplifying its errors.

Second, the AI needs context to be useful. Our own HotelGPT runs on roughly twenty years of hospitality domain context, built into every reasoning step: how segments behave across markets, how rate codes have evolved, how group blocks wash, how F&B capture varies by day-of-week and event type. A general-purpose AI pointed at a home-brew warehouse has none of that context and does not know it is missing.

Third, the attack surface has changed. That part deserves its own weight.

The security exposure the analyst does not price

Hospitality data is personal data. Guest names, passport numbers, loyalty records, payment tokens. The moment an internal tool touches a PMS extract, somebody in the organisation has become a data controller with a processing activity, a credentials file, and no DPA, no penetration test, no MFA policy, no formal audit trail.

The 2026 numbers around this problem are not comforting. VikingCloud reports that 82 per cent of North American hotels suffered a cyberattack in the past summer, and 48 per cent of hotel IT leaders say they lack confidence their team can detect AI-generated attacks. Gambit Security demonstrated an eight-thousand-dollar AI-agent campaign that compromised an airline, a hotel chain, and more than twenty-five other firms with almost no human effort per target. A Russian operator combining Claude with the HexStrike framework breached four hotel booking platforms earlier this year and exposed 2.1 million records. A single misconfigured cloud bucket at one check-in operator left roughly a million passport and driver’s-licence scans openly accessible. The McDonald’s McHire breach exposed 64 million applicants through a default password on an AI chatbot deployment: “123456”.

Between January 2025 and February 2026, at least twenty separate security incidents have been documented across AI-powered applications specifically. Many of the bolted-on AI assistants being deployed inside enterprises today were not built with auditability as a first-class feature. The personal data that passes through a prompt or screenshot does not always have a traceable home afterwards.

The internal BI build, with an AI assistant plugged in by a well-meaning analyst, now lives on the same threat surface as the companies in those headlines. We invest in continuous penetration testing, Shift Left security monitoring, cybersecurity-framework compliance, and are working toward SOC 2 and ISO certification. In 2026, that is the baseline for anyone trusted with hotel guest data.

The other things that are hard, named plainly

Beyond mapping, correction, cross-referencing, and security, the internal build inherits a long list of problems the specialist vendor has already solved. A few worth naming:

• Permissions and table segregation. When the analyst adds finance data to the warehouse so the GM can see GOP, the salary table on the next schema becomes visible to anyone the analyst grants access to. Formal RBAC is non-trivial.
• Snapshot architecture. The question “what did we believe on Tuesday” cannot be answered from a system that overwrites itself nightly. Building SCD-style history is an architectural decision, not a dashboard feature.
• Complex derived metrics. Paid versus stayed, time-machine comparisons across booking perspectives, the superman-calendar view across properties: these are specialist constructions that took specialist engineering to build the first time.
• Group block tracking across booked, blocked, picked-up, washed, and materialised. The semantics of a group reservation across its lifecycle is its own small discipline.
• Reservation deduplication across OTAs, direct, wholesale, and corporate contracts, with cost attribution per booking.
• Mobile delivery, offline-tolerant, multi-timezone, multi-currency, multi-language.
• Export formats that survive the group’s board-pack conventions.
• Twenty-four-hour operational support with named escalation paths.

An internal analyst can solve two of these. Possibly three. A specialist platform solves all of them as part of the product.

Forward innovation and the opportunity cost

A specialist platform ships features continuously because that is its full-time job. A home-brew internal BI ships features at the cadence of one analyst’s bandwidth, after their day job. In twelve months, the gap between the two is noticeable; in thirty-six, it is a competitive issue.

The commercial director who approved the project will not be the one who inherits the maintenance burden, and will not be the one explaining to the board why the group’s intelligence stack is two generations behind its competitors’.

Five questions worth asking before the project is approved

Before leadership signs off on the internal build, five questions put the risks in daylight:

“Who maintains dozens of integration surfaces across the portfolio when the analyst is on holiday, and what is our SLA on each?”

“What is our data-accuracy regression plan after every source-system update across the stack, and against what benchmark?”

“What is our historical-snapshot strategy, and have we validated that yesterday’s number can still be reproduced today, next quarter, and in two years?”

“What is our security posture on the home-brew environment: pen tests, SOC 2 roadmap, MFA policy, DPA with every integrated vendor?”

“In twenty-four months, when the specialist platforms have shipped two more generations of features, what is our plan to close the gap?”

If the honest answer to any of these begins with “we would have to figure that out”, the project has not yet been scoped. It has been started.

Landing

The honest version of the build-versus-buy conversation in hotel BI is not about cost. It is about which risks the group chooses to own and which it chooses to outsource to a specialist. Internal builds buy perceived control, and inherit integration decay, data-quality drift, security exposure, context gaps, and forward-innovation lag. Specialist platforms absorb those risks as the price of being in business.

A home-brew BI is not a lesser version of the specialist platform. It is a different allocation of risk, and the risks involved in 2026 are no longer the risks that were involved in 2015.