La promessa dei 5 minuti e i 90 secondi d'attesa: la latenza è design

In breve. Zeno promette 5 minuti al giorno di micro-azioni, ma all'avvio /session/start impiegava 65-90 secondi in produzione con il client in timeout a 60: l'utente restava fermo su «Quasi pronto…» mentre 17 chiamate LLM andavano buttate. La latenza non è un dettaglio tecnico: è la prima cosa che l'utente impara del tuo prodotto.

Questo articolo parla di scelte di design, non di risultati: non ho dati su retention o soddisfazione, quindi non ne troverai. Zeno è il coach AI che ho raccontato in Zeno: micro-azioni quotidiane di 5 minuti; del lancio sullo store ho già raccontato i tre rifiuti dell'App Store.

I 65-90 secondi di /session/start

Dai log Railway di produzione, il 13 aprile 2026: /session/start impiegava 65-90 secondi, con il timeout del client a 60 (2ca8efe). L'utente restava fermo su «Quasi pronto…» mentre il client aveva già smesso di aspettare: quasi un terzo dei 5 minuti promessi bruciato prima di cominciare, con un messaggio che prometteva un «quasi» senza orizzonte.

Le 17 chiamate buttate

Nello stesso giro, 17 chiamate LLM buttate (93127d5). La latenza si paga due volte: l'utente che aspetta e le chiamate che partono per un avvio che il client ha già abbandonato. Ogni secondo sopra il timeout non è solo attesa — è lavoro pagato per nessuno.

L'onboarding che promette 5 minuti

L'onboarding offre 2-3, 5 o 10 minuti con 5 preselezionato (mobile/src/screens/OnboardingScreen.tsx:914-924); il backend ripiega su 3 (cold_start_handler.py); CLAUDE.md parla di micro-flussi da 3-7 minuti. E il rebrand dice «Il tuo coach AI, 5 min/giorno» (30e558d, 3 aprile). La promessa è coerente ovunque — 5 minuti — tranne dove conta di più: nei primi 90 secondi, dove l'utente decide se crederci.

La regola: la latenza è design

Tre fatti, una sola regola: misura in produzione, poi prometti solo ciò che l'avvio mantiene. Se /session/start impiega 65-90 secondi, o ridisegni l'avvio o alzi il timeout sopra la realtà — ma non puoi promettere 5 minuti fluidi con un avvio da minuto e mezzo. La latenza è la prima riga del contratto con l'utente, anche se non la scrivi da nessuna parte.

Fatti e limiti

FACT. Il 13 aprile 2026 /session/start impiegava 65-90 secondi in produzione (log Railway) con timeout client a 60; utente fermo su «Quasi pronto…» (2ca8efe).

FACT. Nello stesso giro, 17 chiamate LLM buttate (93127d5).

FACT. L'onboarding offre 2-3, 5 o 10 minuti con 5 preselezionato (OnboardingScreen.tsx:914-924); backend ripiega su 3 (cold_start_handler.py); micro-flussi 3-7 minuti (CLAUDE.md); rebrand «5 min/giorno» (30e558d, 3 aprile).

INTERPRETATION. La latenza è la prima cosa che l'utente impara del prodotto: è la mia tesi di design dopo questo lancio, non un dato misurato.

INTERPRETATION. Ogni secondo sopra il timeout è lavoro pagato per nessuno: è la mia lettura dei 65-90 secondi contro i 60 del client.

Limiti: tre fatti da un solo lancio, non una statistica. Non ho dati d'uso, retention, download o soddisfazione: questo pezzo regge sul design e sui log, non sui risultati utenti.

Domande frequenti

Perché 90 secondi di attesa sono un problema di design?

Perché la promessa è 5 minuti: quasi un terzo bruciato prima di cominciare, con un «Quasi pronto…» senza orizzonte. L'utente impara subito se crederti o no.

Cosa sono le chiamate buttate?

Chiamate LLM partite per un avvio che il client aveva già abbandonato: 17 in un giro solo. Sopra il timeout, paghi lavoro che nessuno vedrà mai.

Come si fissa un avvio troppo lento?

Misurando in produzione e promettendo solo ciò che l'avvio mantiene: o ridisegni lo start, o alzi il timeout sopra la realtà. La latenza è la prima riga del contratto.