TotalCashPro

01 — Overview

TotalCashPro models the business — organisations, branches, staff, suppliers — once, and builds every back-office workflow on top: multi-till cash-ups and bank reconciliation, rotas and leave, stock and purchase orders, temperature logs and food-safety tasks, recruitment, delivery and subscription billing.

02 — The problem

Owners of several restaurants reconcile cash, sales, staff hours, supplier invoices and food-safety checks site by site, often on paper or spreadsheets. Numbers arrive late, rarely agree, and compliance records are hard to produce when an inspector asks.

03 — My contribution

Full-stack engineer — domain modelling, Laravel backend, role-based panels and billing.

04 — System architecture

1. 01 · frontend

   Panels

   • Super Admin
   • Business Admin
   • Staff
   • Rider
   • Kiosk (staff PIN)
   • Security
   • Public marketing & CMS pages

2. 02 · api

   HTTP & API

   • routes/api/v1.php
   • Laravel Sanctum
   • Role-scoped route files per panel

3. 03 · services

   Application layer

   • 23 service areas (Billing, FoodSafety, Temperature, Kiosk, Recruitment, Rider, Security, Staff …)
   • Actions, DTOs, Value Objects, Repositories
   • Events & listeners (e.g. ShiftSwapApproved, PurchaseOrderReceived, RecurringBillGenerated)
   • Observers · 35 Policies

4. 04 · database

   Data

   • 147 Eloquent models · 60 migrations
   • Audit, activity and login-history logs
   • Seeded roles, plans, settings, CMS and food-safety templates

5. 05 · infrastructure

   Integrations & jobs

   • Stripe billing + webhook event log
   • Queued email & push notification jobs
   • Redis
   • AWS

05 — Technology stack

• Laravel
• PHP
• Sanctum
• Vite
• Tailwind CSS
• Alpine.js
• Stripe
• Redis
• AWS

Taken from the project's manifests and architecture documentation.

06 — Modules

• Cash-ups & cash drawers
• Finance & bank reconciliation
• Payroll runs & wages
• Rotas, shifts & leave
• Attendance & kiosk clock-in
• Inventory & stocktakes
• Purchase orders & supplier invoices
• Food safety & temperature logs
• Tasks & checklists
• Recruitment pipeline
• Delivery & riders
• CRM & messaging
• Subscription billing
• CMS & chatbot FAQ

07 — Engineering decisions

• Separate route files and panels per role, so each audience sees a focused interface and authorization stays explicit.
• Actions, DTOs and value objects instead of fat controllers — business operations are small, testable units.
• Domain events (leave approved, shift swap approved, PO received, recurring bill generated) drive notifications instead of inline calls.
• Stripe webhooks are stored as events first, giving an audit trail for billing state.
• Clean-by-default seeding: production starts with roles, plans and templates only; demo data is an explicit opt-in command.

08 — Challenges & solutions

09 — Performance & scalability

• Queued notification jobs
• Dashboard caching covered by DashboardCacheTest
• Redis configured

10 — Security

• 35 authorization policies
• Role-scoped panels and middleware
• Two-factor recovery codes, OTP codes and login history
• Security and audit logs
• Separate local/staging credentials; never production

11 — Infrastructure & deployment

Live at totalcashpro.com. The repository includes a root .htaccess and index.php for shared-hosting deployment, plus a staging reset command (db:reset-staging).

12 — Outcomes

• Live product at totalcashpro.com

13 — Evidence

Architecture and implementation documented in source · reviewed 8 Nov 2026

• Private repository
• Architecture document (private repository)
• totalcashpro.com
• Project inventory in GitHub profile README

Private repositories are available to review on request.