Sprint zero feature: 30 commit di polish prima del lancio

La rifinitura è più redditizia delle funzionalità. In 48 ore e 30 commit senza alcuna nuova funzionalità, ho reso la mia app più solida che in sei mesi di aggiunte. Ecco perché uno sprint "zero funzionalità" prima di un lancio è la migliore decisione che uno sviluppatore solitario possa prendere.

Perché fare uno sprint senza funzionalità prima del lancio?

Per sei mesi, ogni giorno di sviluppo aggiungeva qualcosa. Una funzionalità, una schermata, una pipeline, un'integrazione. Il contatore dei commit saliva, i file si accumulavano, e l'app cresceva con oltre 650 commit.

E poi arriva un momento in cui bisogna fermarsi. Non per stanchezza, ma per lucidità. L'app funziona per 12 tester alpha che conoscono i suoi limiti. Ma il grande pubblico non perdona. Secondo uno studio di Apptentive, il 77% degli utenti legge almeno una recensione prima di scaricare un'app. E un solo bug visibile al momento sbagliato, è una recensione a 1 stella.

Questa settimana, ho fatto l'opposto di tutto ciò che avevo fatto finora: 30 commit in 48 ore. Zero funzionalità. Solo rifinitura, correzioni e preparazione per il momento in cui l'app esce dall'alpha ed entra nel mondo reale.

Come correggere 15 bug su una singola schermata di personalizzazione IA?

L'IA di TAMSIV permette agli utenti di presentarsi a voce. Tu premi, racconti la tua vita in 30 secondi, e l'assistente si adatta alla tua personalità. Il problema: la schermata di configurazione aveva 15 bug sottili che i test automatici non rilevavano.

Un pulsante nascosto da un overlay. Un testo troncato su schermi piccoli. Un loop infinito quando l'utente interrompeva l'IA a metà risposta. Il prompt che si resettava dopo ogni modifica. I pulsanti di azione impilati uno sull'altro invece di posizionarsi verticalmente.

Nessuno di questi bug sarebbe stato trovato in un test rapido. Era necessario usare l'app come un vero utente — premere ovunque, interrompere al momento sbagliato, tornare indietro, riprovare. Questo è ciò che il Nielsen Norman Group chiama test di usabilità esplorativo: nessun script, solo un umano che cerca di rompere l'interfaccia.

15 commit per rendere affidabile una singola schermata. Sembra eccessivo. Ma quando è la schermata che definisce come l'IA ti capisce, ogni micro-bug degrada l'intera esperienza.

Qual è la differenza tra "funziona in alpha" e "è pronto per la produzione"?

Il sistema di abbonamenti Free/Pro/Team esisteva da febbraio. Funzionava in alpha. Ma "funzionare in alpha" ed "essere pronto per la produzione" sono due cose molto diverse.

In alpha, 12 tester sanno che è un lavoro in corso. Accettano un wording approssimativo, un design non del tutto definito, limiti sfocati tra i piani. In produzione, ogni ambiguità costa un utente. Secondo ProfitWell, una pagina di prezzi confusa può ridurre le conversioni dal 20 al 40%.

La revisione ha toccato tre aree:

• Il wording: ogni testo è stato riletto per chiarire cosa è gratuito e cosa a pagamento. Niente più formulazioni ambigue.
• Il design della modale alpha: non ha più ragione di esistere in produzione. Eliminata e sostituita da un flusso naturale verso i piani RevenueCat.
• I limiti del piano gratuito: ogni schermata verificata su 3 diverse dimensioni di schermo, ogni testo responsive.

Il tipo di lavoro che non si vede in un changelog, ma che fa la differenza tra un utente che capisce cosa paga e un utente che disinstalla per confusione.

Quali "piccoli dettagli" hanno il maggiore impatto sulla retention?

Tre piccole modifiche hanno trasformato l'esperienza quotidiana dell'app.

Il pulsante stop TTS. Quando l'IA ti risponde a voce alta e vuoi fermarla, prima dovevi abbassare il volume del telefono. Ora basta un toggle. Sembra insignificante, ma è esattamente il tipo di attrito che spinge un utente a disinstallare. Il dittafono è il cuore di TAMSIV — deve essere impeccabile.

Lo scope stretto del LLM. L'IA tendeva a rispondere a domande fuori tema — meteo, cultura generale, filosofia. In produzione, deve rimanere concentrata: attività, memo, eventi. Punto. Un guardrail backend che rifiuta educatamente tutto il resto. Come spiega la guida di prompt engineering di OpenAI, definire limiti chiari al LLM è essenziale per un'esperienza utente coerente.

Il toggle delle immagini generate. Ogni conversazione può generare un'immagine di copertina tramite IA, grazie all'integrazione Runware nel dittafono. Ma costa crediti. Un interruttore nell'header del dittafono permette ora di disattivare la generazione di immagini al volo. Trasparenza e controllo.

Cosa rappresenta il versionCode 30 per uno sviluppatore solitario?

Ogni build Android ha un numero. Siamo alla 30esima. Le 29 precedenti erano alpha — build per 12 tester che accettavano i bug in cambio della primizia. La build 30 è l'ultima prima che chiunque possa scaricare TAMSIV sul Play Store.

È un numero banale. Ma rappresenta il momento in cui "la mia app" diventa "un'app". Dove il codice non è più protetto dal filtro benevolo dei beta-tester. Dove ogni bug è una potenziale recensione a 1 stella.

Per mettere questo in prospettiva: il precedente sprint di qualità aveva già corretto decine di problemi. La build 30 è il culmine di due settimane di intensa rifinitura, non solo di 48 ore. È lo strato finale prima della messa in produzione.

Come decidere quando smettere di aggiungere funzionalità?

La tentazione dello sviluppatore solitario è di aggiungere sempre di più. Una funzionalità ne chiama un'altra. Il backlog non si svuota mai. E più l'app cresce, più ogni aggiunta crea interazioni impreviste con il resto.

Ho applicato una regola semplice: se un bug può essere riscontrato nei primi 5 minuti di utilizzo, ha la priorità su qualsiasi funzionalità del backlog. Questo è ciò che Marty Cagan chiama il "reference customer test" — se il tuo utente di riferimento non può completare il percorso di base senza attriti, nient'altro conta.

Questo sprint mi ha insegnato qualcosa: la rifinitura non è nemica del progresso. È il contrario. Correggere 15 bug su una singola schermata ha reso l'app più solida di qualsiasi nuova funzionalità. Gli utenti non vedono i commit. Vedono un'app che funziona — o che non funziona.

Qual è il workflow di uno sprint di rifinitura in pratica?

Concretamente, ecco come ho organizzato queste 48 ore:

1. Audit per schermata: ho aperto ogni schermata dell'app su 3 dispositivi diversi (piccolo, medio, grande) e ho annotato ogni anomalia visiva o funzionale.
2. Prioritizzazione per impatto: i bug visibili nei primi 5 minuti in alto, i casi limite in basso.
3. Commit atomici: un commit = un fix. Niente commit "tuttofare". Questo permette di fare un rollback chirurgico se un fix rompe qualcos'altro.
4. Test di regressione: dopo ogni fix, riverifica delle schermate adiacenti. Quando tocchi l'architettura di un componente condiviso, l'effetto domino è reale.

Questo workflow non è spettacolare. Non ci sono nuove tecnologie, nessun refactoring eroico. Solo disciplina e tempo speso a usare la propria app come un utente comune.

Perché la rifinitura è più redditizia delle funzionalità per un lancio?

I numeri sono chiari. Sul Play Store, le app con un punteggio inferiore a 4 stelle perdono fino al 50% dei loro potenziali download. E le prime recensioni sono decisive: definiscono la traiettoria dell'app per i mesi successivi.

Aggiungere una funzionalità che impressiona il 10% degli utenti ma che crea un bug per il 5% di essi, è un cattivo compromesso. Al contrario, correggere 30 micro-bug che potenzialmente colpiscono tutti, è un investimento a rendimento garantito.

Questo sprint di rifinitura ha toccato l'intero percorso dell'utente: dall'onboarding alla gestione degli abbonamenti, passando per il cuore dell'app — il dittafono vocale. E la differenza si gioca in questi 30 commit invisibili.

La build 30 è pronta. L'app è più pulita, più stabile, più chiara di quanto non lo sia mai stata. Il prossimo passo è il grande pubblico.