Il problema
Il Ristorante Gina, un ristorante di pesce, gestiva il servizio su carta: i camerieri scrivevano le comande a mano, cucina e bar leggevano gli stessi foglietti e il conto si faceva alla cassa. I titolari volevano un unico sistema per sala, cucina e gestore, costruito in modo da poter servire in futuro più di un ristorante.
Cosa ho costruito
Ho sviluppato RistoFlow, una web app per la gestione del ristorante, e l’ho configurata con Gina come primo locale.
- Pianta della sala — tavoli raggruppati per sala, con stati in tempo reale (libero, occupato, comande in corso, comande pronte) e il numero di coperti indicato all’apertura del tavolo.
- Comande dal telefono — i camerieri compongono la comanda per categoria, con note per ogni piatto. All’invio viene divisa automaticamente tra cucina e bar, così ogni postazione vede solo il proprio lavoro.
- Monitor di cucina — uno schermo che si aggiorna ogni 5 secondi, porta ogni comanda da inviata a in preparazione, pronta e servita, evidenzia i ritardi e stampa uno scontrino da 72mm, anche in automatico.
- Conti — totale del tavolo con coperto, preconto stampabile e chiusura. Dalla versione 1.5.0 i prezzi li vede solo il gestore, che chiude il conto, e non camerieri o cucina.
- Gestione menu e report — categorie, prezzi (anche per 100 g), piatti segnati come esauriti al volo, e incassi, coperti e piatti più venduti del giorno.
- Quattro ruoli, tanti ristoranti — amministratore della piattaforma, gestore, cameriere e cucina. Ogni ristorante ha i propri utenti e dati, tenuti separati.
- Pacchetto per server locale — un installer che mette l’app, con il menu e i tavoli reali di Gina, su un PC dentro il ristorante, con uno script di backup giornaliero.
Con cosa è fatto
PHP 8 e MySQL con PDO, JavaScript puro, nessuna libreria esterna. Un solo endpoint API gestisce tutte le chiamate. Sessioni con token CSRF e password salvate come hash. Il menu e la carta dei vini di Gina sono stati caricati in 9 categorie.
Perché è fatto così
Ho tenuto l’app libera da dipendenze e ho usato un semplice polling al posto dei websocket, così gira su un normale hosting condiviso. La stessa scelta ha reso facile spostarla su un server locale: comande e conti continuano a funzionare sul Wi-Fi del ristorante anche quando cade la connessione a internet.
