The server decides the price, not the browser.
A restaurant platform built around four branches, with a customer storefront and an admin dashboard on the same data.
01 / The problem
I wanted to learn Laravel through an application that was actually complete, not another CRUD exercise. So I built a restaurant platform with four branches, carrying both a customer storefront and an admin dashboard in one system.
The difficulty was keeping menus, orders, reservations, branches, customers and staff correctly related to each other. Customers needed to browse the menu, order and reserve; staff needed access scoped to the branch they actually manage.
02 / Decisions
Prices are re-read from the database at checkout
The frontend sends which items were chosen. The backend then looks up each item's price again and computes the transaction total on the server before the order is saved. I rejected treating the cart subtotal as the source of truth, because data coming from a browser can drift out of sync with the frontend state, or be modified before it arrives. The database stays the authority on price; the backend decides the final amount.
03 / The outcome
- A fullstack application where the customer storefront and the admin dashboard read from one source of data.
- Four branches, customer ordering, reservations, and role-based access separating staff from admins.
- Separate authentication for customers and for staff.
- An admin dashboard with a summary view and a seven-day sales chart.