Un'app per una pizza di classe: Stripe, allergie e GDPR in una prima elementare

Il progetto più delicato che ho spedito quest'anno non è il SaaS fintech, non è il trading assistito, non è l'orchestratore di agenti. È il sito per la pizza di fine anno di una classe prima elementare.

Una classe intera, una trentina di famiglie. Una pizzeria a Parma. Un mercoledì di giugno, ore 19:15. E una quantità di requisiti non funzionali che manco un bando pubblico.

Il brief (tre giorni alla chiusura delle iscrizioni)

Il brief di partenza chiedeva: iscrizione famiglie senza login, una persona che registra tutta la famiglia, dati dei bambini con allergie, chi paga cosa, e una cassa che incassi esattamente le quote. Consegna: ieri, o quasi — fra l'apertura del progetto e la chiusura delle iscrizioni c'erano tre giorni. Poi, nella chiacchierata di scoping, il perimetro si è allargato da solo: la bevanda di ogni adulto, e la disposizione dei tavoli.

Un agente e io abbiamo tirato su l'app in pochi giorni: Next.js, database, pagamenti, email. Fin qui, ordinaria amministrazione da vibe coding. Le cose interessanti — quelle per cui questo post esiste — sono tre.

1. Il gross-up, ovvero: chi paga le commissioni della pizza?

Il prezzo era 28 € netti ad adulto, 15 € a bambino. Ma se incassi con Stripe, Stripe si prende la sua parte, e la cassa comune della classe si ritrova corta di qualche decina di centesimi a transazione. Moltiplicato per una trentina di famiglie, è una pizza intera che sparisce.

Soluzione da manuale di pricing, applicata alla gita scolastica: gross-up trasparente. Il sistema calcola la commissione — l'1,5% più 25 centesimi, arrotondata per eccesso — e la mostra come riga separata: per un adulto fanno 28 € di pizza, 0,69 € di "commissioni di pagamento", 28,69 € di totale. Il prezzo della pizza resta 28 €, tondo, e la fee ha la sua riga col suo nome. Nessuno deve fidarsi sulla parola: basta leggere.

2. Le allergie, ovvero: il GDPR non va in gita

Le allergie dei bambini sono dati sanitari: articolo 9, categoria particolare, quelli per cui il regolamento europeo non scherza. E quindi: consenso esplicito separato, accesso ristretto, niente allegri export in un foglio condiviso col mondo.

Ma il pezzo che difendo di più è un altro: il sunset. Il progetto è nato con la data di morte scritta nel repository: due settimane dopo l'evento, cancellazione hard di tutti i dati personali. Non "li teniamo che non si sa mai". Cancellati. La feature più sottovalutata del software è la fine.

3. Il vincolo del vicino di bevanda

Dallo scoping è uscito un requisito che nessun product manager avrebbe mai avuto il coraggio di scrivere: i posti a tavola dovevano rispettare la regola "vicino di stessa bevanda" — chi ha scelto Prosecco accanto a chi ha scelto Prosecco, il fronte Spritz compattato altrove. Una geopolitica delle bollicine, messa a verbale con la serenità di chi ordina un caffè.

L'abbiamo implementata. Selezione del posto self-service post-pagamento, con vincolo. Funziona. È probabilmente il constraint di database più assurdo della mia carriera, e l'ho scritto per una cena di bambini di sei anni.

Il conto della serva

• Giorni di codice: 5, con dentro una notte di agenti che ha chiuso 36 compiti su 37
• Consensi per le allergie: uno a parte, separato da tutto il resto
• Reminder automatici programmati: 2
• Giorni tra la cena e la cancellazione dei dati: 14
• Ricavo per lo sviluppatore: 0 €, più una pizza

E qui la chiusa sincera, come da tradizione di famiglia: i progetti pro-bono sono il laboratorio migliore che esista. Nessun cliente pagante ti mette alla prova come una trentina di famiglie con bambini allergici e opinioni sul Prosecco. Se il vostro stack regge la prima elementare, regge quasi tutto.

La seconda, non so.