POS Resto — Web application (Laravel)
POS Resto runs the floor of a restaurant: orders per table, kitchen tickets, split bills, and reservations. Almost everything it stores is operational data — the only personal data is what a reservation or a staff account needs.
POS Resto is software that an organization installs and runs on its own infrastructure. The restaurant operating a given installation decides what data is entered into it and is the data controller for that installation. This page documents what the application itself collects and processes by design; it is the reference policy for the software, and an operator may publish additional terms on top of it. As the developer, I have no access to any production database unless an operator explicitly grants it for maintenance.
| Data | Why |
|---|---|
| Reservation data | Name, phone number, date and time, party size, and notes — so the table is held and you can be contacted about it. |
| Order data | Items, modifiers, table number, course timing, and status — sent to the kitchen display and used for the bill. |
| Bills and receipts | Totals, split-bill breakdown, payment method, and cashier — for accounting and reprints. |
| Staff accounts | Name, role (cashier, waiter, kitchen, manager), and hashed password. |
| Technical logs | IP address, user agent, and action timestamps. |
| Service | What it does |
|---|---|
| Pusher Privacy policy ↗ | Real-time channels for order and status updates. Message payloads pass through Pusher’s infrastructure. |
There is no payment gateway, no advertising network, and no analytics SDK. Receipt printing goes directly to a thermal printer on the local network.
The application uses cookies only for functionality:
There are no advertising cookies, no third-party analytics or tracking pixels, and no cross-site profiling. Clearing cookies simply logs you out.
Data stays inside the restaurant’s installation and is visible to staff according to their role. Reservation contact details are only needed until the reservation is honoured or cancelled and can be cleared afterwards; sales records are kept for as long as bookkeeping and tax obligations require.
The application applies standard protections: passwords are stored as one-way hashes (never in plain text), access is limited by role, and all traffic between client and server is expected to run over HTTPS/TLS.
No system is perfectly secure. Server hardening, backups, and access management for a live installation are the responsibility of the organization operating it.
The system is a staff-facing tool. Online reservations are intended to be made by adults.
You have the right to ask for access to, correction of, or deletion of your personal data, and to object to certain processing.
Because your data lives in the installation run by the organization you deal with, address those requests to that organization first — they hold the data and can act on it. If you cannot reach them, or you believe the application itself is at fault, contact the developer at mhdlutfidev@gmail.com and I will assist technically.
If this policy changes, the “Last updated” date at the top of this page will be revised. Material changes will be reflected in the application release notes.
Questions, complaints, or privacy requests about this application:
I aim to respond within 7 business days.