Lion Hospitality — connecting orders, kitchen, stock and dispatch

Delivery at the verified dates

• POS Admin Web, Manager Web and Vendor KDS: live by 28 Apr 2026
• Waiter Android and go-live onboarding: completed by 28 Apr 2026
• Fulfilment Console: built and in dispatch testing by 28 Jul 2026
• WIMS inventory architecture: defined, not live, as at 28 Apr 2026
• Hungry Lion app, storefront and CRM engine: designed or specified, not live at the verified dates
• Credits and broader rewards: held; no shipped outcome claimed

Situation and evidence

The group was opening new order and fulfilment paths while continuing to run existing venue operations. Orders, kitchen work, stock, dispatch and customer identity could not be treated as separate interface projects because the same order moves through all five.

The first delivery brand began trading through one active delivery marketplace. At the same time, the existing POS and kitchen stack was already running in production, the Fulfilment Console was being tested, and the inventory and direct-ordering layers were still architecture or prototype work. The central product problem was mixed delivery: connecting the stack without writing future systems in the voice of shipped software.

Product judgment

Use the existing operating spine. POS and kitchen display already carried live service. I treated them as the operating spine and designed the newer fulfilment, stock and direct-ordering work around the order states they already needed. This reduced unnecessary reinvention, but it also meant every new surface had to respect operational constraints that pre-dated it.

Design one fulfilment role and queue. The Console model brings inbound channels into one queue handled by one Fulfilment Officer. The product decision and the role decision are the same: one person needs clear ownership of the order from arrival to handoff. At the verified date, one marketplace was the sole active aggregator. The other channel inputs in the model were intended, not live integrations.

Separate live components from designed behaviour. This case study does not describe the whole stack as live. POS and KDS were in production. The Console was built and testing. WIMS, the direct storefront, dispatch integration, CRM engine and venue-specific pricing remained designed, specified or held. That separation matters more than presenting a smooth launch story.

System view

Delivery status

Fulfilment Console — one queue for every intended order source

Delivery: Built / testing · verified 28 Jul 2026.

The active delivery operation began with one marketplace. The longer-term operating model also needed to account for direct storefront orders, WhatsApp, phone, social messages and walk-up orders without turning every source into a separate queue and handoff.

I designed the Fulfilment Console around one accountable role: the Fulfilment Officer. Each intended channel lands in one order queue; the operator keeps ownership through acceptance, kitchen progress and handoff. This was as much an operating-model decision as an interface decision.

The Console was browser-based so order handling was not tied to a licensed counter machine. By 28 Jul 2026 it had been branded for Hungry Lion and was in dispatch testing. That is the delivery boundary: real software under test, not a production adoption story.

Dispatch was designed to wait for the kitchen preparation checkpoint rather than begin when the order first arrived. The reason is operational: a rider sent too early waits, while one sent too late extends the customer’s delivery time. The courier integration documentation was incomplete at the verified date, so the case study presents this as designed behaviour only.

Delivery note: built and testing. No production-order, adoption, missed-order-reduction or dispatch-time claim is made; those figures are not yet in the governed evidence record.

POS, KDS and WIMS — keep the live backbone separate from the inventory architecture

Delivery: POS/KDS live · WIMS directional.

POS Admin Web, Manager Web and Vendor KDS were live by 28 Apr 2026. The Waiter Android app and go-live onboarding were also completed. WIMS was different: its v1 scope and architecture were defined, but it was not production software at the verified date.

The WIMS model starts with the physical movement of stock. A warehouse holds sealed bottles with source cost and markup information. Stock transfers to an outlet, where the working quantity can be tracked in the unit the bar actually consumes. Outlet receiving closes the transfer. This gives the system a place to distinguish warehouse stock, goods in transit and venue stock without claiming a full ERP or accounting system.

The state model makes the checkpoint visible. Public labels are explanatory rather than code enums: Order accepted → In preparation → Ready for handoff → Completed. The design does not allow the line to jump from preparation to completion without passing the checkpoint intended to trigger depletion.

Venue-specific price books were part of the design because the same item may be positioned differently at different venues. The public artifact uses representative values and does not call the feature live.

Delivery note: the live claim belongs to POS/KDS. WIMS, depletion and price books remain directional in this case study. No shrinkage, margin or stock-count improvement is claimed.

Result and boundary

This work established a live POS and kitchen foundation, a fulfilment console in testing, and a defined architecture for the inventory and direct-ordering layers that follow. The public evidence is delivery evidence, not an impact experiment. No claim is made yet about Console adoption, dispatch time, inventory variance, repeat ordering or customer retention.

A redacted walkthrough of the Storefront prototype is available on request.

Next case study

Crowdyvest