Skip to content

Roadmap, Phases & MVP Definition

Status Note — Read Before Following This Roadmap

This roadmap describes the backend-first build order, and that sequencing is still correct for everything from STEP 01 onward. What actually happened in this repo so far deviated from it on purpose, by explicit user instruction: every screen's UI was built first, on static dummy data, across all four working surfaces (Customer Storefront, Admin Dashboard, KDS, Waiter App — Platform Admin is untouched), before any Supabase/auth/database work. See CLAUDE.md "Current Status" and 08-FEATURE-LIST.md §21 for exactly what exists.

Practically, this means Phases 4–13 below already have a UI (Section 5 of each phase's corresponding feature area), but none of the Database, Auth, Realtime, or server-side-price work in Phases 2, 3, 9, 10 has started — so treat every phase from PHASE 2 onward as still fully ahead of you, not "UI done, just wire it up." The dummy-data modules under src/lib/dummy-data/ were deliberately shaped to match 03-DATABASE-ERD.md so that the eventual backend swap replaces data sources under already-built UI rather than triggering a redesign — but it is still real backend work, not plumbing.

Immediate next step is STEP 01 (Section 9 below) — Supabase project, migrations, RLS, auth — unless new UI gaps are found first (see the feature list's §21 gap column).

1. The Golden Rule

Do not start by building 20 dashboard pages. Start with one working vertical slice:

ONE RESTAURANT
      ↓
ONE BRANCH
      ↓
ONE TABLE
      ↓
ONE QR
      ↓
ONE CUSTOMER
      ↓
ONE ORDER
      ↓
ONE KITCHEN
      ↓
ONE WAITER
      ↓
ONE COMPLETED ORDER

Then generalize into the multi-tenant SaaS. This ensures the architecture is proven against a real, working business flow rather than a collection of disconnected UI screens that don't actually talk to each other.

2. Development Order (never build randomly)

Architecture
 ↓
Database
 ↓
Auth
 ↓
Tenant
 ↓
Restaurant onboarding
 ↓
Menu
 ↓
QR
 ↓
Customer storefront
 ↓
Cart
 ↓
Order engine
 ↓
Realtime
 ↓
KDS
 ↓
Waiter
 ↓
Cashier
 ↓
Analytics
 ↓
Inventory
 ↓
CRM
 ↓
Multi-branch
 ↓
AI

The single most important structural point: UI comes after architecture → database → security → business flow. Not before.

3. MVP Definition

MVP includes only:

  • Multi-tenant foundation
  • Auth
  • Restaurant, Branch, Tables
  • Dynamic QR
  • Menu, Categories, Food items, Variants, Allergens
  • Cart, Order
  • Basic Admin
  • Basic Order Dashboard

MVP explicitly does NOT include:

  • AI
  • Inventory
  • Supplier management
  • CRM
  • Advanced analytics
  • Complex POS
  • Advanced WhatsApp automation

4. MVP User Journey

Restaurant Owner
       ↓
Register
       ↓
Create Restaurant
       ↓
Create Branch
       ↓
Create Tables
       ↓
Generate QR
       ↓
Create Menu
       ↓
Print QR
       ↓
Customer scans
       ↓
Menu opens
       ↓
Customer selects food
       ↓
Allergy check
       ↓
Cart
       ↓
Order
       ↓
Restaurant sees order

This is the first complete vertical slice — once it works end to end, only then continue to KDS, Waiter, Cashier, etc.

5. Phase-by-Phase Breakdown

PHASE 0 — Product Foundation

Finalize requirements, user roles, order lifecycle, tenant model, database ERD, and design system. Create the repository, configure environments, configure Supabase. Do not start UI development before this phase is stable.

PHASE 1 — Project Setup

Next.js 16+ project, TypeScript, Tailwind, shadcn/ui, ESLint, Prettier, Husky/lint-staged, Supabase project, local Supabase CLI, environment variables, migration system, CI pipeline.

PHASE 2 — Database

Create the 24 migrations in the dependency order listed in 03-DATABASE-ERD.md Section 4.

PHASE 3 — Auth

Build login, register, forgot password, session, profile, restaurant membership, role, permissions. Then explicitly test each role: Owner, Manager, Cashier, Waiter, Kitchen.

PHASE 4 — Restaurant Onboarding

Owner flow: Register → Create Restaurant → Create Branch → Create Tables → Upload Logo → Configure Theme → Create Menu → Generate QR.

PHASE 5 — Menu Management

Categories, menu items, images, prices, variants, modifiers, ingredients, allergens, availability, ordering. Admin can create, edit, delete, reorder, enable/disable.

PHASE 6 — QR Generator

Admin: Tables → Generate QR → Download → Print. QR always points to /table?token=... — never a hardcoded path like /table/restaurant-1/table-5.

PHASE 7 — Customer Storefront

Build in this exact order: (1) QR resolver, (2) restaurant header, (3) hero, (4) categories, (5) menu, (6) food card, (7) food details, (8) allergy system, (9) cart, (10) checkout, (11) order confirmation.

PHASE 8 — Menu UX

Skeleton loading, category slider, sticky category bar, search, food card, image lazy loading, modal/bottom sheet, add-to-cart animation, cart drawer.

PHASE 9 — Order Engine

Create order, calculate price, validate items, create items, assign table, assign waiter, create kitchen order, create events, update table — everything server-side.

PHASE 10 — Realtime

Wire up: order created, confirmed, preparing, ready, served, completed — then connect Customer, KDS, Waiter, Cashier to those events.

PHASE 11 — KDS

New / Preparing / Ready / Completed columns. Features: realtime, sound, priority, station filtering, order timer, status transitions.

PHASE 12 — Waiter

Login, shift, assigned tables, orders, order status, table requests, bill request, notifications.

PHASE 13 — POS / Cashier

Orders, payment, cash, digital payment, receipt, refund, discount, tax, service charge.

PHASE 14 — Table Management

Table map, status, waiter assignment, QR regeneration, table session, merge tables, split bill. (Merge/split-bill can be pushed to Phase 2+ if MVP scope needs to stay smaller — see SRS open item #5.)

PHASE 15 — Analytics

Dashboard, sales, orders, AOV, peak hours, top items, table performance, waiter performance, channel performance.

PHASE 16 — Inventory

Ingredients, recipes, BOM, stock, stock movement, low stock, suppliers, purchase orders, waste.

PHASE 17 — CRM

Customers, order history, customer profile, spending, favorites, segments, offers, loyalty.

PHASE 18 — Multi-Branch

Central dashboard, branch switching, branch analytics, central menu, branch-specific menu, branch inventory, branch staff, branch permissions.

PHASE 19 — WhatsApp

WhatsApp order, order link, order confirmation, customer notifications, status updates. Kept as a separate integration layer (channel adapter), never deeply coupled into the core order engine:

Order Core
   │
   ├── QR
   ├── WhatsApp
   ├── POS
   └── Delivery

PHASE 20 — AI

  • AI Recommendation: Product + Customer behavior + Order history → Recommendation
  • Inventory Forecast: Historical sales + Seasonality + Day of week + Inventory → Forecast
  • AI BI: Question → Intent → Safe query → Database → Answer (never raw, unconstrained SQL generation from the LLM)

PHASE 21 — Hardware & Thermal Printing Engine

  • Direct ESC/POS & WebUSB / Bluetooth / Network Printing: Zero-dialog 80mm/58mm silent printing for KOTs, guest checks, and daily settlement slips.
  • Smart Station Kitchen Dispatch: Dynamic routing of order line items to separate production monitors (Grill, Fryer, Beverage, Pastry, Expediter).
  • Kitchen SLA & Cooking Timer Alarms: Audible alert beeps and visual color-coded warnings when prep times exceed SLA threshold (>15 mins).
  • Physical Bump Bar Hotkey Support: Dedicated kitchen hardware keyboard and numpad shortcuts.

PHASE 22 — Advanced Inventory, Recipe BOM & Waste Economics

  • Recipe Bill-of-Materials (BOM) Auto-Deduction: Real-time depletion of raw ingredients (protein, vegetables, dairy, oil, packaging) upon order fulfillment.
  • Low-Stock Triggers & Automated Reorder POs: Automated alert delivery to purchasing managers with pre-filled supplier purchase order requisitions.
  • Kitchen Spoilage & Waste Accounting: Daily digital tracking of burned, expired, or dropped items with financial shrinkage analysis.
  • Supplier & GRN Reconciliation: Vendor directory, price history tracking, and Goods Received Note verification.

PHASE 23 — Staff HRM, Rostering & Gamified Performance

  • PIN / Selfie Attendance Clock-In: Tablet-based digital shift sign-in with overtime and punctuality tracking.
  • Automated Waiter Tip Pool Calculation: Fair tip distribution engine based on active shift hours and role weights.
  • Staff Performance Leaderboards: Real-time leaderboards measuring top upselling servers, highest average order value, and fastest table turn times.

PHASE 24 — Automated CRM, Lifecycle Marketing & Gift Cards

  • Automated Birthday/Anniversary Campaigns: Scheduled personalized discount vouchers dispatched via WhatsApp/SMS.
  • Dormant Customer Win-Back Sequences: Automatic re-engagement workflows targeting customers with no orders in 30+ days.
  • Digital Stored-Value & Gift Card Wallet: Reloadable customer gift cards with custom branding, PIN security, and gift transfers.

PHASE 25 — Offline-First POS, Delivery Aggregators & Whitelabeling

  • Offline-First IndexedDB Engine: Uninterrupted checkout and table billing during internet outages, syncing automatically on reconnection.
  • Third-Party Delivery Aggregator Hub: Webhook bridge aggregating Foodpanda, Pathao, and UberEats orders into POS and KDS.
  • Custom Whitelabel Domains: Custom domain routing (order.restaurantname.com) with automatic SSL provisioning.
  • Augmented Reality (AR) 3D Food Previews: Smartphone browser 3D dish visualizer.

6. Development Milestones

#Milestone
1Project + Supabase
2Database + RLS
3Auth + Restaurant onboarding
4Menu CMS
5Dynamic QR
6Customer menu
7Cart + Order
8Realtime
9KDS
10Waiter
11Cashier
12Analytics
13Inventory
14CRM
15Multi-branch
16AI

7. Definition of Done

A feature is not complete when the UI is finished. It is complete when all of the following are true together:

UI + Validation + Database + Permissions + Loading + Error handling
+ Empty state + Mobile responsive + Accessibility + Realtime (where
required) + Tests

Every Screen Checklist

Loading state, empty state, error state, success state, mobile layout, tablet layout, desktop layout, keyboard accessibility, animation, skeleton, permission handling.

Menu Screen Checklist

Restaurant header, logo, cover image, restaurant status, search, categories, featured, menu, food card, price, availability, allergen, variants, modifiers, add button, cart, loading, empty, error.

Order Screen Checklist

Order ID, table, waiter, items, modifiers, quantity, special instructions, subtotal, tax, discount, service charge, total, payment, status, timeline.

8. Final Production Architecture (target state, not MVP)

                        USERS
                          │
          ┌───────────────┼────────────────┐
          │               │                │
       Customer         Waiter           Admin
          │               │                │
          └───────────────┼────────────────┘
                          ▼
                   Next.js 16+
                          │
             ┌────────────┼────────────┐
             ▼            ▼            ▼
        Server Actions  API Routes   Realtime
             │            │            │
             └────────────┼────────────┘
                          ▼
                     Supabase
             ┌────────────┼────────────┐
             ▼            ▼            ▼
         PostgreSQL      Auth       Storage
             │
       ┌─────┼──────┐
       ▼     ▼      ▼
      RLS  Realtime pgvector
                    │
                    ▼
                  AI

9. Immediate Next Step — STEP 01

The first implementation task, before any UI work:

  1. Next.js 16+
  2. TypeScript
  3. Tailwind CSS
  4. shadcn/ui
  5. Supabase
  6. Local Supabase
  7. Environment setup
  8. Database migration structure
  9. Authentication foundation
  10. Initial ERD
  11. Tenant architecture
  12. Folder architecture
  13. Design tokens
  14. Git workflow

Followed by, one at a time, not in parallel:

STEP 02  Database migrations + RLS
   ↓
STEP 03  Auth + RBAC
   ↓
STEP 04  Restaurant onboarding
   ↓
STEP 05  Menu CMS
   ↓
STEP 06  Dynamic QR
   ↓
STEP 07  Customer menu

Complete one step before starting the next — this roadmap is explicitly sequential, not a backlog to be parallelized across steps.