RestroAI POS SaaS Phase 0 Roadmap
Phase 0

Phase 0 Audit And RestroAI POS SaaS Roadmap

This page records the current Laravel project audit and the phased implementation plan for turning the existing admin foundation into a CodeCanyon-ready restaurant POS, KDS, waiter PWA, inventory, SaaS subscription, and AI business intelligence platform.

1. What I Found

Current Foundation
  • Laravel 12 with PHP 8.2 and MySQL-ready configuration.
  • Material Dashboard/Bootstrap admin shell with shared Blade UI components.
  • Installer, authentication, OTP/TOTP, settings, sessions, and branding modules.
  • Spatie roles and permissions with glossary metadata.
  • Notifications, activity logs, Mailpit support, and sandbox payment links.
  • Payment simulator, Stripe, PayPal, Razorpay, and Paystack sandbox adapters.
Current Gaps
  • No restaurant tenant, branch, floor, table, station, or staff domain yet.
  • No POS, order, KDS, waiter PWA, QR menu, inventory, customer, or reservation modules yet.
  • No SaaS plan/subscription domain tables yet.
  • No AI settings, AI usage logs, or AI insight workflow yet.
  • No tenant database provisioning or tenant route resolver yet.

2. What I Will Build In This Phase

Phase 0 is documentation and architecture only. It does not start Phase 1 code. The delivered artifact is this audit-backed roadmap with tenancy, module, database, testing, and implementation sequencing decisions locked.

Scope: tenant databases, subscriptions, and restaurant POS modules are scheduled for later phases. This page prevents the build from mixing architecture work with feature code before the tenancy boundary is ready.

3. Files I Will Create Or Edit

  • documentation/pages/restroai-phase-0-roadmap.html for this audit and roadmap.
  • documentation/index.html to expose the roadmap in the documentation menu and overview.

4. Architecture Decisions

Tenancy Model
  • Use database-per-tenant SaaS.
  • Keep the landlord database for platform records and billing.
  • Keep every restaurant's operational data in its own MySQL database.
  • Start with path routing at /r/{tenant} for shared-hosting friendliness.
  • Add custom domains after the path resolver is stable.
Foundation Rules
  • Preserve installer, Mailpit, settings, payments, notifications, and roles modules.
  • Use resources/views/components, x-ui.page-header, and usage/table-usage.html table patterns.
  • Use appSwal confirmation/loading flows and appToast result notifications.
  • Keep sandbox payments central and attach subscription invoices through polymorphic payable fields.
  • Keep AI optional, settings-controlled, logged per tenant, and limited by SaaS plan.

The planned tenancy package is stancl/tenancy after confirming the Laravel 12 compatible release in Packagist during Phase 1 implementation.

5. Database Tables And Migrations Involved

Phase 0 adds no migrations. The future architecture uses a central landlord database for platform-owned records and separate tenant databases for restaurant operations.

Central Database
  • Tenants/restaurants, tenant domains/slugs, tenant database records.
  • SaaS plans, plan features, subscriptions, invoices, usage counters.
  • Central payment requests, payment transactions, refunds, and webhooks.
  • Platform settings, activity logs, and super admin users.
Tenant Databases
  • Tenant users, roles, settings, branches, floors, tables, and stations.
  • Menu, POS, orders, KDS, waiter PWA, QR ordering, inventory, and purchases.
  • Customers, loyalty, reservations, report snapshots, and AI usage/insights.

6. Step-By-Step Implementation Sequence

Phase 1: Core SaaS Foundation + Subscriptions

Add database-per-tenant SaaS foundation, central Super Admin, restaurants, tenant provisioning, SaaS plans, plan limits, subscriptions, subscription invoices, and subscription payment flows through the existing sandbox payment module. Use /r/{tenant} for the first tenant access pattern.

  • Central tables: tenants, tenant_domains, tenant_databases, saas_plans, plan_features, subscriptions, subscription_invoices, and subscription_usage.
  • Tenant bootstrap tables: users, roles, permissions, settings, and branch seed records.
  • Routes: /admin/tenants, /admin/plans, /admin/subscriptions, and /r/{tenant}/dashboard.
  • Acceptance: tenant creation provisions the database, owner login resolves the tenant, limits enforce, subscription checkout creates a central payment request, and unpaid/expired subscriptions block tenant access.

Phase 2: Restaurant Setup

Build tenant-side branches, floors, tables, table statuses, kitchen stations, tax/service charge settings, receipt settings, and staff assignment.

  • Tables: branches, floors, tables, table_statuses, kitchen_stations, branch_settings, and staff_branch_assignments.
  • Acceptance: branch CRUD, tenant isolation, table status transitions, station assignment, and branch/table plan limits.

Phase 3: Menu Management

Build categories, items, variants, add-ons, modifiers, combo meals, branch pricing, item availability, kitchen station mapping, and optional AI menu description generation.

  • Tables: menu_categories, menu_items, item_variants, modifier_groups, modifiers, combo_items, and branch_menu_prices.
  • Acceptance: menu CRUD, branch price overrides, kitchen station metadata, and AI disabled/enabled behavior.

Phase 4: POS Cashier

Build touch POS, dine-in/takeaway/delivery orders, cart, discounts, taxes, split payments, merge bills, transfer table, hold/resume, refunds/voids with manager PIN, receipt printing, and shift open/close. Current implementation details are documented in POS Cashier Phase 4 and POS Operations Phase 4+.

  • Tables: orders, order_items, order_payments, order_discounts, shifts, cash_drawer_movements, refunds, and voids.
  • Acceptance: full order lifecycle, tax and discount calculations, split payments, manager PIN enforcement, and inventory hooks.

Phase 5: Kitchen Display System

Build live KDS boards, station routing, timers, item status, ready/served flow, sound alerts, delay warnings, KOT printing, and waiter notifications. Current implementation details are documented in Kitchen Display Phase 5.

  • Tables: kitchen_tickets, kitchen_ticket_items, kds_events, kds_station_preferences, kds_device_sessions, and kds_delay_warnings.
  • Realtime: Laravel Reverb or Pusher-compatible broadcasting with polling fallback.
  • Acceptance: station routing, timers, realtime event dispatch, and delayed order warnings.

Phase 6: Waiter PWA

Build the mobile waiter PWA with assigned tables, ordering, order modification, kitchen send, bill request, ready alerts, table transfer/merge, and waiter metrics. Current implementation details are documented in Waiter PWA Phase 6.

  • Add PWA manifest, service worker, offline-safe order drafts, waiter permissions, and assigned-table filtering.
  • Acceptance: PWA route access, offline draft sync, assigned table visibility, and waiter performance metrics.

Phase 7: Table Map And QR Menu

Build drag-and-drop table map, table QR codes, customer QR menu, customer ordering, waiter approval, smart upsell rules, and table revenue heatmap. Current implementation details are documented in Table Map And QR Menu Phase 7.

  • Tables: table_layouts, qr_sessions, customer_cart_sessions, and upsell_rules.
  • Acceptance: layout save/load, QR table binding, approval workflow, and heatmap aggregation.

Phase 8: Inventory, Recipe/BOM, Purchase

Build ingredients, units, suppliers, purchase orders, stock movements, wastage, expiry, recipes, sales-based deductions, costing, margins, and variance reporting. Current implementation details are documented in Inventory, Recipe/BOM, Purchase Phase 8.

  • Tables: ingredients, units, suppliers, purchase_orders, stock_movements, recipes, recipe_items, and wastage_entries.
  • Acceptance: recipe deduction, unit conversion, low-stock alerts, purchase receiving, and cost/margin calculations.

Phase 9: Customers, Loyalty, Reservations

Build customer profiles, loyalty, coupons, gift cards, reservation calendar, waitlist, no-show tracking, and reminder notifications. Current implementation details are documented in Customers, Loyalty, Reservations Phase 9.

  • Tables: customers, customer_order_links, loyalty_transactions, coupons, gift_cards, reservations, waitlist_entries, and reminder_attempts.
  • Acceptance: paid order profile linking, loyalty earn/reversal, coupon rules, gift-card ledger, reminder attempts, and reservation conflict prevention.

Phase 10: Reports And AI Intelligence

Build reports plus optional AI daily briefing, profit leakage watchdog, suspicious refund/discount/void alerts, purchase suggestions, menu engineering, customer segmentation, and kitchen delay prediction. Current implementation details are documented in Reports And AI Intelligence Phase 10.

  • Tables: report_snapshots, report_exports, ai_settings, ai_usage_logs, ai_insights, and ai_credit_limits.
  • Acceptance: report aggregation, snapshots, exports, tenant isolation, AI disabled state, usage limits, evidence-backed insights, and provider failure handling.

Phase 11: CodeCanyon Polish

Finalize installer, demo data, docs, changelog, screenshots checklist, test credentials, requirements, error handling, performance, queues, security audit, and packaging.

  • Acceptance: fresh install works, demo tenant works end-to-end, docs match UI, no hardcoded secrets, tests pass, and demo flows remain intact.

7. Commands To Run

php artisan test
php artisan route:list
php artisan migrate --pretend

8. Testing Checklist

  • Keep php artisan test green after every phase.
  • Test tenant database provisioning and tenant isolation before restaurant modules.
  • Test plan limits for restaurants, branches, tables, staff, AI credits, and feature access.
  • Use HTTP fakes for payment and AI providers.
  • Use queue fakes for provisioning, notifications, AI jobs, and heavy reports.
  • Verify shared UI behavior: table layout, page header, Swal confirm/loading, and appToast result.

9. Assumptions

  • User-selected tenancy is database per tenant.
  • Phase 1 includes SaaS subscriptions.
  • Live payments remain blocked until a later production-readiness phase.
  • Initial tenant access uses /r/{tenant}; custom domains are deferred.
  • Existing installer, settings, payment, Mailpit, documentation, and shared UI patterns must be preserved and extended.

10. What Is Completed

  • Phase 0 project audit completed.
  • Database-per-tenant architecture selected.
  • Phase 1 subscription scope selected.
  • Current test status recorded: 9 passed, 81 assertions.
  • Roadmap added to project documentation.

11. What Remains For The Next Phase

  • Install and configure tenancy package support for Laravel 12.
  • Create central tenant, plan, subscription, invoice, usage, and provisioning tables.
  • Create tenant database migration path and seeders.
  • Add Super Admin tenant/plan/subscription screens using existing UI components.
  • Connect subscription invoices to the existing sandbox payment module.
  • Add tenant route resolver and tenant dashboard at /r/{tenant}/dashboard.