# Un posto solo dove si vede chi gioca e quando

> Piattaforma per il padel: campi, partite e portafoglio, con gli aggiornamenti che arrivano da soli senza ricaricare la pagina.

**Enneci Agency** — Tenuta del Barone di Montemurlo di Nicolò Coppi. Via Piemonte 4/40, 59100 Prato (PO), Italia.
Contatti: ciao@enneciagency.it · +39 379 2885434 (anche WhatsApp) · https://www.enneciagency.it
Zona servita: Prato e provincia, Firenze e Pistoia, e in tutta la Toscana.

## Scheda

- Cliente: GoPadel
- Settore: Sport
- Tipo di lavoro: Piattaforma web
- Anno: 2026
- Sito online: https://gopadel.it
- Tecnologie: Next.js, React, PostgreSQL, Drizzle, Stripe, Swift, Kotlin
- Pagina: https://www.enneciagency.it/progetti/gopadel/

## Risultati

- **3** — piattaforme dallo stesso progetto
- **SSE** — aggiornamenti spinti dal server
- **0** — servizi esterni per il tempo reale
- **Stripe** — portafoglio e pagamenti

Nel padel il problema non è prenotare un campo: è trovare le persone con cui giocare. Le partite si formano e si disfano nel giro di un'ora, e ogni informazione vecchia di dieci minuti è una partita persa.

## Informazioni che invecchiano in pochi minuti

Un posto libero in una partita vale finché qualcuno non lo prende. Se l'elenco si aggiorna solo quando l'utente ricarica, due persone prenotano lo stesso posto e qualcuno resta fuori — con una telefonata di scuse da fare.

La soluzione più comune è aggiungere un servizio esterno per il tempo reale. Funziona, ma aggiunge un fornitore, un costo e un altro pezzo che può rompersi.

## Il tempo reale ce l'ha già il database

Gli aggiornamenti passano da PostgreSQL: quando un dato cambia, il database avvisa l'applicazione con `LISTEN`/`NOTIFY`, e l'applicazione lo spinge ai browser collegati con un flusso di eventi. Nessun servizio in più, nessuna coda esterna.

È una scelta che funziona bene alla scala di un circolo o di una rete di circoli: meno pezzi da tenere in piedi, e il dato in tempo reale nasce dalla stessa fonte che lo conserva.

## Cosa comprende

- **Campi e prenotazioni** — Disponibilità, fasce orarie e prenotazione, con lo stato che si aggiorna da solo.
- **Partite aperte** — Chi cerca giocatori pubblica la partita, chi cerca una partita la trova e si aggiunge.
- **Portafoglio** — Credito e pagamenti gestiti con Stripe, per chiudere la prenotazione senza contanti.
- **Accesso e archiviazione** — Autenticazione ospitata in proprio e archiviazione dei file su storage a oggetti.

## Un progetto solo che produce anche le app native

Quattrocento sorgenti TypeScript per il web, trentuno migrazioni di database, e accanto una cartella `native` con il codice Swift e Kotlin: le app per iOS e Android nascono dallo stesso progetto e parlano con la stessa API, invece di essere due lavori separati da tenere allineati a mano.

Le migrazioni numerate sono il registro di come la struttura dei dati è cambiata nel tempo: trentuno passaggi, ognuno reversibile. Su una piattaforma di prenotazioni, dove i dati storici delle partite servono per le statistiche, poter far evolvere il database senza perdere niente è un requisito, non un lusso.

C'è anche una cartella `design` con il sistema visivo e una `vision` con la direzione del prodotto: il progetto è scritto per essere ripreso, non solo per funzionare.

## Meno pezzi, meno cose che si rompono

La piattaforma tiene insieme campi, partite e pagamenti su un impianto snello: un database che fa anche da canale per il tempo reale, autenticazione ospitata in proprio e nessun servizio di terze parti per gli aggiornamenti. Le app per iOS e Android nascono dallo stesso progetto.
