DEV Community

Cover image for Engineering the WingZone POS: State Management for Group Ordering & Dual Receipts in Kotlin
Ahmad Akmal Abdullah
Ahmad Akmal Abdullah

Posted on

Engineering the WingZone POS: State Management for Group Ordering & Dual Receipts in Kotlin

#kotlin #firebase #android #architecture

One of the most notoriously difficult problems in food and beverage (F&B) software is handling large group orders. When a table of eight wants to order together but pay separately, standard POS systems either force the cashier to input eight separate orders or manually calculate the splits on a calculator.

I built the WingZone App—a native Kotlin-based POS application—to solve this exact workflow bottleneck. It is engineered specifically to handle complex state management for group orders, isolated payments, and hardware receipt generation.

Here is a breakdown of the architecture that secured 1st Place across all courses at the 2026 KPTM Ipoh FYP Exhibition.

The Tech Stack

Instead of building a web wrapper, this project required native execution to ensure zero latency at the checkout counter and direct hardware communication with receipt printers.

  • Core: Kotlin (Native Desktop .exe)
  • Architecture Pattern: MVVM (Model-View-ViewModel)
  • Local State Management: Kotlin Coroutines & StateFlow

Architectural Highlights

1. The Group Ordering Data Structure

The core challenge was structuring the data so a single "Master Order" could hold multiple "Sub-Orders" (individuals), without losing track of the total table state.

I designed a nested data model where a GroupSession acts as the parent object. When a group approaches the counter, the cashier opens a GroupSession. As each person orders, their items are appended to a unique SubOrder array inside that session.

This allows the UI to display the grand total for the kitchen, while keeping the financial data strictly compartmentalized for when it is time to pay.

2. Isolated Payment & Bill Splitting Logic

Because of the GroupSession structure, checkout becomes mathematically frictionless. The UI provides two checkout paths: Pay Full or Split by Individual.

When "Split by Individual" is triggered, the app iteratively locks each SubOrder as the payments are processed. This state is managed using Kotlin StateFlow. If a customer pays their specific portion, their sub-order state flips to PAID, but the parent GroupSession remains PENDING until every individual array is cleared. This guarantees that no items slip through the cracks during a chaotic group checkout.

3. Dual-Receipt Generation Pipeline

Printing receipts for group orders requires different data for different stakeholders. The kitchen needs to see everything at once, while the customer only needs to see what they paid for.

To solve this, I engineered a Dual-Receipt Generation Pipeline:

  1. The Kitchen Ticket: When the order is confirmed, the app flattens the GroupSession array into a single, consolidated list, grouping duplicate items (e.g., combining 4 separate "Fries" into a single "4x Fries" line item) to reduce reading time for the chefs.
  2. The Individual Tickets: Upon payment, the app queries the specific SubOrder, formats the string payload, and sends it to the thermal printer, generating a personalized receipt containing only that customer's items and their specific tax calculations.

The Result

The WingZone App replaced inefficient, manual checkout calculations with a structured, native Kotlin POS system designed around human F&B behavior. By solving the group-ordering and dual-receipt bottlenecks, the system drastically reduced queue times.

The architecture and practical utility of the app earned 1st Place overall at the KPTM Ipoh 2026 FYP Exhibition, outperforming projects from every other course.

I’m Ahmad Akmal (RuumiDev), Founder of MiraiWorks and an Independent Builder specializing in robust systems and interactive UI. If you prefer structured, practical engineering, let's connect:

Top comments (0)