A client restaurant operations product connecting customer ordering, back-office management, a tablet POS, inventory, cash control, and local kitchen printing.
Portfolio showcase only. The client source repository remains private. This repository contains no production credentials, customer records, database exports, or proprietary source code.
Smash It is a working product built around the operational path from an order to kitchen execution and management reporting. Customers can order from a responsive web interface, cashiers use an Android/PWA point of sale, and managers operate the catalog, orders, purchasing, cash, inventory, and reporting from a back office.
Restaurant operations cross several systems: menu configuration, order capture, payment, preparation, stock consumption, purchasing, cash reconciliation, and reporting. Disconnected tools create repeated entry, inconsistent totals, missed web orders, and limited traceability.
The product uses one backend and relational data model as the operational source of truth. Web and POS orders are validated and priced on the server, recorded transactionally, reflected in inventory, and surfaced to staff. The Android POS connects the cloud workflow to receipt and kitchen printers on the restaurant's local network.
- Customers: browse the menu and submit pickup, takeaway, delivery, or dine-in orders.
- Cashiers: use PIN access, manage baskets and cash sessions, and print tickets.
- Managers and owners: manage catalog, orders, purchases, stock, recipes, team access, settings, and reporting.
- Customer ordering site built with React and Vite.
- Tablet-oriented POS packaged for Android with Capacitor.
- Back-office PWA for operational management.
- Product variants, required/optional choices, and server-authoritative pricing.
- Idempotent order submission to protect against retry duplicates.
- Order lifecycle and status history.
- Cash sessions, payments, cash movements, purchases, and fixed expenses.
- Ingredient, recipe, weighted-average cost, and stock-movement tracking.
- Transactional stock consumption and cancellation restocking.
- Local ESC/POS receipt and kitchen printing over the on-site network.
- Operational Socket.IO events and Web Push notifications.
- PostgreSQL persistence through Prisma.
- Protect the order at the boundary: the backend rebuilds prices and totals from persisted catalog data rather than trusting browser values.
- Preserve history: product names, variants, option prices, and costs are snapshotted with each order.
- Make retries safe: a business-scoped client order ID turns duplicate submissions into idempotent replays.
- Keep related business effects atomic: order, stock, purchase, and cash updates use database transactions.
- Keep printers off the public internet: the Android POS reaches printers directly over the restaurant LAN.
flowchart LR
Customer[Customer web app] --> API[Express + TypeScript API]
Manager[Back-office PWA] --> API
POS[React + Capacitor POS] --> API
API --> Prisma[Prisma]
Prisma --> DB[(PostgreSQL)]
API --> Media[Cloud media]
API --> Push[Web Push]
API -. Operational events .-> Manager
API -. Operational events .-> POS
POS --> Native[Android printer bridge]
Native --> Receipt[Receipt printer]
Native --> Kitchen[Kitchen printer]
The implementation is a modular monolith: shared business rules and transactional workflows remain in one API, while the customer site, POS, and back office are independently buildable clients.
See Architecture Notes for verified workflows and trade-offs.
The relational model covers:
- identity, businesses, roles, refresh sessions, and audit logs;
- categories, products, variants, option groups, and options;
- orders, item snapshots, payments, and status events;
- cash sessions, cash movements, purchases, and expenses;
- ingredients, recipes, and stock movements;
- settings, printer configuration, print jobs, and push subscriptions.
Business-owned records carry a tenant identifier and are scoped at the application layer. Monetary and quantity values are stored as database decimals.
- bcrypt password and PIN hashes;
- signed access tokens and hashed, rotating refresh tokens;
- role checks and business-scoped queries;
- Zod request validation;
- production secret-strength and database-target validation;
- explicit production CORS configuration;
- audit logging for sensitive actions;
- Git exclusions for credentials, databases, signing keys, uploads, and backups.
- real-time connections still require authenticated, tenant-specific rooms;
- general login needs distributed rate limiting;
- query-string token support should be removed;
- tenant-isolation and authorization integration coverage should be expanded;
- automated CI security checks are not yet enforced.
These are documented limitations, not hidden claims. See Security and Privacy.
- Recalculating and validating the same commercial rules for customer and POS orders.
- Preventing duplicate orders during unreliable-network retries.
- Updating orders, inventory, purchasing, and cash records consistently.
- Retaining historical price and cost truth after catalog changes.
- Bridging a cloud application to local network printers through Android.
| Decision | Reason |
|---|---|
| Modular monolith | Keeps tightly related restaurant workflows within one transaction boundary |
| PostgreSQL + Prisma | Fits relational business data, Decimal fields, constraints, and transactional updates |
| React + Vite clients | Supports focused, independently deployed operational interfaces |
| Capacitor POS | Reuses the web interface while enabling Android notifications and printer networking |
| Server-side snapshots | Preserves historical order and margin reporting |
| Client order ID | Makes network retries safe and observable |
The images below use public catalog information and contain no customer order, phone, address, revenue, supplier, credential, or printer-network data.
The private implementation was verified on 28 August 2026 with:
- TypeScript checks for the backend and three active frontends;
- production builds for the API, back office, POS, and customer site;
- a targeted POS web-order alert test;
- Git whitespace validation;
- Gitleaks scanning of current tracked files.
The showcase contains no executable client code. Database-backed authorization, tenant isolation, and hardware printing need broader automated coverage.
AI accelerated implementation, debugging, documentation, and verification. Product constraints, architecture, database design, security assessment, acceptance criteria, and final code decisions remained under human control. Generated changes were reviewed and validated against the working system.
Git history in the private repository identifies Moad as its sole contributor. Repository evidence supports ownership of architecture, database design, backend and frontend implementation, Android/POS integration, deployment configuration, operational tooling, and technical documentation. The exact client-discovery and production-handover scope is not claimed because it is not documented in Git.
- Authenticate real-time connections and isolate events by business.
- Add distributed abuse protection and remove query-string access tokens.
- Expand integration coverage for authorization, tenancy, order retries, stock reversal, and cash reconciliation.
- Enforce build, dependency, and secret checks in CI.
- Formalize PII retention and operational observability.
This public repository intentionally excludes implementation code and operating data. Brand names and product imagery remain the property of their respective owners and are shown only to explain the delivered product.