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
- 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.
- 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.
3. Files I Will Create Or Edit
documentation/pages/restroai-phase-0-roadmap.htmlfor this audit and roadmap.documentation/index.htmlto expose the roadmap in the documentation menu and overview.
4. Architecture Decisions
- 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.
- Preserve installer, Mailpit, settings, payments, notifications, and roles modules.
- Use
resources/views/components,x-ui.page-header, andusage/table-usage.htmltable patterns. - Use
appSwalconfirmation/loading flows andappToastresult 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.
- 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 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, andsubscription_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, andstaff_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, andbranch_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, andvoids. - 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, andkds_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, andupsell_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, andwastage_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, andreminder_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, andai_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 testgreen 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.