Case study di architettura / posa
posa: quaranta telefoni, un solo insieme di regole.
posa è una fotocamera usa e getta condivisa per ogni evento. Gli ospiti entrano da un link o da un QR, hanno pochi scatti a testa e nessuno vede le foto finché il rullino non si sviluppa, all'ora scelta dall'host. Sembra un'app semplice. Il lavoro vero è stato fare in modo che le regole valgano per tutti nello stesso momento: decine di telefoni che scattano insieme, alcuni senza campo, altri con una versione precedente dell'app.
- Il mio contributo
- Revisione di Supabase, riprogettazione delle schermate, test e tutta la parte web
- Proprietà
- Venture condivisa con Giulio
- Forma
- App Expo per iOS e Android, sito Next.js, Supabase con funzioni Postgres, pg_cron ed Edge Function
- Tempi
- Avviato da Giulio il 10 settembre 2026, io dal 12
- Stato
- Online su posa-app.com · app in arrivo sugli store
Il prodotto
Una usa e getta sul tavolo di un matrimonio funziona per tre motivi: la pellicola è poca, quindi ogni scatto conta; nessuno vede niente subito; e alla fine c'è un momento in cui le foto si guardano insieme. posa prova a tenere tutte e tre le cose su un telefono.
La categoria esiste già. POV, Lense, Scene e una dozzina di cloni vendono lo stesso modello: QR, limite di foto, reveal il giorno dopo. Il nostro argomento non poteva essere “usa e getta condivisa fatta bene”, che dicono tutti. Abbiamo puntato su due cose che si possono dimostrare: il reveal come rituale, con un'ora e un nome, e una scadenza dichiarata, dopo la quale le foto vengono tolte davvero.
Il problema delle regole
In un'app così quasi ogni regola ha un valore economico. I posti per gli ospiti e gli scatti a testa sono ciò che l'host ha pagato. La chiusura dell'evento e il reveal sono la promessa del prodotto. Sono regole che devono valere su tutti i telefoni degli ospiti insieme, anche su quelli senza rete, con una versione precedente dell'app o chiusi al momento del reveal. Un solo punto li vede tutti: il server.
Il caso più sottile è l'ultimo posto libero. Due ospiti che aprono l'invito nello stesso istante leggono entrambi “un posto disponibile” ed entrano entrambi, a meno che il conteggio non avvenga su una riga bloccata, nella stessa transazione dell'ingresso.
Dove far vivere le regole
Quando sono entrato nel progetto, Giulio aveva già costruito l'app e messo le regole principali nel database. La mia revisione è partita da qui: confrontare quella scelta con le alternative, per sicurezza, costo operativo per due persone e velocità, e poi estenderla a tutto ciò che mancava.
Una festa senza campo
Le feste si fanno in cantine, in campagna, in sale piene di gente. Uno scatto non deve mai andare perso perché manca la rete. Ogni foto viene spostata subito in una coda salvata sul telefono, che riprova con attese crescenti e riparte quando torna il segnale o l'app torna in primo piano. Uno scatto è rifiutato solo se lo dice il server, per esempio perché gli scatti sono finiti.
Il server accetta una foto scattata prima della fine dell'evento e arrivata anche dopo, entro un periodo di tolleranza, così chi era senza campo la carica tornando a casa. Il percorso del file è fissato al momento dello scatto e la funzione che lo registra è idempotente: se la risposta si perde e l'app riprova, non si consuma un secondo scatto. Il contatore in fotocamera mostra il residuo del server meno le foto ancora in coda, per non promettere pellicola già usata.
Anche il peso delle foto era una decisione di costo. Ogni scatto sale due volte: l'originale ridotto a 2560 pixel sul telefono e una copia a 1280 pixel per griglia e visore. Il file si scrive una volta ma si legge a ogni apertura di ogni ospite, e servire a tutti un originale da 3 MB avrebbe deciso il margine del prodotto.
La privacy come funzione del prodotto
Una usa e getta a una festa inquadra persone che non hanno accettato niente. Per questo il consenso è una riga nel database, con la versione del testo mostrato. Non è decorativo: senza quella riga le funzioni che registrano foto e dediche vocali rifiutano la richiesta, e la policy dello storage non lascia nemmeno entrare il file.
Anche il reveal è una promessa. Finché il rullino non si sviluppa, le foto restano velate. Le dediche vocali non si possono sfocare, quindi per loro è il server stesso a rifiutarsi di consegnare il file prima del momento giusto.
La scadenza riguarda il file, non il ricordo. Il rullino continua a dire chi c'era e quanti scatti ha fatto, con cornici vuote al posto delle stampe. Sette giorni prima l'host riceve un avviso, e un job orario cancella prima i file e poi segna le righe, così un errore a metà si ripara da solo al giro successivo. Anche la cancellazione dell'account è una richiesta registrata che sopravvive all'utente e viene ripresa fino a cinque volte se non si completa subito.
L'unico principio che non mantenevamo
Il primo principio scritto nella documentazione di prodotto era che l'ospite non deve installare niente per partecipare. Per i primi giorni è stato falso: la fotocamera richiedeva l'app. È un dettaglio che decide se un rullino ha dodici foto o quaranta, perché molti ospiti non scaricano un'app per una sera.
Ho costruito io tutta la parte web. Ora l'invito si apre nel browser, con una fotocamera web che passa dalle stesse funzioni del database e quindi rispetta gli stessi limiti. Se l'ospite decide di installare l'app, un codice monouso trasferisce i suoi scatti nell'app, senza perdere niente. Lo stesso sito ospita la landing, le pagine su privacy e supporto e la richiesta di cancellazione dell'account.
Cosa abbiamo tolto
Le scene assegnate erano il punto più forte della nostra strategia: invece di quaranta foto della torta, ogni ospite riceveva inquadrature da riempire. Le avevo aggiunte io, e le ho tolte cinque giorni dopo.
Rendevano la fotocamera un compito da svolgere. In più avevano un difetto: con lo sviluppo immediato, alcuni ospiti non riuscivano proprio a scattare. La migrazione che le rimuove lascia accettare l'argomento alle versioni dell'app già installate e lo ignora, perché nessun telefono in giro deve rompersi per una scelta di prodotto.
Cosa farei diversamente
Avrei provato le scene a una festa vera prima di costruirci intorno il posizionamento. Cinque giorni sono pochi da perdere, ma una funzione che doveva distinguerci dai concorrenti non avrebbe dovuto nascere solo da un documento di strategia.
Avrei progettato l'ingresso dal browser fin dal primo giorno. Era il primo principio del prodotto, ed è arrivato per ultimo.
Avrei fissato prima il modello di prezzo. Limiti e scatti inclusi sono già nel codice e controllati in tre punti, ma i prezzi veri sono ancora da decidere, e sono loro a dire se il prodotto sta in piedi.
Hai un'app in cui ogni regola vale dei soldi?
Mi occupo di prodotti in cui limiti, pagamenti e privacy devono valere per tutti gli utenti nello stesso momento, senza aggiungere infrastruttura che un team piccolo non può mantenere.
hello@robertodrago.dev