Master Feature List
This is the single source of truth for every feature in the system,
grouped by module. Each feature carries a phase tag so scope stays visible
at a glance:
No coding starts until this list is reviewed and the MVP column is locked.
UI column (added once the UI-first pass began — see CLAUDE.md "Current
Status"): whether the feature has a working UI on static dummy data.
This is completely separate from the Phase tag and from whether the
feature is actually backed by a database — as of this pass, nothing in
this document is backed by Supabase yet, no matter what the UI column says.
| Mark | Meaning |
|---|
| ✅ | UI built and manually verified, on static/dummy data |
| 🟡 | Partially built — see the note in that row |
| — | Not started |
1. Platform Admin (Super Admin)
Manages the SaaS business itself, not any single restaurant.
| Feature | Details | Phase | UI |
|---|
| Restaurant (tenant) management | Create/suspend/reactivate/delete restaurant accounts; view tenant status | MVP | ✅ /platform-admin/tenants — search/filter, suspend/reactivate/delete with confirm, detail drawer |
| Subscription & plan management | Assign plan tier to a restaurant (e.g. Free/Starter/Pro); track plan limits (branches, tables, staff seats) | P4 | ✅ /platform-admin/subscriptions — plan cards with limits + tenant count per plan; plan-change action on the tenant detail drawer sets the tenant's plan directly |
| Platform-wide analytics | Total restaurants, total orders across platform, revenue-if-applicable, growth trend | P4 | ✅ /platform-admin overview — stat cards, signups-by-month chart, plan breakdown, recent tenants/activity |
| Platform user management | Manage super-admin accounts and their access | MVP | ✅ /platform-admin/users — list + invite sheet (name/email/role) |
| System settings | Global config: default currency list, supported payment providers, feature flags | P2 | ✅ /platform-admin/settings — currency picker, payment-provider toggles, admin activity/audit log |
| Feature flags | Per-tenant or global toggles to enable/disable features (e.g. enable AI for a tenant) | P4 | ✅ /platform-admin/feature-flags — global on/off only; no per-tenant scoping yet |
| Support/impersonation tooling | Ability to view a tenant's dashboard read-only for support purposes, with audit logging of the impersonation itself | P4 | 🟡 "View as restaurant" button links to /dashboard and the audit log UI exists (Settings page), but there's no real read-only impersonation session — it's just a link, no actual scoped/logged session since there's no auth |
UI pass complete on static dummy data (src/lib/dummy-data/platform.ts),
same static-data-first approach as every other surface — no auth, no
tenant isolation, no real billing. Everything here is illustrative until
the backend phase.
2. Restaurant Onboarding & Account Setup
| Feature | Details | Phase | UI |
|---|
| Owner registration | Email/password or magic link sign-up via Supabase Auth | MVP | 🟡 /signup screen exists and walks the whole journey, but nothing is verified and no account is created — see the note below |
| Restaurant creation wizard | Name, slug, logo, currency, timezone — creates the restaurants row | MVP | 🟡 /signup steps 2–4 (name, cuisine, subdomain with availability/reserved checks, address, plan) — collected and thrown away; no restaurants row exists to write |
| Branch creation | Add one or more branches under a restaurant, each with address/phone/timezone/currency | MVP | ✅ "Add a branch" on /dashboard/branches. Owner additions layer over the seeded locations and reach the topbar switcher, the POS and receipt headers. No per-branch timezone or currency yet — the restaurant's applies |
| Custom domain (later) | Point www.brand.com at the tenant once DNS/CDN routing supports it | P4 | 🟡 Owner setup built on Settings — domain entry, exact CNAME record, real DNS check. Routing the domain to the menu waits on the backend |
| Theme configuration | Primary/secondary color, font, button style, card radius stored in theme_config JSONB | MVP | ✅ Built as a foundational cross-app system (accent hue + light/dark + glass mode), not scoped to onboarding — see 05-UI-UX-DESIGN-SYSTEM.md |
| Staff invitation | Invite users by email to a restaurant with a specific role (restaurant_members) | MVP | 🟡 Invite, list and revoke work and persist. No email is sent — there is no mail service — and the modal says so rather than implying one went out |
| Onboarding checklist/progress UI | Guided steps, so a new owner isn't dropped into a blank dashboard | MVP | ✅ On the dashboard overview. Steps are branding → dish photos → floor plan → QR codes → first order, not the Restaurant/Branch/Menu of this row's original wording: every tenant is seeded with a restaurant, branches, tables and a menu, so those would read 5/5 on a brand-new account. What is left is the work the seed cannot do, all of it derived from stores the owner actually writes |
| Staff directory (new) | Admin-facing list of all staff with role, phone, shift status, live performance snapshot | MVP | ✅ /dashboard/staff |
| Staff profile page (new) | Dynamic per-staff page (/dashboard/staff/[id]): contact info, weekly shift schedule with days off, live orders-handled/revenue/items-prepared, recent activity feed | MVP | ✅ |
No auth exists, so nothing in this section beyond the two new staff-UI
rows has started — the "staff directory" is a flat static list, not
actually gated by login or role. The sign-in and sign-up screens
(/login, /signup, /forgot-password, /staff-login) are journey
design only: no credential is checked, no account is created, and the
SessionGuard behind the staff screens is a client-side redirect over a
localStorage value, not a gate. Note: /platform-admin/tenants now has
an "Add restaurant" flow (owner info, plan, initial table count →
generates one QR token per table) — that's a super-admin-side onboarding
action, not the owner self-registration wizard described above; the two
are related but distinct and both still need to exist eventually.
3. Menu Management (Admin CMS)
| Feature | Details | Phase | UI |
|---|
| Category CRUD | Create/edit/delete/reorder/enable-disable categories, with image and display order | MVP | 🟡 Add/rename/delete/reorder (up/down) via "ক্যাটাগরি ব্যবস্থাপনা" dialog on /dashboard/menu; no per-category image yet |
| Menu item CRUD | Create/edit/delete/reorder/enable-disable items: name, description, base price, image, veg flag, calories, prep time | MVP | ✅ Add/edit/delete/toggle-availability all work on the in-memory item list |
| Menu item variants | Attach multiple priced variants to one item (e.g. Small/Medium/Large) | MVP | ✅ Add/edit/remove variants directly in the item edit form, filtered clean on save |
| Modifier groups & options | Define add-on groups (e.g. "Extras") with individually priced options, attach groups to items | MVP | ✅ Add/edit/remove modifier groups + their options directly in the item edit form |
| Ingredient tagging | Associate ingredients with each menu item (feeds allergen matching + future inventory deduction) | MVP | ✅ Chip-input add/remove in the item edit form |
| Allergen tagging | Associate allergens with each menu item, with severity level and icon | MVP | ✅ Toggle chips in the item edit form, plus a create-new-allergen input (session-local, same no-backend caveat as categories/ingredients); no severity level yet, just presence |
| Dish names in two languages | Owner writes the dish name in English and Bengali; each guest reads theirs | MVP | ✅ Both fields in the item form, persisted per tenant; the guest menu resolves names by locale with a fallback to the owner's English, so a half-translated menu still reads. Dish names are the owner's words, so they cannot live in the dictionaries (rule 3) |
| Availability toggle | Mark an item "sold out" / unavailable without deleting it (e.g. ran out of a dish today) | MVP | ✅ Two of them, on purpose: the owner pauses a dish in the menu builder ("we stopped serving this"), and the kitchen 86s it from the KDS ("we are out tonight", cleared next shift). The guest menu and the package rules both key off the same available flag |
| Bulk image upload | Upload menu photography to Supabase Storage, tenant-scoped path | MVP | ✅ Frontend: "Choose photos" on /dashboard/menu takes a whole folder at once and guesses each dish from the filename, every guess correctable before saving. Still localStorage data URLs, not a bucket — that half waits on the backend |
| Menu preview | Admin can preview exactly what the customer-facing menu looks like before publishing | MVP | ✅ Read-only detail dialog reusing the customer's own DishImageCarousel + lightbox |
| Menu versioning/drafts (later) | Stage menu changes and publish atomically rather than editing live | P2 | — Not built. Menu edits apply immediately |
| Multi-branch menu override | A branch can hide/reprice specific items relative to the restaurant's master menu | P4 | — Not built. One menu per restaurant |
4. Dynamic QR System
| Feature | Details | Phase | UI |
|---|
| Table creation | Table number, name, capacity per branch | MVP | ✅ "Add Table" on /dashboard/tables |
| QR token generation | Persistent, unguessable per-table token; hash stored, raw token embedded in the QR | MVP | ✅ Random token generated per table; not hashed anywhere since there's no DB yet |
| QR download/print | Export a printable QR (PNG/SVG/PDF) per table, optionally branded with restaurant logo | MVP | ✅ PNG download, plus an A5 table tent card — restaurant name, tagline, table label, the live QR and what to do with it in both languages (a card on a table cannot know who sits down next). src/lib/print-table-tent.ts |
| QR resolution endpoint | Public route handler: token → table → branch → restaurant → session | MVP | 🟡 /table?token=... is genuinely resolved against the static TABLES list (see app/[locale]/table/page.tsx) — real, not cosmetic — but it's a client-array lookup, not a DB-backed endpoint with session creation |
| QR regeneration | Invalidate and reissue a table's token (e.g. token compromised, table repurposed) without affecting other tables | MVP | ✅ "Generate new token" in the table QR dialog, with a confirm step |
| Table session lifecycle | Create session on scan, track last_activity_at, expire stale sessions, support multiple customers per session | MVP | ✅ A sitting starts on scan, is resumed while live, and expires after 3h idle or the moment a waiter marks the table clean. The cart's storage key includes the sitting, so a new party reads an empty cart rather than having a stale one cleared out from under them. Multiple devices per sitting already worked — the cart is shared, the guest name is per device |
| Table status | vacant / occupied / reserved / billing / maintenance, updated automatically as orders progress | MVP | ✅ Displayed and color-coded on /dashboard/tables, but status is static seed data, not derived live from orders |
| Table map / floor plan (visual) | Drag-and-drop table layout with live color-coded status | P2 | 🟡 Grid/floor-plan toggle on /dashboard/tables — static illustrative positions (floorX/floorY per table), color-coded by status, opens the same QR detail sheet; not drag-editable yet |
5. Customer Storefront
5.1 Discovery & Browsing
| Feature | Details | Phase | UI |
|---|
| Restaurant header | Logo, name, branch, live open/closed status | MVP | ✅ |
| Hero/featured banner | Promotional banner slot, restaurant-configurable | MVP | ✅ Dismissible promo banner above the search bar (PROMO_BANNER in dummy data) |
| Search | Search menu items by name across categories | MVP | ✅ |
| Category navigation | Pills (desktop) / horizontal scroll (mobile); sticky on scroll | MVP | ✅ |
| Featured items carousel | Embla-based slider for highlighted dishes | MVP | ✅ |
| Menu grid/list | Progressive-loaded food cards, grouped by category | MVP | ✅ |
| Food card | Image, badge, favorite toggle, name, short description, price, rating, allergy indicator, add button | MVP | ✅ |
| Food detail view | Full image gallery, description, ingredients, allergens, variants, add-ons, special instructions, quantity, add-to-cart — presented as a mobile bottom sheet/modal | MVP | ✅ Includes a full-screen image lightbox with its own swipe/slide navigation |
| Skeleton loading states | Never a blank screen while menu data streams in | MVP | ✅ Shimmer on dish images (real load-based, not timer-based) + full-page menu skeleton during the simulated QR-resolve phase |
| Favorites (new) | Heart-toggle per dish, persisted in local component state for the session | — | ✅ |
| "You might also like" (new) | Same-category upsell row on the food detail sheet, one-tap add | — | ✅ |
5.2 Allergy & Ingredient Safety
| Feature | Details | Phase | UI |
|---|
| Personal allergy selection | Customer selects from a predefined allergen list (Peanut, Lactose, Gluten, Egg, etc.) | MVP | ✅ |
| Per-item safety status | SAFE / WARNING / UNSAFE badge computed against declared allergies + item ingredients/allergens | MVP | ✅ Logic covered by unit tests (src/lib/allergy-filter.test.ts) |
| Safety disclaimer | Explicit "informational only, not a medical guarantee" messaging in the UI | MVP | ✅ |
| Ingredient list display | Full ingredient breakdown visible in the item detail view | MVP | ✅ |
5.3 Cart & Checkout
| Feature | Details | Phase | UI |
|---|
| Add to cart (with variant/modifiers/qty/notes) | Scoped to the active table session | MVP | ✅ |
| Cart drawer/bottom sheet | Right drawer (desktop) / bottom sheet (mobile); item list, quantity edit, remove | MVP | ✅ Bottom sheet on every breakpoint (see design note in cart-drawer.tsx); item list is height-capped and scrolls independently of the totals/checkout footer once it grows past ~3 items |
| Live price breakdown | Subtotal, tax, discount, service charge, total — computed, then re-verified server-side on submit | MVP | 🟡 Computed and displayed correctly by calculateOrderTotals() (src/lib/order-totals.ts, unit-tested); the "re-verified server-side" half doesn't exist yet (no server), but the rule is now a pure function the server can call rather than arithmetic buried in JSX |
| Special instructions per item | Free-text note per line item | MVP | ✅ |
| Allergy warning acknowledgment | If a cart item is WARNING/UNSAFE for the customer's declared allergies, require explicit acknowledgment before ordering | MVP | ✅ |
| Place order | Atomic server-side order creation (order + order_items + kitchen_order + table status update) | MVP | 🟡 UI/flow complete; "atomic server-side" doesn't apply yet — it's a synchronous write into the shared client-side store (lib/store/live-store.ts) |
| Order confirmation screen | Order number, table, estimated prep time | MVP | ✅ |
| Live order status tracking | Received → Preparing → Ready → Served, pushed via realtime | MVP | ✅ Genuinely live, including across separate browser tabs/devices, via the demo live-store (localStorage + BroadcastChannel) — see CLAUDE.md. Not Supabase Realtime yet, but not a fake timer either; status only changes when a KDS/Waiter action actually changes it |
| Abandoned cart recovery (later) | Detect an inactive session with items in cart and prompt/notify | P2 | 🟡 In-session only: a guest who leaves items in the cart is nudged on the menu to finish. Nothing reaches them after they leave — that needs messaging and a backend |
| Guest checkout (no account) | Default flow — name/phone only, no account required | MVP | ✅ (there's no account system at all yet, so this is the only flow that exists) |
| Optional customer account | Login for order history, favorites, loyalty | P3 | — Not built. Guests order without an account |
| Bill/payment request from table | Customer or waiter triggers a "request bill" event | P2 | ✅ "বিল চাই" in My Orders → payment method picker → shows live in the Waiter App's requests inbox |
| WhatsApp order channel | Alternate ordering entry point via WhatsApp link, feeding the same order core through a channel adapter | P4 | — Not built |
| Multi-round ordering / "My Orders" (new) | A table session can place several order rounds; each round tracks its own status, all rounds roll up into one running bill | MVP | ✅ |
| Reorder past items (new) | One tap re-adds every item from a previous round to the current cart | — | ✅ |
| Tip selection (new) | Preset tip percentages at checkout | — | ✅ None / 5 / 10 / 15% or a typed amount, itemised on the bill and carried onto the order and the receipt. Calculated on the food, never on tax or the service fee, and never reduced by a discount — src/lib/order-totals.ts |
| Promo/discount code (customer-entered) (new) | Customer enters a code at checkout for an instant discount — distinct from the staff-applied discount in §6 | — | ✅ (Try WELCOME10 or SAAD15 in the dummy data) |
| Delivery & Takeaway Checkout (new) | Place online orders for Home Delivery (BD address + Zone fee) or Takeaway without table QR | MVP | ✅ |
| Promo Campaign Scan-to-Claim (new) | Scanning a promo QR directly opens item sheet with locked special discount and instant add-to-cart | MVP | ✅ |
| Multi-Branch Switching (new) | Switch between tenant branches from dashboard topbar with branch-scoped data | MVP | ✅ |
| Dedicated Rider Delivery Portal (new) | Mobile dispatch app (/rider) with order queue, phone dialer, map routing, and delivery completion | MVP | ✅ |
| Delivery Distance & Transit Calculation (new) | Distance (KM) estimation with automated dynamic delivery fee calculation | MVP | ✅ |
| Loyalty Rewards & Cashback Wallet (new) | Earn loyalty coins on orders and redeem points for instant discount in cart drawer | MVP | ✅ |
| SMS & WhatsApp Notification Dispatch (new) | Simulated live dispatch notifications and message template customizer | MVP | ✅ |
| Post-Meal 5-Star Reviews & Feedback (new) | Interactive review modal on bill payment / delivery completion with rating sentiment analytics | MVP | ✅ The prompt appears once an order is served or paid, survives a reload, and the review reaches the owner's CRM board with its sentiment. (It used to show a thank-you and discard the rating — the board listed only seeded reviews.) |
| Dine-In Split Bill (new) | Split table bills equally (N guests) or itemized individual dishes in My Orders sheet | MVP | ✅ |
| Table Booking & Reservations (new) | Storefront reservation widget and admin calendar timeline manager | MVP | ✅ |
| AI Smart Upselling & Combos (new) | Companion dish pairings (e.g. Biryani + Borhani) in food detail sheet and cart | MVP | ✅ |
| Food Costing (COGS) & Profit Analytics (new) | Ingredient cost tracking, gross profit margin breakdown, and food cost ratio analytics | MVP | ✅ |
6. Order Management & Order Engine
| Feature | Details | Phase | UI |
|---|
| Server-side price authority | Server independently recalculates price, tax, discount, total — client totals are never trusted | MVP | — Not satisfied — there is no server. See CLAUDE.md rule #1 and the "Current Status" section. The calculation itself is extracted and tested (src/lib/order-totals.ts), so satisfying this becomes wiring rather than reimplementation |
| Order state machine | PENDING → CONFIRMED → KITCHEN_PREP → READY → SERVED → COMPLETED, with CANCELLED branches per business rules | MVP | ✅ UI reflects a 6-state machine (pending/confirmed/preparing/ready/served/completed); nothing server-validates the transitions yet |
| Order types | dine_in, takeaway, delivery | MVP | ✅ Dine-in, Takeaway, and Home Delivery supported in live store & UI |
| Delivery lifecycle tracking | Order Placed → Confirmed → Kitchen Prep → Ready for Dispatch → Out for Delivery → Delivered | MVP | ✅ |
| Order transactionality | All-or-nothing creation (order + items + kitchen order + table update) with rollback on failure | MVP | — N/A without a database |
| Order event log | order_events records every transition for traceability | MVP | 🟡 Each order carries its own timeline (Order.timeline), shown to the guest, the kitchen and the owner. No append-only log across orders — that belongs in the database |
| Discounts | Manual discount application by staff, with audit logging | P2 | 🟡 A percentage discount before tax at the POS. Guest orders get promo codes only (§5.3) |
| Service charge | Configurable per restaurant, applied automatically or manually | MVP | ✅ Rate set in Admin Settings, applied automatically at customer checkout |
| Cancellation flow | Role-gated cancellation with reason capture, at defined allowed statuses | P2 (rules pending confirmation — see SRS open item #3) | 🟡 The owner can cancel an order while it is pending, confirmed or preparing, and the guest's tracker shows it. No guest-initiated cancel — the rules are still open (SRS #3) |
| Refund flow | Tied to the payments record, role-gated | P2 (pending confirmation) | 🟡 Refunds exist at the POS (§9). Guest orders cannot be refunded yet — rules still open |
7. Kitchen Display System (KDS)
| Feature | Details | Phase | UI |
|---|
| Column view | New / Preparing / Ready / Completed | P2 | ✅ |
| Station-based routing | Orders route to Grill/Fryer/Pizza/Drinks/Dessert stations | P2 | ✅ (stations: grill/fryer/main/dessert/drinks — "Pizza" renamed "Main" to fit this menu) |
| Realtime new-order alert | Visual highlight + configurable sound on new ticket | P2 | ✅ New tickets appear live (cross-tab) + a real Web Audio two-beep alert, toggleable |
| Order timer | Elapsed time per ticket, visually flagged if over target prep time | P2 | ✅ Overdue flag at 15+ minutes |
| Priority flagging | Mark a ticket urgent/rush | P2 | ✅ Shown as a distinct accent bar + badge; set in dummy data, no "mark as priority" action yet |
| Status transition controls | Kitchen staff moves a ticket New → Preparing → Ready (server-validated, not arbitrary) | P2 | ✅ UI-validated (one step at a time); not server-validated |
| Kiosk-friendly large-screen layout | Designed for a wall-mounted display, not a phone | P2 | ✅ |
8. Waiter App
| Feature | Details | Phase | UI |
|---|
| Shift management | Clock in/out, waiter_shifts tracks active shift per branch | P2 | 🟡 On/off toggle in the UI; no shift history record |
| Assigned tables view | Tables auto-assigned to the waiter on active shift | P2 | ✅ |
| Active orders per table | Live status of every order at each assigned table | P2 | ✅ |
| Table requests | Bill request, call-kitchen, and similar customer-triggered flags surfaced to the waiter | P2 | ✅ Real-time from the customer's own Call Waiter / Request Bill actions |
| Order status updates | Mark items served | P2 | ✅ Per-item checklist once an order is "ready" (auto-advances to "served" when every item is checked) |
| Push notifications | New order / ready-for-pickup / customer request alerts | P2 | ✅ Real browser Notification API, gated behind a permission-request bell button; fires when a new table request arrives while the tab is hidden |
| Waiter performance data feed | Orders handled, revenue, service time — feeds Analytics module | P2 | ✅ Feeds both the Staff profile page and Admin Analytics |
9. Cashier / POS
| Feature | Details | Phase | UI |
|---|
| Order lookup & billing | View open orders for a table/session, generate final bill | P2 | ✅ Dedicated /dashboard/pos — search by table/order number, itemized bill with tax + service charge, "Generate final bill" |
| Payment processing | Cash, card, mobile banking (bKash/Nagad), online — via the pluggable payments abstraction | P2 | 🟡 Payment method selection on the POS bill is real UI state (persisted to the order via markOrderPaid); no actual gateway processing since there's no backend |
| Split/multiple payment methods per order (later) | Partial cash + partial card, etc. | P3 | ✅ The POS splits one ticket across cash, card, bKash and Nagad. Labels only — no money moves |
| Receipt generation | Printable/digital receipt | P2 | ✅ Print (browser print) + plain-text download, shown once a bill is generated on /dashboard/pos |
| Discount & service charge application | Staff-applied, audit-logged | P2 | ✅ POS: percentage discount before tax, service charge on every ticket |
| Refund handling | Tied to original payment record | P2 (pending business rules) | ✅ POS: mark a charged ticket refunded, with a stated reason. Labels only — no money moves |
| Payment webhook handling | Signature-verified callbacks from digital payment providers | P2 | — |
A dedicated Cashier/POS surface now exists at /dashboard/pos — it lists
served/completed orders that aren't yet paid, shows a tax/service
breakdown, and marks the order paid (isPaid/paymentMethod on
AdminOrder) once a bill is generated. Real payment processing, receipts,
discounts, and refunds still need the backend phase.
10. Table Management
| Feature | Details | Phase | UI |
|---|
| Table map (visual floor plan) | Color-coded by status: vacant/occupied/reserved/billing | P2 | ✅ Grid/floor-plan toggle on /dashboard/tables, color-coded tiles |
| Drag-and-drop layout editor | Position tables visually to match the physical floor plan | P2 | ✅ /dashboard/tables → arrange mode: owner-defined zones, drag within and across zones, snap-to-grid, arrow-key nudging. The waiter board follows the owner's layout |
| Table merge | Combine two tables' orders for one bill (large party) | P3 | ✅ /dashboard/tables, behind FEATURE.tableMerge: merged tables pool their orders for one bill, and can be un-merged |
| Split bill | Divide one table's order into multiple bills | P3 | ✅ Split-bill sheet in the guest's cart, behind FEATURE.splitBill |
| Table session history | View past sessions for a table | P2 | 🟡 Each table on /dashboard/tables has a session-history view, built from seed data rather than recorded sittings. Guest sittings are tracked (useTableSession) but not yet written into it |
11. Analytics & Reporting
| Feature | Details | Phase | UI |
|---|
| Dashboard summary cards | Today's Sales, Orders, AOV, Active Tables | MVP (basic) | ✅ |
| Hourly sales chart | Sales volume by hour of day | P2 | ✅ |
| Orders by category | Category-level sales breakdown | P2 | ✅ |
| Top products | Best-selling items by volume/revenue | P2 | ✅ |
| Waiter performance | Orders handled, revenue, avg order value, avg service time per waiter | P2 | ✅ (avg service time not included) |
| Table revenue | Revenue attributed per table | P2 | ✅ Derived live from orders (getTableRevenue), sorted highest-first, on /dashboard/analytics |
| Peak hour detection | Identify busiest time windows | P2 | ✅ Top 3 hours by sales volume (getPeakHours) on /dashboard/analytics |
| Channel performance | Dine-in vs takeaway vs delivery vs WhatsApp comparison | P4 | ✅ /dashboard/analytics → By channel: orders, revenue, share of revenue and average ticket for dine-in, takeaway and delivery, computed from every order on record (seeded and live), cancelled ones excluded. Replaced two switchers that changed no figure |
| Materialized/aggregated analytics tables | Pre-computed rollups for performance at scale (not required while computing directly from orders is fast enough) | P3+ | — N/A without a database |
| Kitchen staff performance (new) | Orders handled + items prepared per kitchen staffer | — | ✅ |
12. Inventory Management
| Feature | Details | Phase | UI |
|---|
| Ingredient stock tracking | Current stock, minimum stock, cost per unit, unit of measure | P3 | ✅ /dashboard/inventory: on-hand quantity, reorder threshold and unit cost per item |
| Recipe / BOM definition | Attach ingredient quantities to a menu item (e.g. Chicken Burger → 150g chicken, 1 bun, 1 cheese slice, 20g sauce) | P3 | — Not built. Dishes are not linked to the stock they use |
| Automatic stock deduction | On order completion, deduct recipe ingredients from stock | P3 | — Not built. Needs recipes first; orders do not touch stock |
| Stock movement ledger | Every stock change recorded as purchase/sale/adjustment/waste/return/transfer — never a blind quantity overwrite | P3 | ✅ Inventory → Movements: purchase, sale, adjustment, waste, return and transfer |
| Low-stock alerts | Notify when an ingredient drops below minimum_stock | P3 | ✅ Banner on the inventory board, with one-click reorder into a purchase order |
| Supplier management | Supplier records, contact info | P3 | ✅ Inventory → Suppliers |
| Purchase orders | Create/track purchase orders and their line items against suppliers | P3 | ✅ Inventory → Purchase orders, drafted and tracked through receiving |
| Waste tracking | Record spoilage/waste as a stock movement type | P3 | 🟡 Waste is a movement type in the ledger. No dedicated waste log or report |
13. CRM (Customer Relationship Management)
| Feature | Details | Phase | UI |
|---|
| Customer profile | Name, phone, order history, total spent, favorite items, visit count | P3 | ✅ /dashboard/crm: contact, orders, spend, favourite dish, last visit, segment, loyalty points |
| Order history per customer | Full past-order list tied to phone/account | P3 | 🟡 Totals per customer (orders, spend, favourite, last visit) — not the list of their orders |
| Customer segmentation | Group customers by behavior (frequency, spend) | P4 | ✅ CRM segments with a filter and per-segment counts |
| Loyalty program | Points/rewards tied to order history | P4 | ✅ Loyalty wallet behind FEATURE.loyalty, with points redeemable as a discount at checkout |
| Coupons & offers | Discount codes, targeted promotions | P4 | ✅ Promo codes at checkout, and promo campaigns with their own QR landing pages (/dashboard/promos) |
| Marketing messaging (later) | Campaign sends to segments, likely via WhatsApp/SMS/email channel adapters | P4 | — Not built |
14. Multi-Branch Management
| Feature | Details | Phase | UI |
|---|
| Central dashboard | Cross-branch view for restaurant owner | P4 | ✅ /dashboard/branches compares every location on one screen — orders, revenue, tables, staff |
| Branch switching | Admin UI to switch context between branches | P4 | ✅ Topbar switcher, behind FEATURE.multiBranch. The POS stamps orders with the active branch |
| Branch-level analytics | Same analytics module, scoped per branch | P4 | 🟡 Orders and revenue today per branch on the branches board. Analytics and insights are not split by branch |
| Central vs branch-specific menu | Master menu with per-branch overrides | P4 | — Not built |
| Branch-level inventory | Independent stock per branch | P4 | — Not built. One stock list per restaurant |
| Branch-level staff & permissions | Staff scoped to one or more branches | P4 | — Not built |
15. WhatsApp Ordering Integration
| Feature | Details | Phase | UI |
|---|
| WhatsApp order link | Customer starts an order via a WhatsApp deep link | P4 | — Not built |
| Order confirmation via WhatsApp | Automated confirmation message | P4 | 🟡 Platform admin → Notifications has WhatsApp, SMS and email templates and a dispatch log. Nothing is sent — no provider is connected |
| Status update messages | Preparing/Ready/Served notifications pushed to WhatsApp | P4 | 🟡 Same templates and dispatch log as above; nothing is sent |
| Channel adapter architecture | WhatsApp logic isolated behind a channel adapter so the core order engine stays channel-agnostic (see 04-API-AND-ROUTING.md) | P4 | — Not built |
16. AI Layer
| Feature | Details | Phase | UI |
|---|
| Cross-sell recommendations | Suggest items based on customer behavior + order history | P4 | 🟡 A simpler, non-AI same-category "You might also like" row exists (§5.1) — no behavioral/ML recommendation yet |
| Demand/inventory forecasting | Predict ingredient needs from historical sales + seasonality + day-of-week | P4 | 🟡 /dashboard/insights projects the coming week's revenue from past days — a plain projection, not a model. No inventory forecast |
| Natural-language BI | Owner asks a question in plain language; system runs intent extraction → constrained/validated query → PostgreSQL → LLM-generated explanation. Raw unrestricted SQL generation by the LLM is explicitly disallowed | P4 | — Not built |
| Menu optimization suggestions | Data-driven suggestions on pricing/menu composition | P4 | 🟡 /dashboard/insights lists rule-based suggestions from the order data. No model behind them |
| Customer insight summaries | LLM-generated summaries of customer segments/trends | P4 | — Not built |
17. Notifications (cross-cutting)
| Feature | Details | Phase | UI |
|---|
| Realtime in-app notifications | KDS/Waiter/Cashier/Customer notified via scoped Supabase Realtime channels | MVP (order-status) / P2 (full set) | 🟡 Cross-surface live updates work (see live-store.ts), but via a demo localStorage/BroadcastChannel layer, not Supabase Realtime |
| Configurable KDS sound alerts | Kitchen staff can adjust/mute alert sound | P2 | ✅ Toggle button in the KDS header |
| Push notifications (PWA) | Waiter/KDS/Customer installable PWAs receive push where supported | P2 | — Not built. Kitchen, waiter and rider screens raise browser notifications while open; nothing reaches a closed app |
| Email notifications (later) | Order receipts, staff invitations | MVP (staff invite) | — Not built. Staff invites are recorded but no email is sent |
18. Settings & Configuration
| Feature | Details | Phase | UI |
|---|
| Restaurant profile settings | Name, logo, currency, timezone, contact info | MVP | ✅ |
| Theme/branding settings | Colors, font, button/card style | MVP | ✅ (as the cross-app theme system, not a settings-page-only feature) |
| Tax & service charge configuration | Restaurant-level defaults | MVP | ✅ |
| Role & permission management UI | Assign/change staff roles | MVP | ✅ Permission matrix editor (role × permission grid) on /dashboard/settings; owner row locked. Assigning a role to a specific staff member is still not editable — the matrix only controls what each role can do |
| Payment provider configuration | Enable/configure bKash, Nagad, card, cash | P2 | ✅ On/off toggles per method |
| Notification preferences | Per-role notification/sound settings | P2 | ✅ (new order / bill request toggles) |
19. Security & Compliance (as user/operator-facing features)
| Feature | Details | Phase | UI |
|---|
| Row Level Security enforcement | Database-level tenant isolation (not a toggle — foundational, see 06-SECURITY.md) | MVP | — No database yet |
| Role-based access control | Enforced in app logic + RLS | MVP | — No auth yet — every route is publicly reachable |
| Audit log viewer | Admin-facing view of audit_logs (price changes, cancellations, discounts, deletions, permission changes, inventory adjustments) | P2 | ✅ Restaurant-level activity log card on /dashboard/settings (ADMIN_AUDIT_LOG — distinct from Platform Admin's platform-wide one) |
| Rate limiting | On public endpoints — QR resolution, order placement | MVP | — |
| Error monitoring dashboard access | Sentry (or equivalent) integration visible to engineering, not end users | MVP | — |
Nothing in this section exists yet. The staff screens now redirect a
signed-out visitor to /login, but that is a browser-side redirect over a
localStorage value the visitor can write, applied after the page and its
seed data have already been sent — every screen remains reachable by anyone
with the URL and a devtools console. This is expected and acceptable for a
static-data UI pass, but it means none of this codebase is safe to point at
real tenant data until the backend phase lands.
20. Feature Prioritization Summary
MVP → Sections 2, 3 (core), 4, 5, 6, 11 (basic), 17 (order-status), 18 (core), 19
P2 → Sections 3 (drafts), 4 (floor plan), 5 (abandoned cart, bill request), 6 (cancel/refund), 7, 8, 9, 10 (map), 11 (full), 17 (full), 18 (payment/notif config), 19 (audit viewer)
P3 → Sections 5 (accounts), 9 (split payment), 10 (merge/split), 12, 13
P4 → Sections 1 (subscriptions/flags), 2 (custom domain, multi-branch menu), 5 (WhatsApp), 13 (loyalty/marketing), 14, 15, 16
This table is the scope contract. Any feature not listed here is out of
scope until explicitly added. Any MVP-tagged feature is required before
Phase 7 (Customer Storefront) is considered complete per
07-ROADMAP-PHASES.md.
21. UI Build Status Summary (this pass)
A quick answer to "is the UI done?" — surface by surface:
| Surface | UI pass | Biggest gaps vs. this document |
|---|
| Landing page | Done | — |
| Customer Storefront | Done | Server-side price re-verification (needs backend) |
| Restaurant Admin Dashboard | Done | Per-category image; real drag-and-drop floor-plan editing (positions are static); per-staff role assignment |
| KDS | Done | — |
| Waiter App | Done | — |
| Platform Admin | Done | Real impersonation/audit (needs auth); per-tenant feature-flag scoping |
Everything marked ✅ above is static-data-only, manually verified in the
browser each round (no automated component/e2e tests — see CLAUDE.md
"Tests" for what is covered). The next milestone per
07-ROADMAP-PHASES.md is the Supabase/backend phase,
starting at STEP 01 — not more UI, unless new gaps are found in the list
above first.
22. Future Implementation & Next-Gen Enterprise Modules (Phase 5+)
This section outlines upcoming roadmap additions designed to expand Restaurant OS SaaS into a full-scale omnichannel platform:
22.1 Kitchen Automation & Hardware Integration (KDS & IoT)
- Direct ESC/POS & WebUSB / Bluetooth Thermal Printing: Silent, zero-dialog 80mm/58mm Kitchen Order Ticket (KOT) & customer receipt printing directly from the web POS/KDS.
- Multi-Station Kitchen Routing: Automatic distribution of ticket items to distinct station screens (Bar, Grill, Fryer, Pastry, Expediter).
- Kitchen SLA & Cooking Timer Alarms: Visual alert countdowns and audible warning beeps for orders exceeding target prep duration (>15 mins).
- Hardware Bump Bar Integration: Physical keyboard/numpad hotkey mapping for kitchen staff operating in high-heat, gloved environments.
22.2 Raw Material Inventory, Recipe BOM & Waste Management
- Recipe Bill-of-Materials (BOM) Auto-Deduction: Automatic ingredient deduction (meat, oil, vegetables, packaging) from real-time stock upon order fulfillment.
- Low-Stock Auto-Alerts & Reorder Thresholds: Automatic WhatsApp & email alerts dispatched to store managers when raw ingredients hit minimum safety levels.
- Kitchen Waste & Spoilage Logging: Digital recording of burned, damaged, or expired stock with automated monetary loss reports.
- Supplier & Purchase Order (PO) Management: Supplier directory, quotation logs, and Goods Received Note (GRN) inventory reconciliations.
22.3 AI Restaurant Intelligence & Predictive Operations
- Voice-to-Order Smart POS Assistant: Real-time natural speech parsing converting verbal Bangladeshi dish orders into structured cart items.
- AI Sales & Demand Forecasting: Weather-aware, holiday-aware, and historical time-series forecasting for predictive prep volume and staff scheduling.
- Dynamic Happy-Hour & Peak-Hour Pricing: Automated time-based price adjustments and promotional triggers for off-peak dine-in hours.
- AI Feedback & Sentiment Triaging: Automated categorization of negative post-meal reviews with instant supervisor escalations.
- BCG Menu Matrix Engineering: Automated categorization of dishes into Stars, Plowhorses, Puzzles, and Dogs with pricing recommendations.
- Multi-Lingual AI Menu Audio Translation: Auto-translation into 10+ languages (Arabic, Japanese, Spanish) with audio pronunciation.
22.4 Real-Time Group Collaborative Cart & Dine-In Pay-at-Table
- Live Group Shared Cart: Real-time collaborative table ordering where multiple diners scan the same table QR and see a synchronized live cart with name attribution.
- QR Pay-at-Table Self-Checkout: Instant bill settlement via bKash/Nagad/Card directly from customer mobile without calling a waiter.
- Smart Tip Suggestion Algorithm: Behavioral tip percentages (10%, 15%, 20%) increasing server tips by 25-30%.
- Pre-Authorized Open Bar Tabs: Card/wallet pre-authorization for open lounge & beverage tabs settled automatically at exit.
22.5 Standalone Self-Ordering Kiosks & Pickup Token Screens
- Floor-Standing Touchscreen Kiosk PWA: Large-screen kiosk interface with step-by-step navigation, combo upsell prompts, and direct thermal KOT printing.
- Order Pickup Token Screen (TV Display): Split-screen TV monitor displaying "Preparing" and "Ready for Pickup" order tokens with voice callout chimes.
22.6 Custom Meal Builder & Nutrition Tracking
- Step-by-Step Custom Food Builder: Visual ingredient layer builder (e.g. Build-Your-Own Pizza/Burger/Bowl) with live pricing.
- Automatic Macro & Calorie Calculator: Recipe-based nutritional breakdown per dish with dietary filters (Keto, Diabetic-friendly, Gluten-Free).
- Augmented Reality (AR) 3D Food Previews: Interactive 3D dish previews directly in the smartphone browser before ordering.
22.7 Catering, Banquets & Milestone Events
- Custom Event Package Calculator: Per-head package builder (e.g. ৳1200/head x 50 guests) with hall rental, decoration, and sound system add-ons.
- Milestone Deposit Scheduling: Automated collection of advance deposits (30% booking, 50% event day, 20% post-event).
- Interactive Banquet Seating Chart Planner: Drag-and-drop table layout planner with VIP guest tagging.
22.8 Meal Subscriptions & Beverage Membership Passes
- Monthly Corporate Lunch Tiffin Delivery: Recurring meal calendar with skip/pause features for corporate offices.
- Unlimited Coffee / Beverage Pass: Monthly subscription pass allowing 1 daily specialty coffee.
22.9 In-Store Guest Entertainment & Gamification
- Crowdsourced Table Jukebox: Diners vote via QR code for the next track to play on the venue's Spotify/sound system.
- Wait-Time Table Trivia Mini-Game: Interactive digital quiz while waiting for food, awarding discounts to daily top scorers.
- Post-Bill "Spin the Wheel" Gamification: Digital wheel spin after payment offering instant cashback or dessert vouchers.
- VIP Secret Unlocked Menu: Hidden specialty dishes accessible only by Gold/Platinum loyalty members.
22.10 All-You-Can-Eat (AYCE) Buffet Countdown & Waste Control
- Table AYCE Countdown Timer: Live 90-minute digital timer on diner's mobile with 15-minute ordering auto-lock.
- Excess Food Wastage Fine Calculator: Automatic surcharge calculation for unconsumed leftover food (>150g).
22.11 Cloud Kitchen Virtual Multi-Brand & Central Commissary
- Virtual Cloud Kitchen Multi-Branding: Managing multiple digital restaurant brands from a single kitchen with centralized KDS.
- Central Commissary Inter-Branch Requisitions: Central kitchen batch production and stock transfers to satellite outlets.
- Franchise Royalty Fee Automation: Automated calculation and invoicing of franchisor royalty and marketing percentages.
22.12 On-Demand Third-Party Courier Dispatch & Curbside Pickup
- 1-Click Third-Party Courier Dispatch: Automated dispatch to Pathao, Steadfast, or RedX riders when in-house fleet is overloaded.
- Curbside Pickup Vehicle Geofencing: Proximity alert informing floor staff of customer arrival in car.
- Third-Party Aggregator Hub: Direct webhook bridge consolidating Foodpanda, Pathao, and UberEats orders into POS and KDS.
22.13 Staff HRM, Biometric Attendance & Tip Pools
- PIN / Selfie Clock-In & Shift Rostering: Tablet-based digital shift attendance, overtime tracking, and shift swap workflows.
- Automated Waiter Tip Pool Distribution: Fair tip distribution algorithm calculated based on active shift hours and assigned role weights.
- Gamified Staff Leaderboard: Real-time scoreboard recognizing top upselling servers and fastest table turnaround staff.
22.14 Loss Prevention, Anti-Theft & Security
- Cashier Void & Discount Abuse Detection: Automated security alerts triggered by unusual bill cancellations after printing or high discounts.
- Manager NFC / Fingerprint Override: Quick NFC card tap or fingerprint scan for instant supervisor authorization without typing passwords.
- Transaction CCTV Timestamp Tagging: Direct linking of POS transaction timestamps with security camera logs for dispute resolution.
22.15 IoT Cold Storage & Food Safety (HACCP)
- IoT Fridge & Freezer Temperature Logging: Automated hourly chiller temperature records with immediate alerts for rising temps.
22.16 NBR EFD & Government Tax Compliance
- National Board of Revenue (NBR) EFD / SDC Integration: Mushak 6.3 QR invoice printing and automated VAT-15 monthly reporting.
- Multi-Bank Card Settlement Reconciliation: Daily automated reconciliation of credit card POS machine settlement slips with bank deposits.
22.17 Multi-Currency & International Tourist Dining
- Dynamic Multi-Currency Storefront: Live conversion to USD, EUR, GBP, AED, and BDT based on visitor preference.
- International Digital Wallet Gateway: Seamless acceptance of Stripe, Apple Pay, and Google Pay.
22.17b Meal packages (built)
- Owner-built dish bundles sold at one price — a family platter, an iftar
box, a lunch deal.
/dashboard/packages behind FEATURE.packages, shown to
guests above the dish grid on /table, ordered as a single cart line.
Distinct from a promo: no code, no expiry, no landing page, and every line
points at a real MenuItem so the price and availability stay live.
Choose-N groups are built: a package can carry "pick one of these"
steps (the thali pattern), each option optionally adding a surcharge. The
guest's picks land in the cart line's id, so two people choosing
differently get two lines rather than one of quantity two, and on the
kitchen ticket so a cook can read what to make. Owners photograph a
package from the same board; the guest sees the strip in the detail sheet.
Scheduling is built: a package can run on chosen days and between
chosen hours, evaluated in the restaurant's own timezone (Tenant.timezone,
on the record since the start and used here for the first time) rather than
the guest's device clock. Windows may cross midnight, and a Friday-night
22:00–02:00 offer is still Friday's at one on Saturday morning. The owner's
board shows every package whatever the hour, with the schedule in plain
words and a note when guests cannot currently see it.
22.18 Offline-First PWA POS & Custom Whitelabel Domains
- Offline-First IndexedDB Sync Engine: Full offline resilience allowing POS checkouts and table ordering without internet connectivity, auto-syncing when online. (A service worker now keeps a scanned menu usable on a dropped connection, and the guest is told they are offline — but that is page caching, not a sync engine. There is no server to reconcile writes with yet.)
- Custom Tenant Whitelabel Domains: Multi-tenant custom domain routing (e.g.
menu.shadghor.com) with automated SSL provisioning.
- Accounting Software Sync: Automated end-of-day journal push to QuickBooks and Xero.