Sprint qualità: correggere i bug silenziosi che portano alla disinstallazione
Un promemoria che scompare senza preavviso, un'email che non arriva mai, un errore fantasma all'avvio: questi bug non fanno notizia in un changelog, ma distruggono la fiducia dei tuoi utenti. In una giornata di sprint di qualità, ho corretto quattro problemi silenziosi in TAMSIV — il mio gestore di attività vocale per Android — e l'esperienza quotidiana è cambiata radicalmente.
Punti chiave da ricordare:
- I bug silenziosi (promemoria eliminati, email mute, errori flash) causano più disinstallazioni che crash visibili.
- Attivare push ED email di default per i promemoria elimina il 90% dei ticket "non sono stato notificato".
- Uno sprint di qualità senza nuove funzionalità è l'investimento più redditizio per la fidelizzazione degli utenti.
- La traduzione completa di ogni funzionalità (qui i badge in 6 lingue) è un segnale di rispetto verso gli utenti internazionali.
Perché uno sprint di qualità è più importante di una nuova funzionalità?
Quando sviluppi un'app da solo, la tentazione è costante: aggiungere funzionalità. Un nuovo filtro qui, un'integrazione là. È gratificante, si mostra facilmente in screenshot, fa un bel commit.
Ma la realtà è che gli utenti non disinstallano un'app perché manca una funzionalità. Disinstallano perché un promemoria non ha funzionato. Perché un'email non è mai arrivata. Perché un errore incomprensibile è apparso all'avvio.
Secondo uno studio di UserTesting, l'88% degli utenti non torna mai dopo una brutta esperienza. E i bug silenziosi — quelli che non fanno crashare l'app ma che erodono la fiducia — sono i più pericolosi. Non ricevi un rapporto di crash. L'utente non segnala nulla. Se ne va, e basta.
È per questo che ho deciso di dedicare un'intera giornata a uno sprint di qualità al 100%. Nessuna nuova funzionalità. Nessun refactoring ambizioso. Solo quattro correzioni chirurgiche che, messe insieme, cambiano davvero l'esperienza di TAMSIV quotidianamente.
Come possono i promemoria validi scomparire in silenzio?
Lo scenario: crei un'attività con tre promemoria — uno tra 10 minuti, uno domani mattina, uno venerdì. Solo che il primo promemoria è già nel passato (ci hai messo troppo tempo a convalidare). TAMSIV mostrava un avviso: "Questo promemoria è nel passato". Fin qui, logico.
Il problema? Chiudendo questo avviso, tutti i promemoria venivano eliminati. I due promemoria futuri, perfettamente validi, se ne andavano con esso. Una pulizia un po' troppo zelante nel codice di validazione.
Questo tipo di bug è particolarmente insidioso. L'utente non sa nemmeno che i suoi promemoria sono scomparsi. Aspetta la notifica di domani mattina... che non arriverà mai. E incolperà l'app — giustamente.
La correzione tecnica
La soluzione è stata quella di separare chiaramente i promemoria passati da quelli futuri nella logica di validazione. Concretamente:
- Filtro temporale: solo i promemoria la cui data è anteriore a
Date.now()sono contrassegnati come scaduti. - Avviso mirato: il messaggio di avviso riguarda solo i promemoria effettivamente nel passato, con il loro numero esatto.
- Conservazione garantita: i promemoria futuri rimangono intatti, qualunque cosa l'utente faccia con l'avviso.
- Fusi orari: ne ho approfittato per rafforzare la gestione dei fusi orari nella validazione — un caso limite che avevo sottovalutato.
Il sistema di promemoria e ricorrenze è un pilastro di TAMSIV. Un bug qui, anche minimo, ha un impatto sproporzionato sulla fiducia dell'utente.
Perché le email di promemoria non arrivavano mai?
TAMSIV supporta due canali di notifica per i promemoria: il push (notifica sul telefono) e l'email. In teoria. In pratica, quando un utente creava un promemoria, solo il canale push era attivo di default. L'email? Disattivata. Silenziosamente.
Se non andavi a spuntare manualmente "email" nelle impostazioni del promemoria, non ricevevi mai nulla nella tua casella di posta. Nessun errore, nessun messaggio — solo il silenzio. E per un utente che non consulta sistematicamente il suo telefono, è un promemoria completamente mancato.
Qual è il default giusto per i canali di notifica?
La domanda sembra banale, ma non lo è. Come raccomanda il Nielsen Norman Group nelle sue ricerche sui valori predefiniti, il default deve corrispondere a ciò che la maggior parte degli utenti si aspetta. E la maggior parte si aspetta di essere notificata — tramite tutti i canali disponibili.
Ora, entrambi i canali sono attivi di default. Ricevi un push e un'email. Se vuoi disattivare uno dei due, è sempre possibile, ma il comportamento predefinito è quello che tutti si aspettano. È il principio del sane default — un concetto centrale nella progettazione di applicazioni di produttività.
Da dove viene questo errore "Invalid Refresh Token" all'avvio?
Questo è il tipo di bug che non rompe nulla ma mina la fiducia. Apri l'app dopo qualche ora di inattività, e per una frazione di secondo, un errore "Invalid Refresh Token" lampeggia sullo schermo. Poi tutto funziona normalmente.
Immagina: apri TAMSIV al mattino per vedere le tue attività del giorno, e la prima cosa che vedi è un errore. Non sai cosa significa. Non sai se i tuoi dati sono al sicuro. Non sai se l'app funziona correttamente. Anche se tutto è perfettamente OK in realtà, l'impressione è disastrosa.
L'analisi tecnica del problema
All'avvio a freddo, Supabase Auth tentava di aggiornare il token di autenticazione. Se il token era scaduto (dopo qualche ora di inattività), l'SDK sollevava un errore prima che il meccanismo di riconnessione automatica avesse il tempo di fare il suo lavoro.
L'errore risaliva all'UI quando non aveva alcuna ragione di esserci — la riconnessione finiva sempre per avere successo. È un pattern classico nelle app che utilizzano token JWT con refresh automatico: la prima chiamata fallisce, il refresh si attiva, la seconda chiamata ha successo.
La correzione intercetta questo errore specifico (AuthApiError con il codice invalid_refresh_token) al livello giusto e lo rimuove dalla visualizzazione. L'aggiornamento della sessione continua a funzionare esattamente come prima, ma l'utente non vede più un messaggio ansiogeno che non lo riguarda.
Questo tipo di gestione degli errori è critico per qualsiasi app che utilizzi l'autenticazione Supabase. L'SDK fa bene il suo lavoro — bisogna solo evitare di esporre i suoi errori intermedi all'utente.
Come tradurre un sistema di gamification in 6 lingue?
TAMSIV è disponibile in francese, inglese, tedesco, spagnolo, italiano e portoghese. Il sistema di gamification — livelli, badge, streak — fa parte delle funzionalità che gli utenti scoprono progressivamente. Solo che la guida esplicativa dei badge esisteva solo in francese e inglese.
È un problema più sottile di quanto sembri. Un utente di lingua tedesca che scopre il sistema di badge e si imbatte in un testo in francese o inglese sentirà immediatamente che questa parte dell'app non è finita. È un segnale negativo molto forte, soprattutto quando il resto dell'interfaccia è correttamente tradotto.
Il processo di internazionalizzazione dei badge
I 10 badge di TAMSIV hanno ciascuno un nome, una descrizione e delle condizioni di sblocco. Questo significa 30 stringhe di testo da tradurre in 4 lingue aggiuntive (tedesco, spagnolo, italiano, portoghese). Il sistema di internazionalizzazione in 6 lingue che ho implementato gestisce questo con una pipeline di traduzione automatica tramite OpenRouter, seguita da una revisione manuale per i termini di gamification.
Non è una correzione spettacolare, ma è il tipo di dettaglio che fa sentire un utente lusofono o germanofono a casa nell'app. E come spiega CSA Research, il 76% dei consumatori preferisce acquistare prodotti nella propria lingua.
Qual è l'impatto reale di queste correzioni sulla fidelizzazione?
Queste quattro correzioni rappresentano una giornata di lavoro. Nessuna avrebbe fatto un titolo di changelog entusiasmante. Ma insieme, eliminano attriti reali:
- Promemoria persi: nessun promemoria valido scompare più a seguito di un avviso su un promemoria scaduto.
- Email mancate: entrambi i canali di notifica sono attivi di default, nessuna sorpresa.
- Errore all'avvio: il messaggio "Invalid Refresh Token" non viene più visualizzato.
- Gamification tradotta: i 10 badge sono disponibili nelle 6 lingue supportate.
In termini di fidelizzazione, ciascuno di questi bug era un punto di attrito invisibile. L'utente non segnala "la tua email di promemoria non è arrivata" — si dice semplicemente che l'app non funziona e la disinstalla. Secondo Adjust, il tasso di fidelizzazione medio di un'app a J30 è del 6%. Ogni attrito eliminato spinge questo numero verso l'alto.
Come organizzare uno sprint di qualità quando si è uno sviluppatore solo?
Essere uno sviluppatore solo su un progetto come TAMSIV significa che nessuno pianificherà uno sprint di qualità al tuo posto. Ecco il metodo che utilizzo:
- Utilizzare la propria app quotidianamente — il dogfooding è la migliore fonte di bug. Ogni irritazione annotata in un memo vocale (con TAMSIV, ovviamente).
- Dare priorità in base all'impatto sull'utente — un bug che colpisce il 100% degli utenti ad ogni avvio ha la precedenza su un bug che colpisce il 2% dei casi.
- Limitare lo scope — una giornata, massimo 4 correzioni. Nessun refactoring tentatore lungo il percorso.
- Testare su dispositivi reali — i 12 beta-tester sono lì per questo. Un bug riprodotto su 3 dispositivi diversi è un vero bug.
Lo sprint zero-feature che ho fatto la settimana successiva ha confermato questo approccio: i feedback dei beta-tester erano molto migliori dopo queste correzioni silenziose che dopo l'aggiunta di nuove funzionalità.
Domande frequenti
Quanto tempo ci vuole per uno sprint di qualità efficace?
Una giornata concentrata è sufficiente per 3-5 correzioni mirate. L'importante è non mescolarlo con lo sviluppo di funzionalità — il contesto mentale è diverso. Raccomando uno sprint di qualità ogni 2 settimane per un progetto in fase di lancio.
Come rilevare i bug silenziosi quando non ci sono crash report?
Il dogfooding quotidiano è il metodo numero uno. Usa la tua app come un utente normale, non come uno sviluppatore. Strumenti come Firebase Analytics aiutano anche a rilevare pattern anomali (sessioni molto brevi, funzionalità mai utilizzate).
Perché attivare push ED email di default piuttosto che lasciare che l'utente scelga?
Perché la maggior parte degli utenti non cambia mai le impostazioni predefinite (ricerche del Nielsen Norman Group). L'opt-out è più rispettoso dell'opt-in per le notifiche di promemoria — l'utente ha esplicitamente chiesto di essere ricordato, si aspetta di ricevere la notifica su tutti i canali disponibili.
L'errore "Invalid Refresh Token" è pericoloso per i dati?
No, assolutamente no. È un errore intermedio normale nel flusso di aggiornamento del token JWT. Supabase Auth gestisce questo automaticamente — il token scaduto viene sostituito da uno nuovo in background. Il problema era solo la visualizzazione di questo errore tecnico all'utente.
Come gestire la traduzione dei termini di gamification (badge, livelli)?
Utilizzo una pipeline di traduzione automatica tramite OpenRouter, seguita da una revisione per i termini specifici del gaming. Alcuni termini come "streak" o "badge" sono spesso mantenuti in inglese anche nelle versioni localizzate, perché sono universalmente compresi dagli utenti di app mobili.