Why hotels should not vibe code their own apps

I want to be careful here, because I am not the sceptic in this story. We vibe code at Juyo. Our integration layer is built on AI-authored recipes, and it has collapsed work that used to take weeks into work that takes hours. I am not going to stand in front of a room and tell hotels that AI cannot build software. It can, and it is astonishing.

I am going to tell them something narrower and more useful. Vibe coding is an excellent way to author software. It is a very poor way to operate it. And a hotel group that does not understand the difference is about to buy itself a problem that will not surface for six months.

The number will be wrong, and nobody will notice

Ask an AI to build you an occupancy dashboard and it will build one. It will look good. It will run.

Then ask what it did with out of order rooms. With house use. With complimentary. Which room count went into the denominator, the physical inventory or the sellable inventory on that specific date. Whether a same-day cancellation is stripped from pickup or left in it. Whether a no-show is revenue. How it handled the three months in 2023 when your PMS exported a different segment code for the same corporate account.

None of that is in the prompt, so the model chose. It chose reasonably, confidently, and invisibly. Now you have a number that is wrong by two or three points in a way that is almost impossible to see, and a commercial team making pricing decisions on it.

This is the part outsiders consistently underestimate about hospitality data. The code is trivial. The definitions are the product. Twenty five years of edge cases sit underneath a metric that looks like a simple division.

Your data does not remember, and your app cannot fix that

Most hotel systems overwrite. Today’s picture replaces yesterday’s. Which means the question that actually drives revenue, what did we believe last Tuesday and how has it changed, is unanswerable, not because the app is badly built but because the history was never kept.

A vibe-coded app reads a live API. It gives you now. It cannot give you the shape of how you got here, and it never will, no matter how good the next model is. Building historical depth is an architectural decision that lives outside any prompt’s reach, made before any code exists.

The security exposure is real and it is yours

Guest data is personal data. The moment an internal tool touches a PMS, someone in your organisation has become a data controller with an undocumented processing activity, credentials sitting in a config file, no DPA, no penetration test, no MFA enforcement, and no record of who can see what.

Your own brand standards would fail this tool if a vendor brought it to you. Every serious hotel group now sends suppliers a security questionnaire that runs to dozens of controls. Ask yourself honestly whether the app your commercial analyst built in a weekend would survive the questionnaire your procurement team sends to us.

The cost is not the build, it is every Tuesday afterwards

Nobody prices the maintenance, because the build was free and felt finished.

Then the PMS ships an API change. A token expires. A property gets rebranded and its mapping breaks. The app does not crash, which would be a mercy. It quietly serves stale numbers, and someone runs a revenue meeting on them.

Who is on call at six in the morning? Who owns the fix when the person who built it has moved to another group, taking with them the only mental model of a codebase nobody else has read? Hospitality has too much turnover to accept a bus factor of one on anything that touches pricing.

Trust is the asset you are actually gambling

This is the argument I would make even if every technical concern above were solved.

It takes years to get a commercial organisation to trust its numbers, and one bad quarter to lose it. Once a GM has been embarrassed in a meeting by a figure that turned out to be wrong, that person is done. They go back to their own spreadsheet, permanently, and every future analytics initiative in that hotel starts from behind.

A vibe-coded app risks the single asset that is hardest to rebuild, in exchange for a saving that was mostly imaginary.

So vibe code this instead

Use it, but point it somewhere the downside is bounded.

Use it for one-off analysis you will throw away tomorrow. Use it for internal admin that touches no guest data and no pricing. Use it to build the mockup that shows your vendor exactly what you want, which is the highest return use I know of, because the hardest part of buying software has always been articulating the requirement. An afternoon with a prototype will specify your needs better than a 40 page RFP written by committee.

And notice what we actually do with it, because the distinction matters. We vibe code integrations, inside a governed environment, against a validated schema, with review, with tests, with monitoring, and with a named human who answers for the output. The AI authors. The platform constrains. A person is accountable.

Icarus did not fall because the wings were badly made. The wings were superb. He fell because nothing in the design told him how high was too high.

Build the prototype. Then let someone who owns the consequences build the system.