By Pablo Revale

Yours Won’t Be Our First

A test you can run on any hospitality tech vendor, including us: ask them to name the failure before it happens.

July 31, 2026 · 6 Minutes

“WE’VE DONE THIS BEFORE” IS WORTH NOTHING

Every technology vendor in this industry says they understand hospitality. The claim is free, which means it carries no information, and you have no way to test it inside a sales cycle. So here is a better test, and you can run it on us or on anyone else. Ask them to name the failure before it happens. A team that has shipped in hotels can tell you, without seeing your code, which part of your project will slip and why. A team that has not will tell you about their process. Process is what you present when you do not have patterns.

IT IS ALMOST NEVER THE SOFTWARE

Skift Research found that 63% of hotel technology budgets go to maintaining legacy systems, many of them not AI compatible and unable to support complex data integration, while 86% of hoteliers plan to increase technology investment. Deloitte reports that 54% of hoteliers think the technology available to them cannot meet what guests expect. Together those numbers describe an industry buying new capability and installing it on foundations that cannot carry it. Which is why hotel projects fail at integration, migration, and cutover rather than at features. The build is rarely the risk. The seam between the new thing and the twenty year old thing is the risk.

THE FIVE THINGS WE EXPECT BEFORE KICKOFF

These are the patterns we now assume are present until proven otherwise. One, source of truth is ambiguous. Somebody will tell you the PMS owns rate, the CRS actually does, and there is a nightly job neither team remembers that overwrites both. Two, the interesting defects live at night audit rather than in the happy path, so a test plan has to advance the business date and cross a daylight saving boundary. Three, the migration is unscoped. Content, URLs, redirects, and analytics continuity get treated as launch week tasks instead of a workstream with its own estimate. Four, measurement will break at cutover and nobody will notice for a quarter, because a broken tag reports a smaller number rather than an error. Five, the handover is assumed rather than designed, so a year later the client cannot ship without the vendor, which everyone calls a partnership until renewal. We put those five on the table in the first conversation. If we are wrong about your stack, that is a good outcome and a shorter project.

THE RISK YOU’RE BUYING IS THE LAUNCH

Buyers evaluate build quality and almost never evaluate cutover strategy, which is where the money is actually exposed. Two techniques do most of the work and neither is exotic. Build in parallel and swap at the boundary, so the old system keeps taking transactions until the second the new one is proven and the rollback is a URL change rather than a restore. And ramp traffic instead of launching, starting with a small segment and increasing while watching performance and real user feedback, because on a guest facing product at volume the cost of a bad release is not a revert, it is a support queue and a guest at a front desk. Ask any vendor how they intend to cut over. The answer tells you more than their portfolio.

SPECIALISING COSTS US MONEY

There is a version of this argument that sounds like marketing, so here is the uncomfortable half. Turning down non hospitality work costs revenue, and it makes us more fragile to a downturn in one industry than a generalist shop is. What it buys is the only thing that cannot be acquired inside a sales cycle: pattern recognition across the same failure modes, in the same systems, under the same constraints. We are not better engineers than a good generalist team. We have seen your specific problem more times, which means you are not funding the part where we learn it.

WHAT THAT LOOKS LIKE WITH NUMBERS

The Sandals travel advisor portal was handling roughly 60% of Unique Vacations’ sales when we rebuilt it. We wrote the codebase from scratch, ran the new portal in parallel with the old one, and swapped URLs at launch so reservations were never interrupted, moving a platform doing 600 million dollars without a maintenance window. Their two mobile apps, one iOS and one Android, became a single React Native product in under four months, now live across 19 properties in 9 countries and carrying about 16,000 daily user interactions, released by ramping traffic from a small segment upward rather than launching to everyone. On their website we migrated more than 500 pages to a headless CMS with about 100 coded components, on a property serving over a million monthly users, and trained their marketing team to run it. For PRIOR we led discovery and built a booking platform completing end to end booking in under three minutes, with more than 35,000 new subscribers since deploy. For Boutique Homes, around 1,500 homes, analytics led iteration produced roughly 12,000 monthly users and more than 70 new bookings a month. Different problems, same industry, every time.

IF YOU WANT THE TEST INSTEAD OF THE PITCH

Send us your stack and the thing you are trying to launch. We will name the failure modes we expect to find in it before we quote anything, and you can judge us on whether we were right.