Soluzioni · Ristoranti e HoReCa
Il menu di un locale non è una brochure: ha prezzi e volumi che devono essere esatti, cambia spesso ed è letto da persone che parlano tre lingue. Costruiamo il menu come dati, generiamo la pagina da essi e verifichiamo prima di ogni pubblicazione, incluso che i prezzi scendano in ogni categoria e che ogni foto esista.
Già costruitoDouă meniuri digitale în producție, verificabile din exterior azi. Primul: 119 produse în 21 de categorii, cu preț, volum, compoziție și fotografie, plus câte un text scurt de prezentare și un set de recomandări de asociere pentru fiecare produs; generatorul are 402 linii, iar verificarea dinaintea publicării are 233 de linii și 16 blocuri. Al doilea, site-ul-soră cu același motor: 146 de produse în 31 de categorii, generator de 377 de linii, verificare de 210 linii cu 14 blocuri, iar integrarea continuă regenerează pagina din surse și respinge modificarea dacă rezultatul diferă de fișierul din depozit. Ambele răspund 200 și niciunul nu pune vreun cookie — verificat de mine pe 06.09.2026. Spunem și că sunt două lucrări cu același motor și același proprietar, nu două lucrări independente.
Un PDF scansionato su un codice QR non risolve nulla di ciò che un locale deve risolvere. Non si cerca in esso, non si traduce, non si ingrandisce bene sul telefono e non si può modificare senza ristampare il codice. E il menu cambia spesso: la cucina toglie un piatto, il bar riceve un’altra marca, il prezzo di una voce aumenta. Il menu è un insieme di dati che si modifica settimanalmente, non un documento stampato una volta.
Per questo lo trattiamo come dati. Le fonti reali sono alcuni file strutturati — prodotti, testi di presentazione, raccomandazioni di abbinamento, traduzioni — e un generatore scritto in Python compone da essi una sola pagina. In uno dei locali: 119 prodotti in 21 categorie, ciascuno con prezzo, volume, composizione e fotografia, più 119 testi brevi e 119 set di «con cosa si abbina». Nell’altro: 146 prodotti in 31 categorie. La pagina non si modifica direttamente — si rigenera.
La traduzione non si ferma ai pulsanti. Il romeno è la base, e il russo e l’inglese coprono le categorie, le denominazioni, i volumi, le composizioni, le 82 etichette di gusto e tutti i testi di presentazione. In una città in cui il tavolo vicino ordina in un’altra lingua, un menu tradotto a metà è più fastidioso di uno non tradotto: vi lascia credere che possiate leggere tutto.
La parte che consideriamo la più importante e che nessuno richiede nel brief: il carrello, la lista dei preferiti e la divisione del conto girano nel browser, senza account e senza server, e il sito non inserisce alcun cookie e non chiede nulla a un dominio terzo. Non è una promessa dalla politica di riservatezza — è una regola imposta da verifiche automatiche che vengono eseguite prima di ogni pubblicazione e che respingono la modifica se è apparso qualche tracker, qualche risorsa esterna o qualche font preso da altri.
Cosa comprende
I prodotti, i testi di presentazione, le raccomandazioni e le traduzioni stanno in file strutturati; un generatore scritto in Python — 402 righe in un locale, 377 nell’altro — compone da essi una sola pagina. La pagina pubblicata non si modifica a mano; quando qualcuno lo fa, l’integrazione continua lo intercetta, perché rigenera la pagina e confronta il risultato.
In un bar, il volume fa parte del prezzo: la stessa denominazione a 40 e a 100 millilitri sono due prodotti diversi, e il cliente che non vede il volume crede che gli sia stato detto altro. La struttura dei dati tiene tutti e quattro i campi come obbligatori, non come opzionali, proprio perché una voce incompleta non finisca sul tavolo.
La traduzione copre l’interfaccia, le categorie, le denominazioni, i volumi, le composizioni, le 82 etichette di gusto e tutti i testi brevi di presentazione, con ogni chiave romena che ha la sua coppia in russo e in inglese. Uno dei controlli prima della pubblicazione fallisce se il menu non è completo in tutte e tre le lingue.
Senza account, senza server, senza dati inviati da nessuna parte. Il cliente compone il proprio ordine sul telefono e lo mostra al cameriere oppure lo usa per dividere il conto. La conseguenza tecnica: non esiste una base con ciò che hanno ordinato i Suoi clienti, perché non ne viene creata una.
Verificato dall’esterno: nessun header di cookie su nessuno dei due siti, e la politica dei contenuti di uno di essi non consente assolutamente nulla dall’esterno. I font sono ospitati sullo stesso dominio, non presso un servizio esterno. Gli unici indirizzi esterni nella pagina sono i link ai social network del locale — che il visitatore preme, non che la pagina richiama.
Sedici blocchi di verifica in un locale, quattordici nell’altro: nessun tracker, nessuna risorsa caricata automaticamente da terzi, font auto-ospitati, file strutturati validi, ogni fotografia esiste, menu completo in tre lingue, dati strutturati della pagina validi e — quello che sorprende tutti — i prezzi scendono in ogni categoria. Un prezzo inserito male si vede come una discontinuità nell’ordine dell’elenco, non dalla lamentela del cliente.
A ogni modifica, l’integrazione continua rigenera la pagina dalle fonti e respinge la modifica se il risultato differisce dal file nel repository. È l’unica garanzia reale che ciò che è sullo schermo del cliente provenga dai dati che il locale modifica, e non da un intervento manuale dimenticato lì tre mesi fa.
Nella configurazione del server di uno dei locali: mascheratura degli indirizzi IP, intestazioni di identificazione cancellate dal log e conservazione limitata, con riferimento esplicito al principio della limitazione della conservazione. L’integrazione continua rifiuta la modifica se da questa configurazione scompaiono queste righe — quindi la protezione non può andare persa in silenzio con un cambio di server.
Non prende l’ordine in cucina e non conferma una prenotazione: per questo serve una connessione al sistema operativo del locale, che è un lavoro separato. E non pubblichiamo funzioni che promettono qualcosa che deve essere onorato alla cassa — uno sconto di tipo «happy hour» o un orario della cucina non si avviano senza il consenso scritto del locale, perché chi paga la promessa sullo schermo è la persona al banco.
Traseul
La prima consegna è il menu come dati: categorie, voci, prezzo, volume, composizione, fotografia. Qui emergono anche le mancanze — voci senza volume, categorie che in realtà sono due, prodotti senza fotografia. Un menu digitale costruito su dati incompleti appare incompleto, per quanto sia valido il design.
Le categorie, le denominazioni, i volumi, le composizioni, le etichette di gusto e i testi di presentazione ricevono le loro coppie in russo e in inglese. Consegnamo il menu completo in tre lingue e la verifica automatica che fallisce se una chiave resta non tradotta.
Niente tracker, nessuna risorsa di terze parti, font auto-ospitati, file validi, ogni fotografia presente, prezzi in ordine decrescente per categoria, dati strutturati validi. Consegnamo lo script di verifica nel repository, così il locale può eseguirlo anche senza di noi.
La pubblicazione avviene al merge della modifica, dopo che l’integrazione continua ha rigenerato la pagina e l’ha confrontata con le sorgenti, e dopo che è stata conservata una copia della versione precedente. Consegnamo gli accessi e la procedura di ripristino — non solo il sito avviato.
I dati
Le regole differiscono da un settore all’altro. Queste sono quelle che si applicano a ristoranti & horeca.
Un caso
La situazione
In un menu con oltre cento voci, l’errore più frequente non è di design, ma di digitazione: una cifra in più in un prezzo o una voce rimasta senza foto. Entrambi si scoprono, di solito, quando il cliente li mostra al cameriere.
Cosa abbiamo costruito
Prima della pubblicazione abbiamo inserito uno script di verifica — 233 righe in un locale, 210 nell’altro — che esegue sedici, rispettivamente quattordici blocchi: che non si sia infiltrato alcun tracker, che la pagina non richieda nulla da un dominio terzo, che i font siano ospitati localmente, che i file di dati siano validi e che ogni foto esista, che il menu sia completo in tutte e tre le lingue, che i dati strutturati nella pagina siano validi e che i prezzi scendano in ogni categoria. Separatamente, l’integrazione continua rigenera la pagina dalle sorgenti a ogni modifica e la respinge se il risultato differisce dal file pubblicato.
Cosa è emerso
Un errore di digitazione nel prezzo rompe l’ordine decrescente e blocca la pubblicazione, mentre una foto mancante non arriva mai sullo schermo del tavolo. La pagina pubblicata corrisponde sempre ai dati che il locale modifica in locale, perché altrimenti non si pubblica.
Cosa non dice il caso
Le verifiche intercettano ciò che si può verificare meccanicamente. Un prezzo inserito male, ma plausibile — e in ordine — passa; per quello non esiste altro meccanismo se non che qualcuno guardi. La documentazione di uno dei progetti dice „14 verifiche” dove lo script ha 16 blocchi; la cifra corretta è quella dello script.
Domande
Sì. Si modificano i dati, non la pagina; la pagina si rigenera da essi. L’integrazione continua verifica la rigenerazione a ogni modifica e respinge la modifica se la pagina pubblicata non corrisponde più alle sorgenti. Così non esiste lo scenario in cui qualcuno ha corretto un prezzo direttamente nella pagina e la modifica è scomparsa alla pubblicazione successiva.
Perché un menu che non raccoglie nulla non ha bisogno di banner di consenso, non ha nulla da far trapelare e non ha nulla da spiegare a un ispettore. La verifica è alla portata di chiunque: una sola richiesta al sito mostra che non ritorna alcun header di cookie. E la politica dei contenuti di uno dei locali non permette assolutamente nessuna risorsa esterna.
Il carrello funziona nel browser, come lista che il cliente mostra al cameriere o usa per dividere il conto. L’invio dell’ordine in cucina richiede una connessione al sistema del locale ed è un lavoro separato, con verifica di compatibilità prima. Non chiamiamo „ordine online” un carrello che non arriva da nessuna parte.
Si può costruire, ma non la avviamo senza il consenso scritto del locale, perché è una promessa che si onora alla cassa. La nostra regola: le funzioni che impegnano il locale verso il cliente — sconti, orari della cucina, disponibilità — non si pubblicano sulla base di una conversazione verbale.
Tre: romeno come base, russo e inglese. Completo significa categorie, denominazioni, volumi, composizioni, etichette di gusto e testi di presentazione, non solo pulsanti. Una verifica automatica fallisce se il menu non è completo in tutte e tre — per questo non arriva sul sito tradotto a metà.
Tra le verifiche prima della pubblicazione ce n’è una che richiede che i prezzi scendano in ogni categoria. Non è una regola commerciale, è un rilevatore di errori di digitazione: una voce inserita con una cifra in più o in meno rompe l’ordine e blocca la pubblicazione. Le altre verifiche si occupano di foto mancanti e di file non validi.
Il risultato è una singola pagina generata, con i font ospitati sullo stesso dominio e senza risorse richieste da domini terzi. Questo significa meno connessioni da aprire e nulla che debba attendere un servizio esterno. Non pubblichiamo cifre di velocità misurate in condizioni diverse dalle vostre.
Sì, e allora la politica dei contenuti della pagina consente esattamente quel dominio, nient’altro. In uno dei due locali questo si vede dall’esterno. Va detto anche il contrario: in quel momento la pagina non è più «senza nulla dall’esterno», quindi la decisione si prende consapevolmente, non come bonus.
Sono due siti con lo stesso motore, dello stesso proprietario, e lo diciamo esplicitamente. La differenza funzionale dichiarata tra loro sono i consigli di abbinamento per prodotto, che il secondo non ha. Potremmo presentarli come lavori indipendenti; sarebbe un’esagerazione di portafoglio.
Raccontaci il tuo processo. Insieme stabiliamo cosa vale la pena costruire, cosa possiamo collegare e come verifichiamo il risultato.