La Fossa Events
La piattaforma di un festival sportivo di paese che organizzo anch'io — un gestionale per lo staff e un sito pubblico dove i giocatori si iscrivono e prenotano il campo.
Scrivimi- Stato
- In produzione · 2 edizioni gestite
- Ruolo
- Unico sviluppatore, co-organizzatore
- Periodo
- giu 2026 – oggi
- Piattaforma
- Web · desktop, tablet e telefono
- Stack
- Next.js, React, TypeScript, Supabase, Postgres, TanStack Query

Problema
La Fossa Events organizza eventi sportivi a Santa Maria La Fossa, un paese vicino a Caserta: La Fossa Games, una settimana di tornei d'estate, e FantaFossa, un torneo di calcetto in cui le squadre si costruiscono all'asta, come al fantacalcio. Sono uno degli organizzatori.
Un'edizione vuol dire tornei, squadre, la cassa del bar, sponsor, fatture e un campo che si prenota tutto l'anno. La prima La Fossa Games ha avuto 350 giocatori, oltre 1.000 presenze e 58 sponsor locali. Serve un solo sistema di cui lo staff si fida durante una serata di partite, e una faccia pubblica che ci porta dentro le richieste. Costruisco il software che uso io stesso.
Cosa ho costruito
- Un gestionale per tutta l'edizione: tornei con gironi, calendario, risultati e classifiche; squadre e giocatori; sponsor, richieste di iscrizione, documenti e fatturazione.
- Cassa e magazzino del bar, usati da tablet al banco, con le chiusure di cassa a fine serata e la stampa tramite un print agent separato.
- Viste a schermo intero per la sala: sorteggi e asta del FantaFossa proiettati su uno schermo, senza la navigazione del gestionale.
- Ruoli e permessi per owner, admin, cassieri, staff e ospiti in sola lettura, definiti per modulo e azione e applicati dalla row-level security.
- Il sito pubblico: ogni format e ogni edizione passata, le classifiche dei tornei pubblici e le richieste di iscrizione a un torneo o di prenotazione del campo, che arrivano nel gestionale in attesa finché lo staff non le conferma.



Decisioni
Il gestionale gestisce un'edizione alla volta, per costruzione.
Il festival prepara sempre una sola edizione, quindi nel database non esiste un ID evento. L'edizione corrente è una tabella di una sola riga che non può contenerne una seconda, e query e permessi restano semplici. Passare a più eventi richiederebbe una nuova decisione e una migrazione, non una chiave esterna aggiunta per sbaglio. Prima di una nuova edizione il gestionale fa un backup ripristinabile, poi azzera.
Il bar e il campo sopravvivono al festival; i tornei no.
Ho diviso i dati in due cicli di vita. Prenotazioni del campo, cassa e magazzino lavorano tutto l'anno e sopravvivono all'azzeramento; tornei, squadre, sponsor e conti del festival appartengono all'edizione e se ne vanno con lei. Nessuna tabella permanente può puntare a una che viene azzerata, e l'incasso del bar durante il festival si ricava dalle chiusure di cassa nelle sue date invece di copiarlo nei suoi conti.
Il sito pubblico tiene i suoi racconti nel codice, non nel database.
Il gestionale azzera l'edizione ogni anno, ma il sito deve conservare l'archivio di tutte quelle passate. Quindi i contenuti editoriali sono versionati con il sito, e dal database arriva solo lo stato live, cioè le fasce libere del campo e i tornei aperti. Ogni modifica a un testo richiede un rilascio; in cambio un azzeramento non può cancellare l'archivio e non c'è un CMS da gestire.
Qualità
- 514asserzioni pgTAP sulle regole del database, in 39 suite
- 640+test Vitest nelle due app
- 0chiavi segrete nel sito pubblico — legge solo da funzioni del database che restituiscono dati pubblici
Come ci ho lavorato
Spec → ticket → agenti di coding, ogni decisione rivista e presa da me. 26 ADR nelle due app, un glossario condiviso e una regola per gli agenti, documentare solo ciò che il codice fa davvero.
Stato e link
- Stato
- In produzione · 2 edizioni gestite
- Sito pubblico
- lafossagames.com(si apre in una nuova scheda)
- Codice
- Su richiesta