What broke.

The dateline has changed. That story gets its own letter; for now, it’s enough to say the flight home was shorter than the six months were.

This week, the letter I promised and the one I’ve been most nervous to write: what actually breaks when you plug AI into real venues. Vendors don’t write this letter. That’s rather the point of writing it.

Here is the first thing to know about software breaking in hospitality: it almost never breaks loudly. Nothing catches fire. No screen goes blue. The dangerous failures are silent, and the most dangerous of all are the ones that report success.

A story from my own building. Months ago, a venue’s marketing message went out over WhatsApp — or so the dashboard said. Green tick. "Sent." Except WhatsApp has rules about when a business may message a guest, and outside a certain window only pre-approved templates are allowed through. The message hadn’t qualified. The platform’s answer was to refuse it, and my dashboard’s answer was to call that refusal a success. The venue toasted a delivery rate that was, on close inspection, a work of fiction.

I fixed it. Then I found the same lie living in a second code path. Then, months later, a third. In the end the real fix wasn’t to the sending at all — it was to the reporting. The dashboard now tells the operator, in plain words, when a message was suppressed and why. Which sounds like a demotion for the software and is actually the entire job: a system that admits what it didn’t do is worth ten that claim they did everything.

Another one, harder to tell. For a while, one class of venue user could change settings, press save, watch the screen say saved — and the database, for reasons of permissions plumbing too dull to detail, would quietly discard the change. No error. No log an operator would ever see. People were managing their venue and the venue wasn’t listening. When we found it, the fix took a day. Finding it took months, because nothing was visibly wrong. Silence, again.

And one confession of a different kind: the feature we killed. Early on I built an entire ordering subsystem into the WhatsApp concierge — menus by keyword, collection orders, the lot. Five thousand lines, its own screens, its own tables. It worked. It was, by any technical definition, finished. Its total production footprint after months of existing: two test orders, both mine. Nobody had asked for it; I’d simply enjoyed building it. This year I deleted every line, and the deletion was better engineering than the building had been. The graveyard of hospitality tech isn’t full of things that didn’t work. It’s full of things that worked and weren’t wanted.

What should an operator take from a founder airing his own reverts? A better question for every vendor who visits you, because the demos all look identical now and this is where they differ: don’t ask what the system does. Ask what it does when it fails. Does the dashboard ever say "we didn’t send this, and here’s why"? What happens to the booking when the integration hiccups mid-service? If the answers are fluent, you’ve found engineers. If the answers are silence — well. You already know how I feel about silence.

The uncomfortable truth of six months is that the platform I’m proudest of is mostly made of repairs. Every system leaks; I wrote that last week about bookings and it’s just as true of software. The difference, in both cases, is whether anyone is counting — and whether the count is allowed to embarrass you.

Next week: the seat is the product, properly — what 126,000 guest signals reveal about the tables everyone fights over.

— B

Disagree with any of this? Message me. I answer.

Bhrij Patel is the founder of RAYN, an AI-native hospitality intelligence platform, built after years operating restaurants from quick service to fine dining