A family-shop ordering system and the limits of replacement

Mr. Donut is my family's shop. I built a custom ordering system for its workflow. This is historical family-business engineering work; it is separate from RetailOS and is not evidence of current RetailOS adoption or a paying customer relationship.

The original article's aggregate order and customer figures have been retired pending reconciliation of their source cohort and date range. No revenue or current trading result is claimed here.

01 · Start with the operator's workflow

The useful system handled the steps staff needed: take an order, select a delivery area, assign the work and update its status. The interface had to fit the shop's habits and devices.

02 · Keep the implementation understandable

The delivered application used Next.js, React and Supabase, with Arabic-first screens and a small data model for orders, delivery areas and staff actions. A straightforward path through the daily work mattered more than an elaborate feature list.

03 · A replacement needs a reason to be adopted

Building RetailOS later did not automatically move the shop onto it. The custom system and the later retail platform were different pieces of work. A migration must earn the operator's time through a clear improvement in the workflow.

04 · Publish what the case can support

This case demonstrates delivery of a usable family-business system and the practical limits of replacing it. It does not certify current activity, lifetime order totals, unique-customer counts, delivery percentages or paid-platform adoption.