Fake open orders
3
Static count for the owner preview only.
Future adapter: orders filtered by active status.
Static operations preview
Owner console operations preview
Use this fake-data layer to show how a future owner operations and menu editor experience could feel after the customer preview, while keeping this public demo safely disconnected from real business systems.
Today at a glance
Fake operations signals
Mock busy mode
Off
Preview state only; no operations setting exists.
Future adapter: storefront_settings.is_busy.
Sample prep window
15-20 min
Illustrative timing label, not a kitchen promise.
Future adapter: prep settings plus status timestamps.
Menu photo readiness
8 slots
Counts prepared demo image slots, not owner uploads.
Future adapter: media library with approval workflow.
Static status stages
Fake customer-status pairing
- Reviewed
Represents a static owner-side glance at a fake cart review event.
Future adapter: initial order record and received event. - Mock kitchen received
Illustrates a future kitchen queue state without creating any ticket.
Future adapter: staff-visible queue with authorization checks. - Mock prep started
Shows how status progress could be explained to an owner later.
Future adapter: status event append with audit metadata. - Ready preview
Static terminal preview only; it does not promise food or pickup.
Future adapter: terminal order state and customer lookup.
Business settings preview
Read-only future settings shape
- QR menu URL
- Current site origin + /menuExplains the public QR concept without storing links or scans.Future adapter: storefront base URL and QR placement notes.
- Prep promise
- 15-20 min previewIllustrative label only; no kitchen timing or staff workflow exists.Future adapter: owner-managed prep windows and busy-mode rules.
- Brand readiness
- Logo, app icon, menu photosShows what a future rebrand could swap for a real client.Future adapter: approved brand asset registry.
- Static loyalty preview
- Browser-local onlyNo account, phone lookup, or customer record is created.Future adapter: privacy-reviewed customer identity model.
Demo order/status board
Fake order cards, no management actions
Mock kitchen received
HHP-DEMO-1042Combo Over Rice, white sauce, medium spice, warm pita, bottled drink
Pairs with the fake customer status concept. No real ticket exists.
Future adapter: order header, items, and status events.Preview fake order detailPreview prep ticketMock prep started
HHP-DEMO-1043Chicken Over Rice, extra white sauce cup
Static card showing how a staff queue could be discussed later.
Future adapter: staff-visible status transition control.Ready preview
HHP-DEMO-1044Falafel Over Rice, green herb sauce, bottled drink
Fake terminal state; it does not represent pickup or fulfillment.
Future adapter: terminal status plus customer lookup token.Menu editor preview
Menu readiness without editable fields
This static board shows how owner-facing menu management might be organized later. It does not contain controls, uploads, publishing, or storage.
Production boundary
What must exist before this becomes real
- A live owner console would need authenticated staff access, role checks, and audit trails.
- Menu changes would need validation, publishing rules, rollback behavior, and image approval.
- Order status changes would need database records, allowed transitions, and customer-safe lookup tokens.
- Customer signals, loyalty, receipts, and analytics would need privacy review and retention decisions before implementation.
Founder presentation guardrail
Describe this route as a static owner operations preview. Do not say the demo is connected to real orders, real menu records, payments, customer records, or staff admin access. Those would be later production features after discovery, privacy, security, and operations decisions are approved.