Una console di prenotazioni per un operatore balneare multi-sede. Nessun backend richiesto.

Sovrapprenotazioni che nessuno poteva impedire.

Gestire più sedi balneari su un foglio di calcolo condiviso non è un problema di workflow. È un problema di coerenza dei dati travestito da problema di workflow. Due gestori che aprono lo stesso foglio nello stesso momento, scorrono fino allo stesso slot e premono salva — uno dei due vince sempre, e l'altro non sa mai di aver perso. L'operatore offriva omaggi a ospiti scontenti due o tre volte a settimana proprio per questo.

I fornitori di PMS che avevano valutato richiedevano tutti un server on-premise, una licenza per postazione e un onboarding di tre mesi. Niente di tutto questo si adattava a un piccolo operatore con personale stagionale, senza funzione IT e con una forte preferenza per non possedere infrastruttura. Il brief era chiaro: vogliamo qualcosa che i nostri gestori possano aprire in un browser, e vogliamo che non si rompa.

Una console di prenotazioni multi-struttura, con sincronizzazione della disponibilità senza polling.

La console ha dato a ogni sede una griglia di prenotazione in tempo reale — arrivi, partenze, disponibilità per slot, occupazione per data. Un gestore in una struttura poteva vedere le modifiche concorrenti da un'altra struttura nel momento in cui avvenivano, senza ricaricare la pagina. Prenotare, modificare e annullare una prenotazione aggiornavano tutti immediatamente lo stato condiviso. Ogni sessione aperta vedeva ogni modifica nel momento in cui atterrava.

Sotto la console: Firestore per i dati delle prenotazioni, Realtime Database per il livello di sincronizzazione della disponibilità, Firebase Auth per la gestione delle sessioni e Firebase Hosting per la SPA statica. Nessun server Node. Nessun processo Express da riavviare. Nessuna pipeline di deployment oltre a un singolo comando CLI.

La superficie analitica girava accanto a quella operativa: dati demografici degli ospiti, grafici di tendenza delle prenotazioni tramite Highcharts e una vista di previsione dei ricavi attinta dalle stesse collezioni Firestore che la griglia di prenotazione già leggeva. La generazione integrata di fatture (jsPDF) e l'esportazione CSV/XLSX gestivano il workflow di fine mese del proprietario senza uno strumento separato. Tre mesi e mezzo dal primo commit alla produzione.

F · 01Sincronizzazione della disponibilità in tempo reale

Firestore + Realtime Database inviano aggiornamenti a ogni sessione aperta nel momento in cui una prenotazione cambia. Niente polling. Nessun refresh.

F · 02Cruscotto multi-struttura

Un'unica console abbraccia tutte le sedi. Ogni struttura ha la propria griglia; il proprietario vede il quadro completo in un'unica scheda.

F · 03Livello di sessione Firebase Auth

Firebase Auth gestisce le sessioni per gli utenti proprietario, gestore e personale. Nessun server di autenticazione personalizzato, nessuna tabella di permessi da mantenere. Controlli di ruolo a livello applicativo regolano le superfici.

F · 04Generazione di fatture

Conferme di prenotazione e fatture prodotte lato client con jsPDF e inviate via email direttamente — nessuno strumento di fatturazione separato.

F · 05Importazione / esportazione di massa

Importazione CSV e XLSX per il caricamento di massa stagionale. Esportazione per il commercialista del proprietario a fine mese. Entrambe girano nel browser.

F · 06Analitiche

Dati demografici degli ospiti, tendenze delle prenotazioni e una vista di previsione dei ricavi costruite su Highcharts, che leggono le stesse collezioni Firestore della griglia di prenotazione.

La scelta solo-Firebase, e perché è sopravvissuta alla produzione.

I tentativi di prenotazione concorrenti sullo stesso slot — due gestori che prenotano l'ultima sdraio del pomeriggio — erano esattamente il guasto che l'operatore continuava a pagare. La soluzione non era il locking lato scrittura; era la verità lato lettura. I listener in tempo reale di Firestore facevano sì che ogni sessione aperta su ogni dispositivo vedesse una prenotazione nell'istante in cui veniva scritta. Una volta che uno slot era occupato, la schermata di ogni gestore lo mostrava. Il fallimento di coordinamento del foglio di calcolo — due persone che lavorano su viste obsolete della stessa riga — non poteva accadere, perché nessuno lavorava su una vista obsoleta.

La decisione di rinunciare del tutto a un server backend non era una scorciatoia per tagliare i costi. Era l'architettura giusta per i vincoli di questo operatore. Non c'era un team DevOps a fare da babysitter a un processo Node, nessuna reperibilità da affidarci e nessuna tolleranza per un server che va giù un sabato di agosto. I servizi gestiti da Firebase portano la garanzia di disponibilità; noi portiamo la logica applicativa. Il confine è pulito.

Firebase Auth ha gestito le sessioni senza un server di autenticazione personalizzato. Il supporto multilingua per una base di ospiti internazionale girava tramite ngx-translate. Il bundle statico veniva distribuito su Firebase Hosting in meno di due minuti. Il costo mensile totale dell'infrastruttura è rimasto entro il piano gratuito di Firebase per i primi sei mesi di produzione.

Zero doppie prenotazioni. Il conto dell'infrastruttura è rimasto entro il piano gratuito.

Il problema delle sovrapprenotazioni si è fermato. Nei primi dodici mesi di operatività, l'operatore ha registrato zero prenotazioni in conflitto sullo stesso slot. Il foglio di calcolo è rimasto aperto per una settimana dopo il lancio, come ripiego che nessuno ha usato.

Il sistema è andato live su tre strutture simultaneamente. La proprietaria ha condotto da sé la formazione del personale, in un solo pomeriggio, perché la console era abbastanza semplice da spiegare in un'unica sessione. Il turnover del personale stagionale — l'altra ragione per cui il foglio di calcolo era stato così fragile — ha smesso di essere un rischio per l'integrità dei dati una volta che lo stato è vissuto nel database, non nel file locale di qualcuno. Le nuove assunzioni stagionali ricevevano un invito Firebase Auth e la stessa console che usavano tutti gli altri.

Il prodotto gira senza un server backend dal 2019. L'operatore non ci ha mai aperto una segnalazione di reperibilità.