Primo video demo e sprint qualità: 7 correzioni critiche

Dopo 6 mesi di sviluppo e oltre 700 commit, TAMSIV aveva tutto: una pipeline vocale funzionale, un sistema di gamification, gruppi collaborativi, 6 lingue supportate. Ma mancava qualcosa di essenziale — un video. Perché un'app vocale non si descrive. Si mostra. Questa settimana, ho girato il primo video demo di TAMSIV e, parallelamente, ho completato uno sprint di qualità che ha corretto 7 problemi critici.

Punti chiave da ricordare:
- Un video demo è indispensabile per un'app vocale — "parla e l'IA capisce" non è sufficiente, bisogna vedere il microfono che si attiva e l'attività che si crea.
- Uno sprint di qualità (0 funzionalità, 7 correzioni) ha un impatto pari a un mese di sviluppo quando mira alle frizioni quotidiane.
- Il pulsante di stop di un dittafono deve funzionare al 100% — anche l'1% di fallimento distrugge la fiducia.
- Svuotare sempre la cache singleton al logout su dispositivo condiviso — una fuga di dati tra sessioni è un bug di sicurezza critico.

Perché un video demo è indispensabile per un'app vocale?

Per 6 mesi, TAMSIV è esistito in testo e screenshot. Sul sito web, negli articoli del blog, sulle schede del Play Store. Ma un'app vocale ha un problema fondamentale di comunicazione: l'interazione principale è invisibile.

Puoi scrivere "parla, l'IA capisce e organizza" quante volte vuoi. Finché il visitatore non ha visto il microfono che si attiva, la trascrizione in tempo reale, l'attività che si crea da sola nella cartella giusta — non capisce veramente cosa fa l'app.

Come spiega Wyzowl nel suo rapporto 2026 sul video marketing, il 96% dei consumatori guarda un video esplicativo prima di acquistare un prodotto o scaricare un'app. Per un'app vocale, questa cifra è probabilmente ancora più alta — il concetto stesso richiede una dimostrazione visiva.

Il video è ora visibile su YouTube e direttamente integrato nell'hero del sito tamsiv.com. Il visitatore vede immediatamente come funziona TAMSIV, senza dover scaricare l'app o leggere una documentazione.

Come integrare un video nell'hero di un sito Next.js?

L'integrazione nel sito Next.js era ovvia — ma con alcune limitazioni tecniche:

• Performance: nessun autoplay, nessun preload del file video completo. Un embed YouTube con facciata (immagine placeholder + pulsante play) per evitare di caricare l'iframe al primo rendering.
• Mobile responsive: il rapporto 16:9 deve adattarsi senza bande nere o overflow su tutti gli schermi.
• SEO: tag VideoObject in JSON-LD affinché Google indicizzi il video e lo mostri nei risultati arricchiti.

Il risultato: l'hero del sito mostra ora un'anteprima del video con un pulsante play. Un clic carica l'embed YouTube. È il miglior compromesso tra impatto visivo e performance — il Largest Contentful Paint non è influenzato.

Perché uno sprint 0 feature cambia tutto per la retention?

Parallelamente al video, ho dedicato una settimana a uno sprint di qualità al 100%. Nessuna nuova funzionalità — solo polish, affidabilità e correzioni silenziose che fanno la differenza ogni giorno. 7 commit. 0 nuove funzionalità.

È controintuitivo quando sei uno sviluppatore singolo. Hai una lista di funzionalità da aggiungere lunga un braccio. Ogni giorno senza nuove funzionalità ti sembra perso. Ma è esattamente il contrario: ogni micro-frizione eliminata, ogni bug silenzioso corretto, è un utente in più che non disinstalla dopo 3 giorni.

Questo sprint segue lo sprint di qualità precedente che aveva già corretto i promemoria e le email. Questa volta, le correzioni toccano il cuore dell'app.

Come rendere un pulsante di stop affidabile al 100% su un dittafono vocale?

Il bug più frustrante dell'app: a volte, il pulsante "stop" non rispondeva. Il microfono continuava a registrare, l'utente doveva forzare l'arresto. Un incubo UX assoluto.

La causa? Un problema di timing tra l'inizializzazione dello STT nativo (riconoscimento vocale del telefono) e lo stato React. Quando l'utente premeva stop durante una finestra di pochi millisecondi in cui lo STT era in transizione tra due stati, il callback di stop veniva semplicemente ignorato.

La soluzione tecnica in 3 punti

• Modalità "standby" per lo STT nativo: invece di inizializzare completamente lo STT ad ogni pressione del pulsante microfono, rimane in stato di veglia attiva. Risultato: avvio 2 volte più veloce, nessuna attesa di callback.
• Pulsante stop assoluto: indipendentemente dallo stato interno dello STT (inizializzazione, ascolto, elaborazione), il pulsante stop attiva un arresto forzato. Nessuna condizione, nessun "aspetta che il callback ritorni".
• Cleanup di sicurezza: un timeout di 30 secondi pulisce automaticamente qualsiasi stato residuo — ispirato al pattern utilizzato nell'AudioPlayerService.

Questa correzione è forse la più importante di tutto lo sprint. La pipeline vocale è il cuore di TAMSIV. Se il pulsante di registrazione non è affidabile al 100%, nient'altro ha importanza.

Come far capire le fasce di date a un'IA vocale?

Prima, chiedere "cosa ho questa settimana?" all'IA funzionava solo per un giorno. Il system prompt limitava le richieste a una singola data. Un problema tipico della progettazione di prompt per l'IA conversazionale.

La soluzione ha richiesto due modifiche:

1. Estensione del system prompt: aggiunta di esempi di fasce di date ("da lunedì a venerdì", "i prossimi 3 giorni", "questa settimana") nelle istruzioni dell'IA.
2. Modifica del function calling: lo strumento create_calendar_event accetta ora un parametro end_date opzionale per le richieste che riguardano una fascia.

Ora, l'assistente comprende le fasce: "da lunedì a venerdì", "i prossimi 3 giorni", "questa settimana". È un cambiamento sottile ma che trasforma l'uso dell'agenda quotidianamente.

Perché passare da SDXL a HiDream per la generazione di immagini IA?

Le immagini di copertina delle cartelle in TAMSIV sono generate da IA. Usavamo SDXL 0.9, che aveva due problemi principali: capiva male i prompt complessi (testo misto, istruzioni ignorate) e la qualità era inconsistente.

Il passaggio a HiDream-I1-Fast tramite Runware ha cambiato tutto. Migliore comprensione del prompt, risultati più coerenti e un costo di ~0.003 EUR per immagine. È lo stesso modello che uso per le immagini IA inline nel dittafono — la coerenza visiva è mantenuta in tutta l'app.

Come rilevare una fuga di dati tra sessioni utente?

Un bug critico scoperto e corretto durante questo sprint: su un dispositivo condiviso, i dati dell'utente precedente potevano apparire brevemente durante un cambio di account. La cache singleton non veniva svuotata al logout.

È un bug di sicurezza di classe critica. Anche se l'esposizione è breve (poche centinaia di millisecondi), un utente può vedere le attività, i memo o gli eventi di un altro utente. In un'app di produttività che gestisce dati personali, è inaccettabile.

La correzione: pulizia completa al logout

La soluzione è semplice in teoria ma richiede rigore: ogni servizio singleton (ContentCacheService, CalendarService, GamificationService) ha ricevuto un metodo clearAll() chiamato sistematicamente ad ogni disconnessione. Il sistema di sicurezza di TAMSIV include ora una verifica che tutte le cache siano vuote prima di inizializzare una nuova sessione.

Qual è l'impatto combinato del video e dello sprint di qualità?

Il video e lo sprint di qualità sono due facce della stessa medaglia:

• Il video è la vetrina — rende il progetto tangibile per chi non ha mai toccato l'app. È lo strumento di acquisizione.
• Lo sprint di qualità sono le fondamenta — fa la differenza tra un'app che si prova e un'app che si tiene. È lo strumento di retention.

I due si completano perfettamente. Attirare utenti con un bel video per poi perderli a causa di un pulsante di stop difettoso sarebbe un disastro. Al contrario, un'app perfettamente rifinita che nessuno conosce non serve a nulla.

È esattamente la logica che dettaglio nell'articolo sul percorso dei 650+ commit: ogni fase del progetto alterna tra funzionalità visibili e polish invisibile.

Quali lezioni trarre per uno sviluppatore singolo che lancia la sua app?

Dopo questa settimana, ecco cosa ho imparato:

1. Gira il tuo video presto. Non aspettare che l'app sia "perfetta". Un video di 2 minuti con un prodotto funzionale vale più di mesi di descrizioni testuali.
2. Pianifica i tuoi sprint di qualità. Blocca una settimana su due senza alcuna funzionalità. Lo sprint zero-feature è diventato un rituale per me.
3. Il pulsante principale deve essere infallibile. Per TAMSIV, è il pulsante del microfono. Per te, è il pulsante che rappresenta la tua proposta di valore principale. Se fallisce una volta, perdi la fiducia.
4. Verifica la sicurezza dei singleton al logout. Se usi cache in memoria in un'app mobile, assicurati che vengano pulite ad ogni cambio di sessione.

Domande frequenti

Quanto tempo ci vuole per girare un video demo di un'app mobile?

Per TAMSIV, il video di 2 minuti ha richiesto circa mezza giornata: preparazione dello scenario, 3 riprese, montaggio di base. Non è necessario uno studio professionale — una buona illuminazione e uno schermo ben inquadrato sono sufficienti. L'importante è mostrare l'interazione reale, non un mockup.

È necessario uno sprint di qualità prima o dopo il lancio?

Entrambi. Prima del lancio, uno sprint di qualità mira alle frizioni più visibili (come il pulsante di stop). Dopo il lancio, i feedback degli utenti guidano le priorità. Raccomando uno sprint di qualità ogni 2 settimane durante la fase beta.

La modalità standby dello STT consuma più batteria?

No, la modalità standby mantiene il modulo STT in memoria ma non avvia l'ascolto attivo. Il consumo della batteria è trascurabile rispetto alla registrazione attiva. È paragonabile a mantenere una connessione SpeechRecognizer inizializzata senza avviarla.

Come evitare fughe di dati tra sessioni su dispositivo condiviso?

Tre regole: (1) ogni servizio singleton deve avere un metodo clearAll(), (2) questo metodo viene chiamato nel gestore di logout, (3) un test automatizzato verifica che tutte le cache siano vuote dopo il logout. È basilare ma spesso dimenticato nelle architetture basate su singleton.

HiDream-I1-Fast è migliore di SDXL per la generazione di immagini di app?

Per le immagini di copertina e le illustrazioni contestuali, sì. HiDream comprende meglio i prompt complessi e produce risultati più coerenti. SDXL rimane rilevante per il fotorealismo puro, ma per immagini funzionali in un'app mobile, HiDream è una scelta migliore a un costo simile (~0.003 EUR/immagine).