Skip to content
Farhat Ullah.
AI

Making a no-code AI concierge survive contact with real guests

A multilingual, voice-enabled hotel assistant built on a no-code platform was unusable on phones. Fixed the layout and voice failures in single files rather than across 300+ components, and scoped the migration off the platform.

Client
Hospitality technology product
Sector
AI
Stack
Supabase · OpenAI · Vercel · CSS · Web Speech API
Year
2026
By Farhat UllahSenior Full Stack + AI EngineerUpdated

The problem

A multilingual, voice-enabled virtual hotel concierge had been built on a no-code platform. It demoed well. On an actual guest's phone it did not work.

Two failures, both fatal in a hotel lobby. A viewport bug cut off the bottom of every screen, so the thing the guest needed to tap was frequently below the fold with no way to reach it. And on iOS, focusing the chat input triggered Safari's automatic zoom, which broke the layout the moment anyone tried to type.

There was a third: on the published mobile build, voice input simply did nothing. No error, no explanation — the assistant appeared to hang.

What I built

Surgical CSS rather than a component sweep. The platform had generated over three hundred components. The tempting fix is to go through them; the correct fix was to recognise that both layout bugs were global symptoms with global causes — a viewport height assumption, and an input font size below the threshold at which iOS Safari zooms on focus. Both were fixed in a single stylesheet that applied everywhere, without editing a single component.

That distinction is the whole engagement. Three hundred component edits is a week of work, a large diff, and a regression surface across every screen. Two rules in one file is an afternoon and reviewable in one sitting.

The voice failure, traced to its actual cause. It was not the speech code. The published mobile build was being denied microphone permission by the browser, and the application had no path for that outcome — it waited for audio that would never arrive. I scoped a graceful fallback: when permission is unavailable, the assistant says so and invites the guest to type instead.

A hanging interface is worse than a missing feature. A guest who is told to type gets help; a guest watching a spinner concludes the hotel's technology is broken.

Migration off the platform. Ongoing: moving the product onto a stack it can actually grow on — Supabase for database, auth and functions, OpenAI for the assistant itself, deployed on Vercel.

Outcome

The concierge works on the devices guests actually hold, and degrades honestly when a browser withholds a permission it cannot get back.

Why it mattered

No-code platforms are very good at getting to a demo and consistently weak at the last ten percent — real devices, real permissions, real network conditions. That last ten percent is the entire difference between a prototype and something a hotel puts in front of paying guests.

It is also a reminder that the highest-leverage fix is often the smallest one. The instinct on inheriting a 300-component codebase is to start rewriting it. Finding the two rules that fix everything is better work and a much smaller risk.

Components left untouched
300+

Have a system that needs to work in production?

Tell me what's breaking — or what you're building.

Chat on WhatsApp