Centralizing multi-hotel room service into one cloud-kitchen network with a single source of pricing control

The product needed to work for three completely different users, each with different devices and different concerns — a hotel guest ordering from their room, kitchen staff managing a live queue, and a super admin running the operation across cities. That split is what shaped the rest of the system.

The guest experience is deliberately linear, with no back-tracking once verification starts: a QR scan (with a manual hotel-and-room-number fallback for when scanning fails), OTP verification re-checked every session since no login persists between visits, a menu filtered by veg/non-veg and organized into categories, a prepaid-only cart with a full GST breakdown, and a confirmation screen where the order ID, estimated time, and kitchen routing are handled invisibly in the background.

I carried this through two fidelity stages — structural wireframes to lock the flow logic first, then this fully-branded high-fidelity build in orange, with realistic menu content, live-feeling payment states ("Processing Payment," "Verifying Payment"), and a working demo mode that simulates the QR scan for testing without needing a real hotel room.

Kitchen staff needed something they could check between orders, not a dashboard requiring training. The screen leads with at-a-glance counts — New, Active, Done, and average service time — then a filterable order list: all hotels or one, and every stage from New through Delivered. Each order expands to show its items and a single action button that advances it to the next stage — Accept, Start Preparing, Mark Ready, Mark Delivered — so staff never have to guess what to do next. A live "new orders" badge in the header calls out anything unaccepted. Deliberately absent: pricing or revenue figures. Kitchen staff see what they need to cook and route, nothing else.

The admin panel is the operational backbone: a six-tab structure — Cities, Kitchens, Hotels, Menu, QR Codes, Reports — sitting under one hard rule: pricing is centrally controlled and propagates to every city, so no single hotel or kitchen can quietly override a price. Hotels map to exactly one kitchen each, which prevents the ambiguity of an order being split across two kitchens. QR codes are generated and managed per hotel, with PNG and PDF export for printing.

Rather than design three portals as separate products, I built a shared design system underneath all of them.

Because this system runs on a few non-negotiable business rules, I documented them explicitly as design principles alongside a "don't" list. Treating these as first-class design constraints — not just backend rules — meant the UI itself made the wrong actions structurally unavailable, rather than relying on staff to remember not to break them.

• Hotels cannot override pricing
• One hotel maps to exactly one kitchen
• No cash-on-delivery
• QR codes must uniquely identify both hotel and room
• Staff should be able to learn the interface with no formal training
• Guest ordering should require no training
• Admin changes must propagate across every city

My role throughout was direction, review, and integration — prompting each tool with the right context (design system rules, business logic like the prepaid-only and one-kitchen-per-hotel constraints), checking output against actual requirements, and stitching the pieces together into one coherent product rather than three disconnected AI outputs.