Beachfy e il gestionale che nasce dalla piantina della spiaggia

Come si gestisce oggi un lido e perché il calendario da solo non basta

Chi gestisce uno stabilimento balneare non ragiona per fasce orarie. Ragiona per posti. Il cliente abituale non chiede un ombrellone qualsiasi per martedì: chiede il quarantadue, quello in seconda fila vicino al passaggio, perché è lì che si mette da anni. Alla cassa arriva quasi sempre una richiesta di spazio, con un posto preciso in una fila precisa.

Molti software per lidi partono dal presupposto opposto. Sono costruiti sopra un modello preso in prestito da altri settori: una risorsa, un intervallo di tempo, una prenotazione che li lega. Il modello regge finché le risorse sono intercambiabili. Una camera vale l'altra a parità di categoria, una poltrona vale l'altra a parità di operatore. Su una spiaggia la posizione è il prodotto. La prima fila e l'ultima fila hanno prezzi diversi perché sono beni diversi, anche quando l'ombrellone è identico.

Il calendario resta indispensabile, ma da solo lascia scoperta la parte difficile. Se il dato primario è lo slot, la piantina finisce per essere un disegno mantenuto a parte, aggiornato a mano, che dopo tre settimane di stagione non corrisponde più alla spiaggia vera. Se invece il dato primario è la postazione collocata sulla mappa, il calendario diventa una proiezione: si legge, si mantiene da sé.

Beachfy nasce da questa inversione. È il prodotto su cui stiamo lavorando in Melarise e va detto subito: non è ancora aperto al pubblico. L'applicativo è sviluppato, ma l'apertura è dichiarata per l'estate 2027 e oggi il sito mostra una pagina di attesa con countdown. Quello che segue riguarda scelte progettuali e vincoli tecnici, prima ancora di qualsiasi risultato sul campo.

Il modello dei dati di un gestionale per stabilimento balneare parte dalla mappa

La struttura dei dati ricalca la gerarchia che esiste già sulla sabbia. La postazione è l'unità minima: un ombrellone con le sue coordinate sulla piantina e le sue dotazioni. Le postazioni stanno in file. Le file stanno in settori. Ognuno di questi livelli corrisponde a una parola che il gestore usa a voce quando parla con il bagnino.

Il listino si aggancia al settore e si ferma lì, senza scendere al singolo ombrellone, con i tre livelli che l'uso reale impone: feriale, weekend, alta stagione. È soprattutto una scelta di manutenzione. Se il prezzo fosse un attributo della postazione, ritoccare il listino a metà stagione significherebbe modificare centinaia di record e sperare che nessuno resti indietro.

La disponibilità, di conseguenza, è il risultato di un calcolo: una postazione, un intervallo di giorni, l'insieme delle prenotazioni che lo intersecano. Il registro delle prenotazioni conserva i fatti; la disponibilità è un'interrogazione su quei fatti. La distinzione evita la classe di bug più antipatica in questo dominio, cioè il doppio stato che si disallinea e produce due ombrelloni venduti sullo stesso posto.

Anche le statistiche di occupazione ereditano gratis la struttura. Sapere che una certa fila di un certo settore resta vuota nei feriali è un'informazione che può cambiare il listino. Sapere soltanto quanto è piena la spiaggia nel complesso serve molto meno. La granularità utile arriva dalla mappa: se il modello non la contiene, le statistiche non possono inventarla.

I problemi veri di un editor di mappe interattive dentro il browser

Il primo ostacolo è la quantità. Uno stabilimento di medie dimensioni ha molte postazioni, e ognuna è un elemento interattivo che deve rispondere al tocco. Se ogni movimento del puntatore attraversa lo stato applicativo e provoca un aggiornamento dell'intera piantina, il risultato è un trascinamento a scatti sul portatile e un telefono che scalda. La via d'uscita passa dal separare lo stato transitorio del trascinamento da quello applicativo: durante il gesto si muove solo l'elemento coinvolto, la riconciliazione avviene al rilascio.

Il secondo ostacolo è il tocco su mobile. Su una mappa, trascinare un elemento e spostare la vista sono lo stesso gesto fisico, e qualcuno deve decidere chi vince. Senza una disambiguazione esplicita, il gestore che prova a sistemare un ombrellone finisce per far scorrere tutta la spiaggia. Serve disattivare il trascinamento della mappa mentre una postazione è in movimento e restituirlo subito dopo. Va aggiunto che un ombrellone disegnato in scala reale può risultare più piccolo di un polpastrello: l'area sensibile al tocco deve essere più grande del simbolo che si vede.

Il terzo ostacolo è lo stato annullabile. Annulla e ripristina si progettano dall'inizio, prima ancora di scrivere le modifiche. Impongono che ogni cambiamento sia rappresentato come operazione descritta e reversibile, invece che come mutazione diretta dell'oggetto. Chi conserva soltanto l'ultimo stato buono si ritrova a copiare l'intera mappa a ogni pixel di spostamento, con il consumo di memoria che ne consegue.

Il quarto ostacolo è il salvataggio. Scrivere a ogni micro-modifica significa inondare il database; scrivere troppo di rado significa perdere lavoro alla prima disconnessione. Il compromesso è un salvataggio ritardato che scatta quando l'utente si ferma, con lo stato locale come fonte immediata di verità e la persistenza come conseguenza. Resta il caso limite delle due sessioni aperte sulla stessa mappa: qui l'unica risposta onesta è decidere in anticipo chi vince, invece di scoprirlo dopo, quando una piantina è già stata sovrascritta.

Ordini in tempo reale con Firestore e l'avviso sonoro per lo staff

Il banco del bar è un piano bagnato dove chi prepara caffè e panini lavora con le mani occupate, senza uno schermo davanti. Un'interfaccia che richiede di controllare ogni tanto se sono arrivati ordini fallisce proprio nel momento in cui conta, cioè quando c'è coda. Per questo gli ordini arrivano su un ascoltatore in tempo reale di Firestore: la lista si aggiorna da sola, senza ricaricare e senza interrogare il server a intervalli.

L'avviso sonoro completa il meccanismo ed è la parte che viene sottovalutata. Senza suono, il tempo reale serve solo a chi sta guardando. Con il suono, il personale può occuparsi d'altro e reagire quando serve. Tecnicamente resta un punto delicato: i browser bloccano la riproduzione audio finché l'utente non ha interagito con la pagina, quindi lo sblocco va agganciato a un gesto esplicito all'apertura del turno. Vanno considerati anche lo schermo che si spegne e il dispositivo che entra in risparmio energetico, altrimenti l'avviso arriva puntualmente in ritardo.

La consegna alla postazione chiude il cerchio aperto dalla mappa. L'ordine porta con sé il codice della prenotazione, che è legato a una postazione con coordinate note sulla piantina. Chi consegna non deve chiedere dove si trova il cliente, e il cliente non deve descrivere la propria posizione. È il vantaggio concreto di aver messo la mappa alla base del modello, invece di averla aggiunta come schermata accessoria.