Canary Food & Beverage Ordering
I designed a 0-1 food & beverage ordering platform specifically for hotels. This was the latest addition to Canary's suite of products aimed at increasing hotel efficiency and increasing their ancillary revenue. Through a scrappy and highly iterative approach, our team developed launched the MVP in about four months to several pilot customers and over $50k in committed ARR.
We built a mobile-first ordering experience for our guests that served as an extension to our existing guest experience platform. Guests can browse available menu items, add to their carts, and then send their orders to hotel staff easily. To manage inbound orders, we built a dashboard and notification system that enabled operators to easily notify their kitchen staff and complete fulfillment.
Room service, ordered on your phone
Guests scan a QR code and land in the outlet's menu — no app, no account. Browsing, modifiers, and the cart all live on one surface, so a guest can go from “what's open” to a submitted order in under a minute.
Bird's eye view of all your orders
Staff see every inbound order in one lane and move it through approve → prepare → deliver. The side sheet carries the full ticket, so nobody has to hold a guest's modifiers in their head while walking to the kitchen.
Keeping the menu honest
The item library is where a property's menu actually lives. Availability is a single toggle — the fastest edit a kitchen makes during service — and destructive actions stay behind a confirm, because 86'ing an item and deleting it are very different intents.
Writing the outlet page
Every field an operator fills in renders live in the guest preview beside it. Hotel staff aren't content editors by trade, so the screen shows the consequence of each keystroke instead of asking them to imagine it.
The order queue sorts by time to delivery, not time received. Urgency badges surface anything at risk of slipping during a breakfast rush, so staff never have to triage by memory.
Opening an order shows everything fulfillment needs in one panel: guest contact details, room or delivery location, items with modifiers, and scheduling for orders placed ahead.
Context
Guests' late-night munchies were increasingly going to DoorDash instead of the front desk, so we rebuilt room service to be modern, convenient, and visually enticing. One hotel we spoke to ran breakfast on door hangers. Guests forgot to hang them, staff missed pickups, and complaints piled up. At most properties the alternative was the front desk phone: misheard orders, tied-up staff, and enough friction that guests simply gave up. Meanwhile, Canary was losing deals in APAC markets where mobile ordering is table stakes.
Canary's Guest Hub was still a static content product. F&B ordering would make it transactional: a revenue engine, not just an info layer. The discipline was scope: no marketplaces, no kitchen software. Just get a guest's order to staff efficiently.
Our approach
There were four major decisions that defined the design:
- Built upon our existing infrastructure: fast implementation was important in order to go-to-market quickly. We designed mobile ordering as an extension to our existing guest experience and upselling platforms using similar patterns, but tweaked to match food & beverage use cases.
- Delivery type drives the experience: hotel customers wanted to go beyond in-room dining in order to expand channels for revenue. We had to design a flow that flexibly allowed for alternative locations such as orders delivered poolside, or to the hotel lounge.
- Five system objects as the IA backbone: Ordering Outlets, Menus, Items, Modifier Groups, Orders. Manage items once, compose menus flexibly.
- Works with or without a PMS: reservation-linked ordering when integrated, manual entry fallback for everyone else. No POS requirement meant shipping to the whole market.
How hotels build their menus: create an item once, then reuse it across any menu and ordering location.
Research & Discovery
Customer interviews with hotel F&B staff, competitive analysis, and usability testing on a fully interactive Next.js prototype I built, which went on to become the primary demo tool for sales calls and GTM enablement. The research drove three calls: no POS requirement (a POS dependency would have blocked 80%+ of potential customers), a staff dashboard sorted by time-elapsed urgency so orders never get missed during peak hours, and a no-download mobile web flow using patterns guests already know. Once early adopters went live, I ran the customer feedback calls myself — walking HOMA's Thailand properties through the product while demoing my own prototype.
Customer interviews with hotel F&B staff, competitive analysis, and usability testing on a fully interactive Next.js prototype I built, which went on to become the primary demo tool for sales calls and GTM enablement. The research drove three calls: no POS requirement (a POS dependency would have blocked 80%+ of potential customers), a staff dashboard sorted by time-elapsed urgency so orders never get missed during peak hours, and a no-download mobile web flow using patterns guests already know. Once early adopters went live, I ran the customer feedback calls myself — walking HOMA's Thailand properties through the product while demoing my own prototype.
Impact & Results
F&B Ordering hit GA in February 2026 with two verbal commitments from demos alone and 50 pilot orders validating demand before launch. The delivery-type model became the architectural pattern for all future ordering scenarios (spa, activities, table-side), and APAC enterprise interest is building, with $25K+ in potential ARR from interested properties.
The platform also started clearing enterprise deals: my HubOS service-requests design solved Eurostars' #1 deal-blocking feature request — internally the line was “no HubOS integration = no deal” for the 270-property chain. And at the December 2025 team retro, the note that stuck: “Amazed at how we were able to hit our goal!”
F&B Ordering hit GA in February 2026 with two verbal commitments from demos alone and 50 pilot orders validating demand before launch. The delivery-type model became the architectural pattern for all future ordering scenarios (spa, activities, table-side), and APAC enterprise interest is building, with $25K+ in potential ARR from interested properties.
The platform also started clearing enterprise deals: my HubOS service-requests design solved Eurostars' #1 deal-blocking feature request — internally the line was “no HubOS integration = no deal” for the 270-property chain. And at the December 2025 team retro, the note that stuck: “Amazed at how we were able to hit our goal!”
Reflection
- Prototype in code, early. Hotel staff testing realistic flows made research dramatically more effective, and the prototype became a genuine GTM asset.
- Find the one variable. The delivery-type insight collapsed dozens of edge cases into a single configurable model. Designing for two audiences (guests ordering, staff fulfilling) means designing the system, not the screens.
- I'd push harder on staff notifications in the MVP. Post-launch feedback from HOMA showed hotels needed immediate alerts, as their team had to keep checking for new orders.
- Prototype in code, early. Hotel staff testing realistic flows made research dramatically more effective, and the prototype became a genuine GTM asset.
- Find the one variable. The delivery-type insight collapsed dozens of edge cases into a single configurable model. Designing for two audiences (guests ordering, staff fulfilling) means designing the system, not the screens.
- I'd push harder on staff notifications in the MVP. Post-launch feedback from HOMA showed hotels needed immediate alerts, as their team had to keep checking for new orders.
Built with Nico Garnier (PM) and engineers Joanne Chevalier, Andrea Bradshaw and Luciano Guasco.