← Work
Hospitality / Operations

Lion Hospitality Platform

Lion Hospitality PartnersProduct and Technology Strategy2025 — 2026

Product and technology strategy for a custom hospitality operating stack spanning POS, kitchen display, CRM, WIMS, and multi-venue management across Lion Hospitality Partners.

Lion Hospitality Platform — project image

A restaurant does not get a failed state. If the POS goes down during service, there is no error boundary to catch it — there is a line of customers, a kitchen mid-ticket, and a server with no system to work from. Software designed for a desk job does not survive contact with a dinner rush.

The system design problem

Lion Hospitality runs several venues on a custom-built operating stack rather than stitched-together off-the-shelf tools. That choice creates a different design problem than a typical SaaS product: the same data — an order, a table, an inventory count — has to stay correct and current across systems that different roles touch in different ways and at different speeds.

A server, a line cook, a venue manager, and a finance lead are not looking at the same screen or asking the same question, but they are all looking at consequences of the same underlying state. The design work was as much about keeping that state coherent across roles as it was about any single interface.

What the stack covers

The operating stack spans point of sale, kitchen display, CRM, a warehouse and inventory management system (WIMS), and multi-venue coordination — five systems that have to behave as one continuous workflow rather than five separate products that happen to share a login.

One design decision

A concrete example: void flows. When an order item gets voided mid-service — wrong item rung in, customer changed their mind, kitchen made a mistake — that single action has to propagate correctly to the kitchen display (stop making it), the POS (adjust the check), inventory (return or write off the ingredient), and reporting (record it as a void, not a comp or a discount, since those have different financial and tax treatment).

The original flow treated a void as a POS-only edit. I redesigned it as a cross-system event with one clear trigger point and role-appropriate confirmation, so a server could void an item in seconds without the kitchen, inventory, and reporting falling out of sync with each other.

What I can share

This is a live operational system for an active hospitality business, and the work is still ongoing. The detail above is representative of the kind of cross-system design problem the engagement involves, not a complete account of the platform. I am not able to share screens, financials, or internal documentation publicly.

  • Operations
  • Complex systems
  • Multi-role UX
  • Hospitality tech
  • Product strategy

Want the deeper walkthrough — research, tradeoffs, and what shipped?