In sintesi: che cosa ho sviluppato con FullRestaurant
FullRestaurant è un sistema per collegare prenotazioni, disponibilità, tavoli, lista d’attesa e ordini delivery o takeaway al lavoro quotidiano del ristorante. Il progetto comprende un’interfaccia web, una PWA, una componente mobile e procedure server che controllano le operazioni prima di salvarle.
Il mio lavoro non si ferma al modulo con cui il cliente sceglie un orario. Comprende ciò che succede dopo: stabilire se la richiesta possa essere accettata, distinguerla da una conferma, assegnare i tavoli, gestire una modifica, mantenere coerente un ordine e mostrare allo staff quale passaggio richiede attenzione.
Questo caso riguarda il gestionale FullRestaurant, non il suo sito commerciale. Le funzioni descritte sono riscontrate nel codice e nella documentazione del progetto esaminati nel settembre 2026. Non sono una dichiarazione che ogni modulo sia attivo in ogni ristorante, né un nuovo collaudo della produzione. Il risultato documentato è funzionale e architetturale: non vengono attribuite al software percentuali di crescita o ore risparmiate prive di misurazione.
Il problema: ricevere una richiesta non significa aver organizzato il servizio
Una prenotazione sembra un’informazione semplice: giorno, ora e numero di persone. Per chi gestisce la sala, però, apre una serie di domande. C’è disponibilità in quella fascia? Il gruppo può essere sistemato nella sala richiesta? Il cliente ha ricevuto una conferma o soltanto la registrazione della richiesta? Che cosa cambia se aggiunge due persone?
Lo stesso vale per un ordine. Registrare piatti e indirizzo non basta se il servizio è temporaneamente sospeso, un prodotto non è più disponibile o la cucina ha comunicato una nuova stima. Senza collegamenti fra questi passaggi, gli operatori devono ricostruire manualmente lo stato del lavoro.
È questo il problema operativo affrontato dal progetto: trasformare richieste separate in percorsi con regole, responsabilità e stati comprensibili. Non attribuisco questo racconto a un’intervista con un ristoratore: è una ricostruzione delle esigenze rappresentate dai requisiti e dal sistema sviluppato.
La differenza rispetto a un semplice sito con form è quindi concreta. Il sito raccoglie un’intenzione; il gestionale deve verificare se e come quell’intenzione possa diventare un servizio.
Prima dell’interfaccia: ristorante, utenti, regole e dati
FullRestaurant distingue le location e le responsabilità di chi le amministra. Un operatore non deve ottenere una vista indiscriminata su tutti i ristoranti soltanto perché può accedere al pannello.
Nel modello verificato, gli amministratori ordinari lavorano sulle location assegnate direttamente o attraverso una relazione di gestione. L’accesso generale del superamministratore è invece associato a un ruolo esplicito. L’assenza di una location assegnata non viene interpretata come autorizzazione a vedere tutto.
Anche gli oggetti operativi restano distinti: una prenotazione non è un ordine, una richiesta in lista d’attesa non è una conferma e una verifica della carta non equivale a un incasso. Conservare queste differenze nel modello dati permette all’interfaccia di mostrare informazioni più precise.
Il principio è lo stesso che applico nei software su misura: prima si definiscono relazioni e responsabilità, poi si costruiscono le schermate con cui le persone le gestiscono.
Dal widget alla prenotazione: i controlli non restano nel browser
Il percorso pubblico permette di inviare una richiesta, ma non demanda al widget l’ultima parola sulla sua ammissibilità. La procedura server verifica lo slot, le chiusure e gli eventuali limiti associati all’esperienza selezionata.
È una scelta importante perché ciò che il cliente vede sullo schermo può essere diventato vecchio nel frattempo. Una fascia disponibile all’apertura della pagina potrebbe non esserlo più al momento dell’invio. Il server deve rivalutare la richiesta utilizzando lo stato corrente, non fidarsi soltanto del controllo già effettuato nell’interfaccia.
Nel flusso verificato, la conferma automatica dipende da regole lato server. Quando tali condizioni non portano alla conferma, la richiesta rimane in attesa. Il percorso utente distingue i messaggi di prenotazione registrata da quelli di prenotazione confermata.
Per lo staff questa distinzione rende visibile il lavoro ancora da fare. Per il cliente evita di usare la stessa parola per due situazioni diverse: aver inviato una richiesta e avere una prenotazione confermata.
Che cosa succede quando arrivano due richieste insieme
Una delle parti meno visibili dello sviluppo riguarda la concorrenza: due persone possono richiedere gli ultimi posti quasi nello stesso momento. Controllare la disponibilità e salvare in due operazioni indipendenti può produrre una decisione basata su informazioni già superate.
La procedura pubblica del progetto serializza le richieste dello stesso ristorante e giorno prima di calcolare la capienza. Nel conteggio considera gli stati previsti, comprese le prenotazioni in attesa e confermate, e applica i filtri pertinenti per fascia e sala.
Detto in modo semplice, due richieste concorrenti non devono entrambe ragionare come se fossero arrivate da sole. Il controllo viene collocato nel punto in cui il dato può essere coordinato fra utenti diversi.
Questa è una proprietà del percorso pubblico esaminato, non una garanzia estesa automaticamente a qualunque canale di ingresso. Integrazioni, procedure amministrative e promozioni dalla lista d’attesa richiedono verifiche specifiche del proprio percorso.
Tavoli e combinazioni: il lavoro continua dopo la conferma
Per un gruppo può essere necessario unire più tavoli. Nel progetto le combinazioni sono strutture esplicite, con posti minimi e massimi, sala, priorità e stato di attivazione. Non si tratta soltanto di aggiungere una nota testuale alla prenotazione.
Il problema diventa ancora più interessante quando la prenotazione cambia. Se vengono modificati data, ora, numero di persone o sala, anche l’assegnazione deve essere riesaminata. Diversamente si rischia di aggiornare la richiesta lasciandola collegata a una sistemazione non più coerente.
La procedura verificata esegue la riassegnazione automatica nella stessa transazione della modifica. Allo stesso tempo preserva le assegnazioni deliberate dal ristorante, comprese le combinazioni che contengono componenti manuali.
È un compromesso progettuale preciso: automatizzare il lavoro ripetitivo senza cancellare una decisione consapevole dello staff. Un automatismo utile deve sapere non soltanto quando intervenire, ma anche quando rispettare una scelta umana.
Lista d’attesa: una disponibilità liberata apre un nuovo percorso
La lista d’attesa conserva informazioni strutturate: data, ora, numero di persone, eventuale esperienza e stato. Questo permette di trattarla come parte del processo di prenotazione, anziché come una raccolta di messaggi scollegati.
Il percorso di promozione presente nel codice cerca una richiesta compatibile e prepara un collegamento di risposta con una scadenza di quindici minuti. La successiva conferma distingue fra accettazione, rifiuto, richiesta già processata e collegamento scaduto.
Queste distinzioni servono a rappresentare situazioni reali: il cliente può rispondere tardi, riaprire lo stesso collegamento o decidere di non accettare. Il sistema deve poter spiegare che cosa è successo senza confondere una proposta con una prenotazione definitiva.
La promozione segue un percorso server distinto dall’invio pubblico ordinario. Per questo non uso la presenza della lista d’attesa come prova che ogni canale abbia già le stesse garanzie di gestione della capienza. La verifica trasversale dei percorsi resta parte del collaudo.
Carta e conferma: verificare non significa incassare
Nel percorso che richiede una verifica della carta, FullRestaurant distingue lo stato di attesa del passaggio di pagamento dalla prenotazione confermata. La funzione esaminata recupera il relativo SetupIntent da Stripe e richiede un esito positivo prima di salvare il riferimento al metodo di pagamento e aggiornare la conferma.
La distinzione conta anche quando si racconta il progetto. Questo flusso documenta la verifica di un metodo di pagamento; non dimostra, da solo, che sia stato incassato un importo, applicata una penale o riscosso un deposito.
Dal punto di vista dello sviluppo, il punto centrale è non dedurre il successo da una pagina chiusa o da un messaggio del browser. Il passaggio viene verificato presso il sistema che ne possiede l’esito e poi riflesso nello stato applicativo.
Eventuali regole commerciali, addebiti e condizioni del singolo ristorante richiedono un perimetro separato. Non vengono inventate a partire dalla sola presenza dell’integrazione tecnica.
Asporto e delivery: lo stesso menu, condizioni diverse
Il percorso di invio dell’ordine distingue takeaway e delivery. Prima di accettarlo verifica che il servizio sia attivo e non sospeso, che gli articoli siano disponibili e che il menu sia compatibile con il tipo di ordine scelto.
Per la consegna entrano in gioco anche zona, costo e importo minimo. Non basta quindi convertire una prenotazione in un carrello: si tratta di un processo diverso, con condizioni proprie.
Un prodotto può essere utilizzabile in un servizio ma non nell’altro. Una configurazione può cambiare mentre il cliente sta componendo l’ordine. Le verifiche lato server permettono di rivalutare queste condizioni nel momento in cui la richiesta viene effettivamente inviata.
Questo è uno dei motivi per cui ho lavorato sul collegamento fra menu, regole e operatività. Se fossero soltanto schermate indipendenti, lo staff dovrebbe risolvere a mano le incoerenze dopo aver ricevuto la richiesta.
Prezzi, varianti e salvataggio: un ordine deve restare intero
Il totale non viene assunto come corretto soltanto perché compare nel carrello. Il percorso server ricostruisce prezzi e opzioni dal menu e verifica le selezioni obbligatorie. Un’opzione mancante o non più valida non deve diventare un dettaglio da scoprire soltanto durante la preparazione.
Una volta validata la richiesta, ordine, righe, stato iniziale e utilizzo dell’eventuale coupon vengono salvati insieme attraverso una procedura atomica. Significa trattare questi elementi come un’operazione coerente, evitando di considerarne sufficiente il salvataggio parziale.
È una parte del lavoro che non si vede contando le pagine del gestionale. L’interfaccia può essere semplice proprio perché dietro esistono controlli per le combinazioni possibili, i prezzi correnti e l’integrità del dato.
La guida al software per prenotazioni, tavoli e delivery affronta le scelte generali. Qui il punto è mostrare come quelle esigenze si traducano in responsabilità effettive dentro il progetto.
Lo staff, i doppi tocchi e lo stato che è già cambiato
Durante il servizio un operatore può premere due volte, ritentare dopo una risposta lenta o agire mentre un collega sta aggiornando lo stesso ordine. Se ogni pressione fosse trattata come un evento completamente nuovo, il risultato potrebbe essere ambiguo.
La procedura di transizione degli ordini acquisisce un blocco sul record e mantiene uno storico. Gestisce una richiesta verso uno stato già raggiunto e rileva quando lo stato atteso dal chiamante è ormai superato.
L’obiettivo non è raccontare un sistema incapace di incontrare errori, ma progettare risposte comprensibili anche quando l’interazione non segue il percorso ideale. Un’azione già eseguita deve essere riconosciuta come tale; una schermata non aggiornata non deve decidere ignorando quello che è successo nel frattempo.
Anche l’orario stimato richiede precisione. Il progetto interpreta la stima nel fuso del ristorante, Europe/Rome: un orario ormai passato non viene spostato automaticamente al giorno successivo. Quando la stima riguarda un’altra data, la pagina cliente mostra anche il giorno. Sono dettagli piccoli nell’interfaccia, ma importanti per evitare informazioni equivoche.
Riordinare non significa copiare ciecamente il passato
Il pulsante di riordino sembra una scorciatoia semplice. In realtà deve confrontare una scelta storica con il menu di oggi: un prodotto può essere stato disattivato, una variante rimossa, un prezzo aggiornato o una categoria esclusa dal servizio richiesto.
La logica verificata ricostruisce il carrello usando il menu corrente. Esclude i prodotti non disponibili o incompatibili con il tipo di ordine, recupera le selezioni storiche attraverso riferimenti e snapshot e ricalcola con i prezzi attuali. Restituisce inoltre gli articoli e le opzioni che non è stato possibile mantenere.
Questo evita di trattare la cronologia come se fosse ancora un’offerta acquistabile senza controlli. L’ordine precedente aiuta a esprimere l’intenzione del cliente; il menu corrente stabilisce che cosa sia effettivamente selezionabile adesso.
È un esempio del livello di sviluppo dietro un comando apparentemente minimo: riutilizzare informazioni, gestire le differenze e rendere esplicito ciò che non può essere riproposto.
Web e mobile: la continuità richiede più di un’icona sul telefono
La base del progetto usa React e TypeScript, con PostgreSQL e funzioni server. Accanto alla PWA è presente una componente Capacitor per Android e iOS. Questo permette di distinguere il percorso web dalle capacità che dipendono dal dispositivo.
La documentazione separa gli aggiornamenti delle risorse web dalle modifiche native. Plugin, permessi e integrazioni hardware non possono essere trattati come una semplice variazione del testo di una pagina: richiedono una build e un ciclo di verifica appropriati.
Per il caso studio, quindi, «mobile» non significa promettere che tutte le capacità siano disponibili allo stesso modo su ogni telefono. La disponibilità corrente negli Store e il comportamento su dispositivi specifici devono essere verificati separatamente. Il codice mostra l’architettura sviluppata, non sostituisce quel controllo.
La stampa: progettata con una prova prima dell’attivazione
Il progetto comprende un percorso per stampanti Epson ePOS nella rete locale del ristorante: ricerca dei dispositivi oppure inserimento manuale dell’indirizzo, configurazione, prova e attivazione. Trovare un dispositivo in rete non viene considerato equivalente a sapere che possa stampare correttamente.
La procedura prevista richiede una ricevuta di prova riuscita prima di attivare un nuovo indirizzo di destinazione. Un cambio dell’indirizzo richiede una nuova verifica. La documentazione distingue inoltre la simulazione dalla stampa effettiva e prevede un controllo manuale per gli esiti incerti.
Il pilot fisico Epson non risulta completato nelle evidenze esaminate. Questa parte viene quindi descritta come implementazione e processo di collaudo predisposti, non come affidabilità hardware già dimostrata sul campo.
Rimane anche un limite operativo esplicito: non viene garantita la stampa autonoma quando il sistema operativo sospende l’app o l’utente la chiude forzatamente. Una soluzione che debba lavorare in quelle condizioni richiede componenti e verifiche ulteriori. Dichiarare questo confine fa parte del progetto, non è un dettaglio da nascondere.
Che cosa dimostra questo caso, e che cosa resta da misurare
FullRestaurant documenta un lavoro che collega esperienza del cliente, organizzazione della sala, ordini e procedure server. Le evidenze riguardano regole di accesso, controllo delle richieste, assegnazioni, stati, prezzi, transazioni, riordino e integrazioni mobile.
Non vengono pubblicati dati dei ristoranti, nominativi, indirizzi di consegna, prenotazioni o dettagli economici. Non sono disponibili, per questo caso, misurazioni sufficienti per dichiarare una riduzione dei no-show, un incremento del fatturato o un numero di ore risparmiate.
Gli indicatori utili da misurare in un perimetro concordato sarebbero invece precisi: richieste che richiedono intervento manuale, incoerenze rilevate, tempi di presa in carico, transizioni da correggere e risultati dei collaudi operativi. Servono dati iniziali e confronti omogenei, non percentuali decorative.
Le tre catture reali del 10 settembre 2026, pubblicate sopra, mostrano la mappa della sala, le opzioni del menu e l’interfaccia delle prenotazioni. Le didascalie indicano ambiente, dati esclusi e limiti di ciascuna verifica. Le schermate documentano quelle interfacce: non dimostrano risultati economici né sostituiscono il collaudo completo delle integrazioni descritte.
Quando un progetto di questo tipo ha senso per un’altra attività
Un software su misura diventa interessante quando le regole dell’attività non si esauriscono nella raccolta di un modulo: ruoli differenti, risorse da assegnare, richieste simultanee, variazioni, integrazioni e lavoro da coordinare dopo l’acquisto o la prenotazione.
Questo non rende lo sviluppo dedicato automaticamente preferibile a un prodotto standard. Prima occorre capire quali esigenze siano già coperte e quali richiedano davvero un sistema diverso. Il confronto è approfondito nella guida software gestionale standard, su misura o ibrido.
Se il tuo processo presenta problemi simili, possiamo partire da un flusso concreto: chi lo avvia, quali dati servono, chi prende la decisione e che cosa deve succedere quando qualcosa cambia. Da lì si definiscono il perimetro e le verifiche, prima di aggiungere schermate o automatismi.
Richiedi una consulenza sul tuo progetto.
