Nel Febbraio 2022 ho finito di scrivere la mia tesi di laurea su Learnn.
86 pagine. Diagrammi di architettura serverless. Il flusso completo di come un video viene caricato, convertito e distribuito su AWS. Lo schema del sistema di checkout con Lambda e SQS. Le tabelle DynamoDB progettate per gestire i progressi di migliaia di utenti. Test di usabilità con 12 utenti, euristiche di Nielsen, t-test e Fisher test.
Il titolo: “Learnn: il ruolo della tecnologia nel design e nello sviluppo di un prodotto.”
L’ho consegnata, mi sono laureato, e l’ho lasciata su una mensola.
Per 4 anni.
La risposta onesta è che ho la tendenza a creare cose e lasciarle sul mio computer. La tesi non è l’unica: ci sono side project, documenti, idee sviluppate a metà che stanno lì e non vedono mai la luce. Ma di questo parleremo in un altro momento.
Nel caso della tesi c’era anche qualcos’altro. Una sensazione che fosse già vecchia dopo pochi mesi. Che qualcuno con più esperienza l’avrebbe letta e ci avrebbe trovato errori. Che le scelte documentate fossero troppo specifiche per interessare a qualcuno al di fuori del contesto di Learnn.
Col tempo ho capito che erano tutte scuse.
Qualche settimana fa l’ho riletta per la prima volta dopo anni. E mi sono reso conto di tre cose.
La prima: i principi che hanno guidato le decisioni architetturali sono ancora validi. Non parlo delle singole tecnologie, ma dell’approccio: scegliere soluzioni semplici proporzionate alla fase del progetto, separare i domini quando serve, accettare tradeoff consapevoli come la ridondanza in cambio di performance. Questi principi funzionano oggi come funzionavano nel 2020.
La seconda: ho visto decine di startup e team ripetere gli stessi errori che sono documentati nella tesi. Partire con un’architettura troppo complessa. Non validare prima di costruire. Usare una metodologia Waterfall a discapito della flessibilità in una fase in cui uscire sul mercato è più importante. Rimandare il rilascio inseguendo la perfezione. Questi pattern si ripetono e avere un caso studio reale che li documenta può essere utile.
La terza: ci sono cose che oggi non rifarei. E queste riflessioni a posteriori sono forse più interessanti della tesi stessa. Ma la tesi non poteva contenerle perché è stata scritta mentre le cose accadevano. Manca la prospettiva di chi guarda indietro con 4 anni di distanza.
Ed è qui, su Omar.log(), che parlerò di queste cose.
La tesi copre l’intero percorso tecnico di Learnn dalla nascita alla fase di stabilizzazione. Non è un post motivazionale e non è una success story — anzi, si chiude documentando che il product-market fit non era ancora stato raggiunto.
Ecco una mappa di cosa trovi, in base a cosa ti interessa:
Se sei un developer o un architect: i capitoli 2.2 e 3.2 sono per te. Il capitolo 2.2 descrive l’intera infrastruttura di streaming: Strapi, Amazon S3, MediaConvert, CloudFront, protocollo HLS con adaptive bitrate. Il capitolo 3.2 entra nel dettaglio del sistema di denormalizzazione dei progressi utente: perché Strapi non bastava più, come abbiamo separato letture e scritture, la struttura delle tre tabelle DynamoDB e il flusso con SQS e Lambda.
Se sei un product manager o un UX designer: i capitoli 2.5 e 3.3 documentano una valutazione di usabilità longitudinale completa. La 2.5 è la valutazione euristica: 6 valutatori, euristiche di Nielsen, 21 problemi trovati, matrice problemi-valutatori, test binomiale per la prioritizzazione. La 3.3 è la valutazione quantitativa: 12 utenti, 3 task, efficacia misurata con Fisher test, efficienza misurata con t-test per campioni dipendenti. Con tutti i numeri: tempi medi, deviazioni standard, p-values.
Se sei un founder o stai validando un’idea: parti dal capitolo 1. Documenta come abbiamo validato Learnn con uno stack MVP a circa €200/mese (WordPress, Mighty Networks, Chargebee, Vimeo), il lancio con 4.500 iscritti, e la decisione di buttare via tutto dopo 90 giorni per ricostruire da zero. Il capitolo 4.1 è dove la tesi si conclude: Learnn aveva 22.000 utenti ma eravamo nel chasm tra early adopters e mercato di massa.
Se ti interessa la metodologia: il capitolo 2.1 documenta il passaggio da Waterfall ad Agile, gli errori di stima della roadmap iniziale, e come il cambio di metodologia ci ha permesso di rilasciare l’app in 45 giorni.
La tesi è stata scritta mentre le cose accadevano. Documenta il processo iniziale: dalla validazione alla prima infrastruttura e alla sua evoluzione. Ma mancano alcune cose che oggi considero fondamentali.
Manca la prospettiva a posteriori. Quali decisioni hanno retto nel tempo e quali no. La struttura di denormalizzazione è ancora in produzione — ma il deploy manuale via SSH di cui si parla nel capitolo 4.3 oggi non esiste più. Nessuna feature esce senza CI/CD, test e review.
Manca il racconto di come si è evoluto il prodotto dopo il punto in cui la tesi si chiude.
Manca la riflessione su come avrei fatto le stesse cose oggi. Nel 2020 non esistevano tool come Mux per lo streaming, Stripe non gestiva le subscription, e sicuramente l’AI non era quella di oggi. Gli strumenti che userei oggi per validare sono cambiati. Se dovessi validare Learnn oggi, farei scelte diverse.
Queste sono le cose che troverai su Omar.log().
Omar.log() non è solo la newsletter della tesi. La serie sulla tesi è il punto di partenza.
Nei prossimi articoli:
Le 5 scelte tecniche che rifarei identiche: cosa ha retto nel tempo e perché.
Le 5 scelte che non rifarei mai più: gli errori, il contesto, cosa farei diversamente.
Come validerei Learnn nel 2026: stesso problema, strumenti diversi.
Dopo la serie sulla tesi, Omar.log() diventa il posto dove scrivo di engineering, product e carriera. Approcci e architetture concrete, strategia di prodotto e casi studio reali, riflessioni sul mio percorso da sviluppatore, e articoli tratti dai miei talk e workshop.
Puoi leggerla e scaricarla qui: omardiop.com/tesi-learnn
86 pagine. Tutto quello che ho raccontato nei post LinkedIn delle ultime settimane, con i diagrammi completi, le matrici, i box plot e il ragionamento dietro ogni decisione.
Non è un documento perfetto. È un documento onesto. Spero che possa esserti utile.
Omar
Se questo articolo ti è stato utile, condividilo con qualcuno a cui potrebbe servire 👇
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.