Nuovo articolo
Da un form di prenotazione a un gestionale completo in un fine settimana: calendario, drag-and-drop, Firebase Auth con MFA, Firestore in tempo reale e Cloud Functions.
Giovedì la call che riscrive i requisiti, venerdì la richiesta, lunedì la consegna. Come è nato il gestionale dei trattamenti Shiseido per l'ospitalità Mastercard alla Mostra del Cinema.
A inizio luglio 2026 il progetto era un form di prenotazione: l'ospite sceglie l'orario del trattamento, un backend minimo tiene il conto per fascia e per utente. L'ultimo giovedì del mese una call con il cliente finale lo trasforma in un gestionale completo per la segreteria, da consegnare il lunedì. Questa è la storia di come è nato Beauty Sessions e di cosa ci ha insegnato sul software su misura in tempi stretti.
Il contesto: ospiti in gruppi, quattro trattamenti, un form già pronto
Al Venice Film Festival 2026 Mastercard è main sponsor e accoglie i propri ospiti con un programma di ospitalità che include trattamenti Shiseido: Hair & Make-up, Facial Massage, Hair & Beard e il Facial Massage della linea barber. Gli ospiti arrivano in gruppi, ogni gruppo ha le sue giornate e i suoi orari, e ognuno prenota il trattamento dentro fasce orarie con posti limitati.
Il committente è Competitive Mind, l'agenzia per cui GiacApp lavora sul progetto; il cliente finale è Mastercard. La parte rivolta agli ospiti esisteva già: la landing del Venice Film Festival 2026 vive dentro G-Events, la nostra piattaforma di gestione eventi, e il form pubblico di prenotazione era pronto. Gli ospiti erano già nel database dell'evento, con i loro gruppi, e il form scriveva le prenotazioni tramite le stesse Cloud Functions e lo stesso Firestore che usiamo per il resto della piattaforma.
Mancava solo un backend leggero per la segreteria: vedere chi ha prenotato cosa, per fascia e per persona. Poi è arrivato giovedì.
Il giovedì che ha cambiato il progetto
Il 30 luglio Competitive Mind presenta la piattaforma a Mastercard. Dalla call emerge una lista di richieste che riscrive il perimetro del progetto. Non più un form con un riepilogo, ma uno strumento con cui la segreteria lavora davvero durante l'evento:
- gestione avanzata delle prenotazioni con un calendario grafico;
- spostamento delle prenotazioni trascinandole da un orario all'altro;
- ricerca nel database degli ospiti;
- creazione di nuovi utenti: gli ospiti registrati erano già in G-Events, ma la segreteria voleva gestire anche ospiti aggiuntivi non registrati;
- creazione di appuntamenti cliccando direttamente sullo slot;
- storico delle prenotazioni;
- accessi multipli per gli operatori;
- gestione della durata dei trattamenti;
- possibilità di cambiare gli slot disponibili durante le giornate e durante i red carpet;
- messaggistica WhatsApp e SMS per contattare gli ospiti e ricevere le loro richieste.
La richiesta formale arriva venerdì 31 luglio nel pomeriggio. La scadenza non è negoziabile: il martedì successivo il cliente deve inviare le DEM che aprono le prenotazioni dal form, e la segreteria deve poter lavorare su ciò che arriva da lunedì. Tre giorni, fine settimana compreso.
Tre giorni: da venerdì pomeriggio a lunedì mattina
Il repository racconta quei giorni meglio di qualsiasi ricostruzione. Il primo commit è di venerdì 31 luglio e già alla versione 0.0.9 l'applicazione funziona: calendario, ricerca degli ospiti, creazione delle prenotazioni, drag-and-drop tra gli slot ed esportazione CSV. In giornata si aggiungono le capienze per fascia, la creazione di nuovi ospiti (separati dagli utenti registrati, nel documento guestUsers) e le conferme per spostamenti, cancellazioni e creazioni.
Sabato 1 agosto è il giorno delle fondamenta: migrazione del progetto da Angular 14 ad Angular 22, ottimizzazioni di cache e prestazioni del backend. Domenica 2 agosto è il giorno dell'integrazione: Firebase Authentication con verifica in due passaggi (MFA via email o telefono) e ruoli operatore, sincronizzazione in tempo reale con Firestore, scritture esclusivamente tramite Cloud Functions, email di conferma, drag-and-drop anche da touch e penna, branding Mastercard VFF 2026.
Cosa c'era nella versione consegnata lunedì
- calendario mensile, vista a tre giorni e agenda giornaliera, con filtri per servizio e gruppo e vista aggregata dei gruppi che si sovrappongono;
- ricerca degli ospiti per nome, cognome, email e telefono;
- creazione di prenotazioni dallo slot, più prenotazioni per ospite con blocco delle sovrapposizioni;
- creazione di ospiti aggiuntivi non registrati;
- spostamento con drag-and-drop verso slot compatibili per servizio, gruppo e orario;
- capienza generale per fascia, gestita come soglia con conferma esplicita oltre il limite;
- eliminazione con conferma ed email di annullamento;
- accesso operatori con Firebase Auth e MFA, aggiornamenti in tempo reale tra postazioni;
- esportazione CSV dell'agenda.
Lunedì 3 agosto la prima versione è online e la segreteria può iniziare a lavorare. Martedì partono le DEM. Lo stesso lunedì compare nel repository la prima interfaccia per le conversazioni WhatsApp: la lista del giovedì non era esaurita, ma il blocco necessario per aprire le prenotazioni c'era tutto.
Come è stato possibile
Tre giorni non bastano a costruire un gestionale da zero. Sono bastati perché gran parte del lavoro era già stata fatta prima e perché il metodo era diverso.
La piattaforma era in casa. G-Events aveva già il database degli ospiti con i gruppi, le Cloud Functions che scrivevano le prenotazioni dal form pubblico, l'autenticazione Firebase con MFA e i ruoli operatore, l'infrastruttura per email, WhatsApp e SMS. Beauty Sessions si è agganciato allo stesso Firestore e alle stesse Functions e ha aggiunto l'interfaccia della segreteria.
Le scritture passano solo dalle Functions. Il form pubblico e la segreteria lavorano sugli stessi dati nello stesso momento: un ospite prenota dal telefono mentre un operatore sposta un appuntamento dal desk. Per questo il frontend non scrive mai direttamente su Firestore. Ogni creazione, spostamento o cancellazione passa da una Cloud Function con transazioni, contatori e audit, e il modello dati è stato pensato fin dall'inizio per l'uso concorrente. Il frontend ascolta Firestore con listener in tempo reale: ogni postazione vede le modifiche delle altre senza ricaricare.
Una persona, con agenti AI come assistenti. Il progetto è stato sviluppato da una sola persona, su Angular 22 standalone con signal e computed, TypeScript e RxJS. Gli agenti AI sono stati usati come assistenti per aumentare la velocità di produzione, non come sostituti: per la codifica Claude Opus con livello di ragionamento high o extra high, per la progettazione e i piani di lavoro, in alcuni casi, Claude Fable 5 a livello medium, high o extra high. Architettura, contratto Firestore e Functions, separazione tra letture in tempo reale e scritture transazionali, regole di lint che impongono i vincoli architetturali e revisione del codice sono rimasti lavoro nostro. Come spieghiamo nell'articolo sui rischi del vibe coding, non è la stessa cosa di chiedere all'AI di fare un gestionale: l'assistente accelera, la tenuta viene dalle scelte fatte prima e dal controllo di chi sviluppa.
Sul carico di lavoro abbiamo solo stime interne, non misure: circa cinque giornate effettive dichiarate, distribuite su cinque settimane, e una stima basata sulle distanze tra i commit che dà tra 48 e 75 ore. Non serve un confronto in giornate/uomo per capire cosa significhi. Un perimetro come questo, con autenticazione a più fattori, agenda in tempo reale, scritture transazionali, messaggistica su due canali, storico e manuale, non si fa in cinque giornate: né un senior da solo né un team di tre persone ci arriverebbero con il metodo tradizionale. Si parla di settimane intere di lavoro, più verosimilmente di uno o due mesi.
Le settimane successive
La versione di lunedì era il minimo per aprire le prenotazioni. Tra il 3 e il 7 agosto sono arrivati i pezzi rimasti della lista: le conversazioni WhatsApp in tempo reale con avvio di nuove chat, la gestione dedicata di Hair & Make-up con le giornate red carpet, la configurazione delle fasce orarie per gruppo e giornata, gli SMS via gateway, la prima versione del manuale e l'esportazione CSV completa.
Il red carpet spiega meglio di tutto perché servisse una configurazione dinamica. Nei giorni di red carpet l'Hair & Make-up si svolge in camera, negli altri giorni in Beauty Room, e le fasce di quella giornata vanno riviste. Il form pubblico legge la stessa configurazione della segreteria, quindi cambiare una giornata red carpet ha effetto immediato anche sulle prenotazioni in arrivo dagli ospiti.
Tra il 10 e il 28 agosto ci sono stati tre interventi puntuali. Poi, tra il 29 agosto e il 2 settembre, il lavoro più profondo: refactoring del modello dati con prenotazioni per documento, configurazione dedicata e audit; fasce con durate diverse per gruppo (30, 45, 60 o 90 minuti); nota per prenotazione; sezione Storico con l'audit per persona; contatore di caratteri e parti per gli SMS; e la selezione multipla delle fasce.
La selezione multipla è il tipo di funzione che non compare in una lista di requisiti iniziale e che, dopo una settimana di uso, nessuno vuole più togliere.
Il 5 e il 6 settembre si chiude con il centro notifiche (la campanella che conta i messaggi non letti di WhatsApp e SMS anche fuori dalle rispettive sezioni), l'avviso di nuova versione per gli operatori e il manuale esportabile in PDF. Il 9 settembre la versione 0.0.176 passa la verifica pre-produzione. Al 6 settembre il progetto contava 216 test automatici e circa 26.000 righe tra codice e documentazione.
Un capitolo a parte merita il manuale operativo, integrato nell'applicazione con indice, ricerca e 36 schermate reali del gestionale. Il punto non è averlo scritto, ma averlo tenuto aggiornato: prima di ogni deploy, quando le funzionalità cambiavano, l'aggiornamento di testi e schermate è stato gestito in modo semi-automatico con Claude Opus 5, con poche indicazioni da parte nostra e una revisione finale prima del rilascio. Su un progetto arrivato alla versione 0.0.176 in cinque settimane, un manuale che si aggiorna con il codice è la differenza tra documentazione utile e documentazione che nessuno legge.
Durante l'evento il sistema ha funzionato senza problemi.
Cosa abbiamo imparato
Il software su misura in tempi stretti funziona se la piattaforma esiste già. Tre giorni sono stati possibili perché database ospiti, autenticazione, messaggistica e Functions erano già lì. Se il progetto fosse partito da zero, la domanda giusta non sarebbe stata "quanto velocemente" ma "cosa tagliamo".
Le decisioni architetturali vanno prese il primo giorno, non l'ultimo. Scritture solo via Functions, listener in tempo reale, capienza come soglia: sono scelte fatte venerdì che hanno retto tutto quello che è arrivato dopo, refactoring del modello dati compreso.
Gli agenti AI aumentano la velocità, non sostituiscono chi sviluppa. Hanno dato una mano su codice, test e manuale, come assistenti. Cosa costruire, in che ordine, con quali vincoli, la revisione del codice e le decisioni sono rimaste lavoro umano.
Quando ha senso, quindi, un software su misura con una scadenza di giorni? Quando l'evento ha regole operative che nessuno strumento generico modella (gruppi, red carpet, trattamenti in camera, capienze da forzare con criterio), quando esiste già una base su cui costruire e quando chi sviluppa può prendere decisioni architetturali senza passare da tre riunioni. Ne abbiamo parlato più in generale nell'articolo su G-Events e i software di gestione eventi.
I dettagli tecnici del progetto, lo stack completo e le funzionalità finali sono nella scheda progetto di Beauty Sessions. Per capire su cosa si appoggia, il punto di partenza è G-Events.