Open Questions
Documento living — aggiornato ad ogni sprint. Ultima revisione: Marzo 2026
Registro centralizzato di tutte le domande aperte sul prodotto, architettura e business che richiedono una decisione prima di procedere con l’implementazione.
Ogni sezione include: la domanda, il contesto, le opzioni, e lo stato decisionale.
Legenda stati
| Stato | Significato |
|---|---|
| 🔴 Bloccante | Blocca implementazione attiva |
| 🟡 Importante | Va deciso nel prossimo sprint |
| 🟢 Non urgente | Può aspettare dati reali |
| ✅ Deciso | Risposta approvata dal founder |
Prodotto
P1 — Visibilità attività tra amici tier 0 (Conoscente)
Stato: 🟡 Importante
Tra due utenti che si sono aggiunti come amici ma non hanno mai partecipato a eventi insieme (tier 0 = Conoscente), cosa possono vedere l’uno dell’altro?
Opzioni:
- A) Visibilità completa — stesso di tier 1+ (semplicità UX)
- B) Visibilità ridotta — solo nome ed eventi pubblici, no “Cosa fanno gli amici”
- C) Nessuna visibilità attività finché non tier 1+
Considerazioni: La privacy è un valore di Flow. Un utente potrebbe accettare una richiesta di amicizia da un conoscente senza volergli mostrare tutti i suoi piani del weekend. Opzione B sembra il giusto compromesso.
P2 — Notifica di upgrade tier connessione
Stato: 🟢 Non urgente
Quando due amici passano da tier 1 a tier 2 (o 2→3), vale la pena notificarlo? “Sei diventato Crew con Marco!”
Opzioni:
- A) Notifica push in-app
- B) Solo un easter egg visivo nel profilo (es. animazione sul badge tier)
- C) Nessuna notifica — il tier è lì, chi lo trova lo trova
Considerazioni: Le notifiche di milestone sono un classico engagement hook. Rischio: sentirsi “tracciati”. Preferibile opzione B — discovery passiva, non notifica proattiva.
P3 — Decay del tier di connessione
Stato: 🟢 Non urgente
Se due amici non escono insieme da 6+ mesi, il tier di connessione scende?
Opzioni:
- A) Storico permanente — il tier non scende mai
- B) Decay soft — tier visualizzato come “dormiente” ma non azzerato
- C) Decay reale — il tier scende di 1 ogni X mesi di inattività
Considerazioni: Dipende da che storia vuole raccontare Flow. Se il focus è “legami costruiti nel tempo”, il tier storico ha senso. Se il focus è “relazioni attive ora”, il decay ha senso. Decisione fondamentale per l’identità del prodotto.
P4 — Follow per organizzatori verificati
Stato: 🟡 Importante (blocca roadmap B2B)
I profili verificati (locali, organizzatori, PR ufficiali) devono avere un meccanismo di follow separato?
Contesto: Il modello amici-only esclude il follow asimmetrico tra persone fisiche. Ma i locali e gli organizzatori sono entità di contenuto, non persone.
Opzioni:
- A) Follow separato — “Segui [Nome Locale]” non influenza la social graph amici
- B) Nessun follow — gli utenti vengono notificati di eventi di organizzatori solo se ci hanno partecipato prima (discovery organica)
- C) Subscribe/Newsletter — modello più opt-in, meno social
Considerazioni: L’opzione A è la più naturale (simile a Spotify: seguire un artista ≠ amicizia). Va definito cosa succede quando segui un organizzatore (feed? notifiche? entrambi?).
P5 — Karma pubblico o privato
Stato: 🟡 Importante
Il punteggio karma è visibile nel profilo pubblico (ad altri utenti) o solo all’interessato?
Opzioni:
- A) Pubblico — visibile a tutti (badge + punteggio)
- B) Semi-pubblico — il badge (es. stella) visibile, il numero solo agli amici
- C) Privato — solo l’utente vede il suo karma
- D) Visibile agli amici — solo chi ti ha in rubrica vede il tuo karma
Considerazioni: Karma pubblico aumenta la trasparenza (utile per chi organizza eventi e vuole valutare partecipanti), ma crea dinamiche di giudizio sociale potenzialmente tossiche. Opzione B è un buon equilibrio.
P6 — Soglie XP per livelli: ottimizzare con dati reali
Stato: 🟢 Non urgente (ma da mettere in agenda)
Le soglie attuali (livello = floor(sqrt(xp/100)) + 1) sono arbitrarie. Vanno calibrate una volta che ci sono dati reali di engagement.
Domande specifiche:
- Quanto XP guadagna in media un utente attivo al mese?
- Quanti mesi ci vuole a raggiungere il livello 5? È troppo presto o troppo tardi?
- Il livello massimo teorico (con la formula attuale) ha senso nel tempo?
Azione: Implementare analytics XP prima di lanciare a una base utenti ampia, poi calibrare.
P7 — Commenti agli eventi
Stato: 🟡 Importante
Gli eventi devono avere una sezione commenti?
Contesto: Attualmente non implementati. Molte piattaforme eventi li hanno, ma generano moderazione costosa.
Opzioni:
- A) Commenti pubblici — visibili a tutti, richiedono moderazione
- B) Commenti tra amici — solo chi si conosce può commentarsi sullo stesso evento
- C) Q&A con organizzatore — thread strutturato, non libero
- D) Nessun commento — la conversazione avviene su chat/crew
Considerazioni: Opzione D è la più coerente con la filosofia di Flow (le conversazioni avvengono in ambienti privati, non sotto post pubblici). Potenziale alternativa: solo Q&A con l’organizzatore per domande logistiche.
P8 — Cosa succede a un evento passato?
Stato: 🟢 Non urgente
Dopo che un evento è terminato, rimane visibile nel feed? Come appare? Per quanto tempo?
Domande:
- Gli RSVP rimangono visibili?
- Le recensioni diventano il “documento” dell’evento?
- C’è un archivio eventi? Filtrabile?
- Un evento passato dovrebbe contribuire al tier di connessione degli amici che c’erano?
Azione: Definire lifecycle completo dell’evento (pianificato → attivo → passato → archiviato).
P9 — Guest list aperta vs. a inviti
Stato: 🔴 Bloccante (blocca biglietteria)
Un organizzatore può scegliere di rendere un evento:
- Aperto a tutti
- Solo su invito (organizzatore controlla chi entra)
- Aperto ma con cap di capacità
- Con approvazione manuale (organizzatore approva ogni RSVP)
Questa distinzione impatta radicalmente il modello dati RSVP, le notifiche, e il flusso di acquisto biglietti.
Azione: Decidere il set minimo per MVP biglietteria e implementare.
Architettura
A1 — Event Bus: Redis Streams o Kafka?
Stato: 🔴 Bloccante (blocca workflows async)
L’architettura prevede un event bus per workflow asincroni (notifiche, XP, badge). Non implementato.
Opzioni:
- A) Redis Streams — già presente nell’infrastruttura (usato per Socket.IO), overhead basso
- B) Kafka — più robusto, consumer groups nativi, ma richiede infrastruttura dedicata
- C) BullMQ su Redis — code di lavoro, non event streaming; più semplice per task queue
Considerazione: Per la scala attuale (MVP/early stage), Redis Streams o BullMQ sono sufficienti. Kafka è over-engineering. Decidere Redis Streams vs. BullMQ in base a se il pattern è “pubblica evento → N consumer” (Streams) o “esegui job → un consumer” (BullMQ).
Riferimento: architecture/architecture-issues.md — Issue #1
A2 — CDC MongoDB → PostgreSQL
Stato: 🟡 Importante
Il servizio eventi usa MongoDB per dati di eventi (flessibilità schema). Il servizio utenti usa Supabase/PostgreSQL. Alcune query necessitano di join tra i due sistemi.
Rischio: Inconsistenza dati. Un evento cancellato in MongoDB potrebbe rimanere in cache PostgreSQL.
Opzioni:
- A) Change Data Capture (Debezium) — robusto, ma complessità operativa alta
- B) Dual-write manuale — ogni write va su entrambi i DB; rischio di split-brain
- C) Eliminare MongoDB — unificare su PostgreSQL con JSONB per campi flessibili
- D) API gateway come unico punto di verità — nessuna sync, query cross-service passano per API calls
Considerazione: Opzione C (unificazione su PostgreSQL) è la soluzione più pulita a lungo termine ma richiede migrazione. Opzione D è pragmatica ma crea accoppiamento tra servizi.
Riferimento: architecture/architecture-issues.md — Issue #4
A3 — Socket.IO: Redis adapter per multi-instance
Stato: 🟡 Importante
Il servizio real-time gira su un’unica istanza (no Redis adapter). Non scalabile orizzontalmente.
Problema: Se si avviano più istanze del realtime service (load balancing), gli eventi non vengono propagati tra le istanze.
Soluzione: @socket.io/redis-adapter — drop-in replacement che usa Redis pub/sub per cross-instance messaging.
Effort: Basso (1-2 giorni), impatto alto. Da fare prima di qualsiasi deploy in produzione con traffico reale.
Riferimento: architecture/architecture-issues.md — Issue #2
A4 — Push notifications: FCM token management
Stato: 🟡 Importante
FCM è integrato come dipendenza ma il token management e il deep link non sono implementati.
Domande specifiche:
- Dove vengono salvati i token FCM? (Supabase
profiles? Tabella dedicata?) - Come gestiamo token scaduti / dispositivi multipli per lo stesso utente?
- Il deep link da notifica push come si mappa sulle route Flutter?
- Come testiamo le notifiche push in sviluppo locale?
Azione: Definire schema device_tokens e implementare registro token + cleanup token scaduti.
A5 — Strategia di test
Stato: 🔴 Bloccante (rischio regressioni in produzione)
Nessuna test suite visibile nel repository. Zero coverage.
Opzioni:
- A) Unit test Dart (flutter_test) — rapidi, ma non testano integrazioni
- B) Integration test Flutter (flutter_driver) — testano flow end-to-end su device/emulatore
- C) Widget test — intermedi, testano singoli widget
- D) Test del backend Node.js (Jest) — API test indipendenti dal mobile
Piano consigliato (priorità):
- Test unit sui notifier Riverpod (logica di stato)
- Test unit sui service layer (API calls mockati)
- Widget test sulle schermate critiche (login, event detail, RSVP flow)
- API test sul backend per endpoint critici
Business & Monetizzazione
B1 — Modello di monetizzazione
Stato: 🟡 Importante (definire prima di crescita)
Come guadagna Flow?
Opzioni non mutuamente esclusive:
- A) Commissione sui biglietti — percentuale su ogni biglietto venduto (standard nel settore: 5-15%)
- B) Abbonamento organizzatori — fee mensile per dashboard analytics, campagne, badge verificato
- C) Boost eventi — gli organizzatori pagano per visibilità premium nel feed
- D) Freemium utenti — feature premium per utenti (es. vedi chi viene agli eventi, filtri avanzati)
- E) Dati aggregati — insights anonimi alla scena locale (locali, PR, turismo)
Considerazione: Il modello A (commissione biglietti) è il più naturale e diretto. Il modello B (abbonamento organizzatori) è più prevedibile come revenue. Combinare A+B è standard nel settore (Eventbrite, Dice).
B2 — Mercati target: solo Italia o internazionale?
Stato: 🟢 Non urgente (ma impatta architettura)
Impatti tecnici se si punta all’internazionale:
- Multi-lingua (già supportato da Flutter, ma i18n non implementato)
- Multi-valuta (biglietteria)
- GDPR vs. altre normative privacy
- Timezone management in date/orari eventi
Azione: Decidere entro fine anno se l’obiettivo è solo Italia o EU/internazionale. Impatta le decisioni di infrastruttura.
B3 — Partnership con locali e promoter
Stato: 🟢 Non urgente
I locali e i promoter sono un canale di distribuzione critico per popolare il feed di eventi. Vanno trattati come partner, non solo come user.
Domande:
- Come si registra un organizzatore? È self-service o manuale (whitelisting)?
- Chi verifica l’identità di un organizzatore (anti-spam)?
- Cosa ricevono gli organizzatori gratis vs. a pagamento?
- Dashboard analytics: quali metriche esponiamo?
UX & Design
U1 — Onboarding: quante informazioni chiedere?
Stato: 🟢 Non urgente
L’onboarding attuale raccoglie informazioni base. Quante ne chiediamo prima di mostrare il feed?
Trade-off: Più dati → migliori raccomandazioni iniziali. Meno dati → meno friction, più utenti completano l’onboarding.
Benchmark: Tinder chiede età, genere, posizione (3 step). Spotify chiede generi musicali (5+ step). Flow probabilmente: città, interessi/vibe, età.
U2 — Dark mode come default?
Stato: 🟡 Importante
L’app attualmente segue il tema del sistema. Per la scena notturna, ha senso impostare dark mode come default?
Opzioni:
- A) Segue sistema (attuale)
- B) Dark mode sempre — forte identità, ma no scelta utente
- C) Dark mode default ma modificabile — buon equilibrio
Considerazione: Una app per la vita notturna dovrebbe presumibilmente essere dark. La dark mode comunica anche “non sei su Facebook”.
U3 — Lingua dell’interfaccia
Stato: 🟡 Importante
L’app è tutta in italiano. Se si punta a mercati non italiani, serve i18n.
Domande:
- Internazionalizzare subito (più costoso ma evita refactoring futuro)?
- Aspettare fino a un secondo mercato concreto?
- Flutter intl package o altra soluzione?
Riferimenti
- Feature tracker:
project/feature-tracker.md - Architettura issues:
architecture/architecture-issues.md - Social connection model:
project/social-connection-model.md - Gamification design:
project/gamification-design.md