👋 Ciao, sono Chri. Fractional CTO e questa è Senza Filtri: la newsletter dove condivido il dietro le quinte del mio viaggio da imprenditore (esperienze, cosa ho imparato e tanti errori) alternando a qualche deep dive sui business che mi incuriosiscono.

Aprivo VSCode ogni mattina e non l’avevo pagato nemmeno un euro (e scommetto che valeva anche per te o per il tuo team).

Non è sempre stato così, chi ha qualche anno sul groppone come me se lo ricorda bene il momento in cui l’ambiente di sviluppo te lo dovevi comprare.

Visual studio, con la sua bella licenza, oppure JetBrains con le rate annuali e Sublime Text, con quel popup che ti chiedeva di acquistare la licenza e che tu, bellamente, ignoravi (tipo WinRar).

Poi arriva Microsoft nel 2015 e mette in giro un editor gratuito: veloce, gira su qualsiasi sistema operativo e nel giro di qualche anno si prende tutto il mercato (sì, non era il primo, ma non stiamo a guardare il pelo nell’uovo. Era il primo ad essere esploso di brutto).

Oggi lo usa il 75,9% degli sviluppatori del pianeta secondo l’ultimo sondaggio di Stack Overflow (che tra l’altro RIP). Praticamente tre su quattro. Il secondo in classifica sta a più di quaranta punti di distanza (tipo il Milan con l’Inter 💙🖤)

E qui ovviamente scatta la domanda: ma se è gratis e nessuno lo paga, Microsoft da dove ci guadagna? Te lo dico io.

Regala l’editor, vendi tutto il resto

Se non vende l’editor vende altro sicuramente. Nel 2002 Joel Spolsky, quello di Stack Overflow per intenderci, scrive un pezzo che gira ancora oggi e lo chiama “commoditize your complement”. Rendi una commodity ciò che sta accanto al tuo prodotto.

Ogni prodotto ha dei complementi, cioè cose che compri insieme. Le auto e la benzina. Le patatine e il ketchup. Quando il complemento costa poco, la gente compra più del prodotto principale. Quindi la mossa furba è far crollare il prezzo di quello che ti sta accanto, così cresce la domanda di quello su cui tu fai davvero i soldi.

Microsoft questo giochino lo conosce da sempre, perché lo ha fatto negli anni ‘80 con i PC. Ha spinto perché l’hardware diventasse economico, intercambiabile, una commodity da quattro soldi, e intanto vendeva il sistema operativo che ci girava sopra. Regali il livello di sotto per possedere quello di sopra.

Con VS Code è la stessa identica cosa, solo trent’anni dopo. L’editor è il complemento, lo rendi gratis, onnipresente, lo metti in mano a cinquanta milioni di sviluppatori al mese, e poi vendi quello che ci gira attorno: l’AI, il cloud, l’infrastruttura. L’editor non deve fare una lira, deve solo essere ovunque.

Il trucco nel trucco

C’è un dettaglio che quasi nessuno conosce e che secondo me è la parte più intelligente di tutta la storia.

Quando scarichi “Visual Studio Code” dal sito Microsoft, pensi di scaricare il progetto open source. Ed è qui che casca l’asino. Esistono due cose diverse. C’è “Code – OSS”, il progetto vero open source rilasciato con licenza MIT, quello che chiunque può prendere e modificare. E poi c’è “Visual Studio Code”, il prodotto che scarichi tu, che è la stessa base ma con dentro il marchio Microsoft, la telemetria, il marketplace ufficiale e le estensioni proprietarie che il progetto open non ha.

Detta papale papale:: la parte aperta serve ad attrarre la community, i contributi garantiti e la fiducia degli sviluppatori, mentre la parte chiusa aiuta a tenere il controllo. Sembra tutto open, ma la verità è che può “aprire quella porta” una persona soltanto.

I tre rubinetti

Ok, ma dove finiscono materialmente i soldi? Ci sono tre punti dove l’editor gratis si trasforma in cassa.

Il primo, e il più grosso, è GitHub Copilot. L’AI che ti completa il codice mentre scrivi, integrata dentro l’editor. Parte da 10 dollari al mese e sale. A gennaio 2026 Microsoft ha dichiarato 4,7 milioni di abbonati paganti, in crescita del 75% in un anno. Le stime degli analisti parlano di circa un miliardo di dollari di ricavi annui, anche se il numero ufficiale Microsoft non l’ha mai confermato, quindi prendilo con le pinze. Nadella nel 2024 se n’era uscito dicendo che Copilot da solo era già un business più grande di quanto fosse tutta GitHub quando l’hanno comprata. E GitHub l’avevano pagata sette miliardi e mezzo (mica noccioline)

Il secondo rubinetto è il cloud. Quando smetti di sviluppare sul tuo portatile e passi agli ambienti in cloud, ai container, agli spazi di lavoro remoti, cominci a pagare. GitHub Codespaces è letteralmente VS Code che gira dentro il browser su infrastruttura Azure, e lo paghi a consumo: si parte da 18 centesimi l’ora di macchina, più lo storage. Sembra poco finché non moltiplichi per un team intero che lavora otto ore al giorno.

Il terzo è il vero bomber: il marketplace. Le regole dicono che le estensioni si possono usare solo dentro ai prodotti Microsoft, non per una questione tecnica però, è scritto nero su bianco nei termini di servizio. L’editor lo puoi anche forkare, ma il negozio delle estensioni resta suo.

Qualche numero non torna però

Fin qui sembra andare tutto bene, ma qualcosa non torna.

Nel 2023 il Wall Street Journal tirò fuori che Copilot lo vendevano a 10 dollari al mese, e Microsoft ci perdeva in media più di 20 dollari a utente. Sui power user, quelli che lo martellavano tutto il giorno, arrivava a perderci fino a 80 dollari a testa. Al mese. Vendevano una cosa a dieci e ne spendevano ottanta. L’avrai visto anche tu sui diversi social gente che spendeva un botto in token rispetto alla fee fissa.

Il software tradizionale, una volta scritto, ha un costo marginale che tende a zero: se lo usa un utente o un milione, a te cambia poco. Ma con l’AI cambia tutto, perché più uno la usa, più tu paghi. Il modello “prezzo fisso al mese” si rompe, perché chi la usa tanto finisce per svenarti.

Ed è esattamente per questo che a giugno 2026 GitHub ha cambiato le regole, passando a un modello dove oltre una certa soglia paghi a consumo. Qualcuno si è ritrovato la bolletta che passava da 29 dollari a quasi 750 in un mese, e ovviamente apriti cielo. Ma il punto è che il prezzo si sta spostando dall’abbonamento per posto al consumo di calcolo. Cioè sta diventando il modello del cloud, non quello del software. Tienilo a mente perché ci toccherà da vicino sta cosa prima o poi...

Si è ribaltata la situazione

Questa storia l’ho già raccontata in parte quando ho fatto il deep dive su GitHub.

Il codice di VS Code è aperto, chiunque può prenderlo e costruirci sopra. E indovina cosa hanno fatto in tanti? Hanno preso l’editor gratis di Microsoft e ci hanno costruito i concorrenti diretti di Microsoft.

Cursor è il caso da manuale. È un fork di VS Code pensato attorno all’AI, nato da quattro ragazzi usciti dal MIT, e in poco più di un anno è passato da 100 milioni a 2 miliardi di ricavi ricorrenti. La società B2B più veloce di sempre ad arrivare a quei numeri. A giugno 2026 si parlava di una valutazione intorno ai 60 miliardi. Tutto costruito sulla base regalata da Microsoft. Windsurf, altro fork, stessa storia, finito in mezzo a una guerra di acquisizioni tra OpenAI, Google e chi più ne ha più ne metta.

Microsoft si è ritrovata ad aver armato i suoi stessi rivali. E ha reagito nel modo prevedibile: nell’aprile 2025 ha cominciato a bloccare le sue estensioni proprietarie dentro i fork. Il CEO di Cursor ha confermato che le estensioni Microsoft “non funzionano più” fuori dall’editor ufficiale. È il paradosso del “regala il complemento”: funziona finché il complemento resta un complemento. Nel momento in cui l’editor diventa la piattaforma su cui i tuoi nemici ti attaccano, il regalo ti si ritorce contro.

Ma la verità è che l’editor sta sparendo

Copilot era nato come un correttore automatico intelligente: tu scrivevi, lui ti suggeriva la riga successiva, quindi era come avere un’assistente, oggi però è diventato agentico.

E c’è chi ha fatto il passo dopo, togliendo l’editor del tutto. Claude Code, quello che uso io insieme a Codex, vive dentro il terminale. Non è un editor, non c’è nessuna finestra dove scrivi il codice riga per riga. È un agente a cui parli. Anthropic dichiara che questa roba fa già più di 2 miliardi e mezzo di ricavi su base annua, e più che raddoppiati da inizio 2026. Il coding è la prima cosa per cui le aziende usano l’AI, e Claude Code non è più un editor per definizione.

Se mi guardo lavorare con onestà: quante volte al giorno apro un file per scriverci dentro, e quante invece per rileggere cosa ha combinato l’AI? Il rapporto è cambiato, e velocissimo. Il posto dove scrivevo il codice sta diventando il posto dove supervisiono qualcuno, o qualcosa, che lo scrive al posto mio.

Se l’editor era il complemento che hai reso gratis per vendere il resto, cosa succede quando l’editor stesso smette di servire? Quando la gente non apre più una finestra per scrivere, ma dà ordini a un agente? Il pavimento su cui hai costruito la tua vittoria si sta spostando proprio mentre finisci di costruirci sopra. Hai conquistato il mercato degli editor esattamente nel momento in cui gli editor smettono di essere il centro. E stavolta Microsoft non guida, insegue: a maggio 2026 The Information ha raccontato di allarmi interni sul fatto che Copilot stia perdendo terreno contro Cursor, Claude Code e gli altri.

Cosa mi porto a casa

Quello che mi resta di questa storia, da uno che sui prodotti ci lavora davvero, è una cosa sola sul prezzo.

Il prezzo va inserito in base al valore e non in relazione a ciò che tutti usano. Microsoft l’ha capito tre volte: ha regalato il valore dell’hardware per vendere Windows, poi ha regalato l’editor per vendere il cloud e adesso prova a farlo con l’AI. In questo modo, il prezzo ogni volta si è spostato di un piano in su, scivolando dall’editor, al cloud fino all’agente. E ogni volta chi restava a difendere il prezzo sul piano inferiore, si ritrovava a vendere una commodity.

Ci faccio caso ogni volta che osservo i prodotti che seguo: c’è sempre la tentazione di mettere il prezzo dove ti senti sicuro, sulla feature che hai fatto bene e che oggi funziona. Peccato che il mercato quella cosa te la sta già trasformando in commodity mentre tu la difendi.

Quindi la domanda che ti lascio, e che mi faccio anch’io guardando quello che costruisco: nel tuo prodotto, stai facendo pagare la cosa giusta? O stai difendendo il prezzo su qualcosa che il mercato sta già rendendo gratis, o peggio, che tra un po’ non userà più nessuno?

Ci vediamo alla prossima.

Senza filtri,
Chri

P.S. Costruiamo insieme Senza Filtri

Ho creato un breve sondaggio anonimo per capire come migliorare la newsletter ed esserti più utile. Se ti va di rispondere a qualche domanda clicca qui (meno del tempo di prendere un caffè). Grazie mille.

👋 Ciao, sono Chri. Fractional CTO e questa è Senza Filtri: la newsletter dove condivido il dietro le quinte del mio viaggio da imprenditore (esperienze, cosa ho imparato e tanti errori) alternando a qualche deep dive sui business che mi incuriosiscono.

31 marzo 2016, fuori dai negozi Tesla di mezzo mondo c’è la fila. Gente in coda da ore, qualcuno addirittura dalla notte prima. A Sydney un pazzo (perché così puoi chiamare uno che fa na cosa del genere) si era piazzato lì la mattina presto per essere il primo al mondo. A Montreal un altro pazzo aveva montato una tenda sotto la neve davanti allo store.

Tutti lì ad aspettare per dare a Tesla 1.000 dollari per un’auto che nessuno aveva ancora visto, di cui non si conoscevano le specifiche definitive e che sarebbe arrivata anni dopo.

Uno di loro fu intervistato e disse: “Sono pazzo? Sto qui da quattro ore per concedere a Tesla un prestito infruttifero di 1.000 dollari per un’auto di cui non so assolutamente nulla e che potrebbe persino non esistere mai?”

Ecco. La storia che voglio raccontarti è tutta dentro quella frase.

La classica regola

Il copione è sempre lo stesso: progetti, costruisci e vendi. Build then sell. Costruisci e poi vendi.

Nell’automotive questa regola è ancora più ferrea che altrove, perché i soldi che devi mettere davanti sono parecchi. Una singola linea di produzione ad alto volume costa tra i 200 e i 500 milioni di dollari. Aggiungici la fabbrica delle batterie e sei sui miliardi. Tutto questo ancora prima di aver venduto una macchina.

Per coprire quei buchi le case automobilistiche usano linee di credito, obbligazioni, banche. C’è sempre qualcuno che paga gli interessi mentre l’auto sta ferma sul piazzale del concessionario in attesa di un compratore.

Tesla nel 2016 aveva un problema enorme con questa regola perché i soldi non li aveva. Era un’azienda cronicamente a corto di cassa, che non aveva mai chiuso un anno in utile, reduce da una storia in cui nel 2008 era arrivata a tre giorni dal fallimento con 9 milioni in cassa. Bei tempi.

Quindi, cosa fai quando devi costruire la macchina che ti cambia la vita, ma non hai i soldi per la fabbrica?

Inverti la regola.

La regola al contrario

Il 31 marzo 2016 Tesla presenta la Model 3. La prima Tesla “per tutti”: autonomia oltre le 200 miglia, prezzo base annunciato 35.000 dollari, una berlina elettrica vera, non l’utilitaria triste con 100 km di autonomia tipo Nissan Leaf.

La cosa pazzesca però non è la macchina in sé, (che alla fine può piacerti o no), ma che la gente poteva prenotarla con un deposito di 1.000 dollari rimborsabili e lo stava facendo a occhi chiusi, ancor prima che Musk salisse sul palco per mostrarla.

I numeri di quei giorni sono tanta roba. Più di 115.000 prenotazioni nelle prime 24 ore, prima del reveal vero e proprio. 276.000 entro il sabato. 325.000 dopo una settimana. Musk twitta che sono circa 14 miliardi di dollari di vendite potenziali. Nella sua lettera agli azionisti Tesla lo scrive nero su bianco: “il più grande lancio di un prodotto di consumo di sempre”.

Per battere il record precedente di prenotazioni di un’auto bisogna tornare alla Citroën DS del 1955, che ne raccolse 80.000 in dieci giorni al salone di Parigi. Un primato durato sessant’anni, polverizzato in una settimana.

La cosa davvero furba è che quei depositi a bilancio Tesla li registra come “customer deposits”, cioè una passività: soldi che non sono ancora suoi, rimborsabili finché l’auto non entra in produzione. Nel frattempo però sono cassa vera che potevano usare. Niente interessi, niente banca da convincere, niente azioni da diluire. I customer deposits di Tesla passano da 283 milioni a fine 2015 a 664 milioni a fine 2016.

Detto papale papale: centinaia di migliaia di persone hanno fatto a Tesla un prestito gigantesco a tasso zero. E nessuna di loro lo aveva chiesto in quei termini. Pensavano di mettersi in coda per un’auto e invece stavano firmando una linea di credito.

Perché la gente ci ha creduto

A questo punto la domanda vera è un’altra. Non “come ha fatto Tesla a incassare”, ma perché diavolo centinaia di migliaia di persone hanno dato soldi veri per un’auto che non potevano né vedere, né guidare.

Di solito si scivola sulla risposta facile: il culto di Musk e i suoi fanboy, però guardando con lucidità i numeri, ci si accorge che crede nel 2016 a Tesla non era un mero atto di fede di un fan, ma una scommessa con una base razionale.

Tesla aveva già consegnato diverse vetture: nel 2008 la Roadster, nel 2012 la Model S, nel 2015 la Model X. Tre auto promesse e tre auto arrivate, con la Model S osannata dalla stampa ed eletta come migliore berlina mai costruita.

Quindi no, chi scommetteva 1.000 dollari non era un pazzo fanatico che stava puntando su una bella slide, ma una persona che voleva puntare su un’azienda che, alla fine, aveva mantenuto già tre volte la sua promessa.

In economia questo si chiama costly signal, ovvero segnale costoso: Tesla aveva già pagato il prezzo di dimostrare ciò che sapeva fare e quel “curriculum” valeva più di qualsiasi spot.

Sulla base razionale poi è scattata la prova sociale. Robert Cialdini la studia da quarant’anni: quando non siamo sicuri, guardiamo cosa fanno gli altri e lo prendiamo come prova che la scelta sia giusta. E cosa vedevi nel marzo 2016? File ovunque, foto sui giornali, 115.000 prenotazioni in un giorno. La coda stessa diventava la pubblicità. Ogni persona in fila era un cartellone vivente che diceva alle altre “fidati, ci metto i soldi pure io”. Ecco perché Tesla non ha speso un euro in advertising: la pubblicità erano i suoi clienti.

Su questa roba solida ci ha poi lavorato la psicologia spicciola, il sunk cost. Una volta che hai messo i 1.000 dollari, anche se sono rimborsabili, qualcosa nella testa scatta. Hai impegnato dei soldi, ti sei raccontato agli amici che hai prenotato la Tesla, sei “dentro”. Andarsene voleva dire ammettere di aver sbagliato, e nessuno ama ammetterlo. Il deposito rimborsabile sulla carta diventava un quasi-obbligo nella testa.

Geniale vero? O forse no.

Il conto che non ti aspetti: la production hell

Perché quando vendi il futuro, poi te lo devi costruire davvero. E qui arriva la parte che nessuna lettera agli azionisti racconta con lo stesso entusiasmo dei preordini.

Tutta quella “domanda” va prodotta, e Tesla ha promosse dei volumi che non sa ancora soddisfare. Elon Musk ha deciso di automatizzare tutto con una fabbrica iper robotizzata a prova di errore, e gli umani? Beh, quelli fuori dai piedi. Peccato che all’inizio non va poi benissimo.

Quel periodo, il 2017 e il 2018, dentro Tesla lo chiamano “production hell”, l’inferno della produzione. E non è un modo di dire da newsletter motivazionale, è proprio il momento in cui l’azienda rischia di rimanerci secca. Musk lo ha raccontato dopo: “perdevamo soldi come pazzi, e se non avessimo risolto quei problemi in pochissimo tempo, saremmo morti”. Quanto vicini alla fine? Sue parole: “nell’ordine delle settimane a una cifra”.

Per arrivare a fare 5.000 Model 3 a settimana, Tesla tira su un’intera linea di assemblaggio aggiuntiva sotto una tenda, una tensostruttura piantata nel parcheggio della fabbrica di Fremont, costruita in tre settimane. L’azienda che voleva la fabbrica più automatizzata del mondo che salva il trimestre con un capannone da circo montato in fretta e furia. Musk in quel periodo dormiva sul pavimento della fabbrica, stessi vestiti per giorni, e su quell’automazione estrema ha poi ammesso: “è stato un errore. Mio. Gli esseri umani sono sottovalutati” (pensa adesso con l’AI...).

Però... c’è un però. La storia “i depositi dei clienti hanno salvato Tesla” è bella, ma falsa. I depositi hanno aiutato, hanno dato ossigeno e hanno dimostrato che la domanda c’era. Ma Tesla per sopravvivere ha comunque emesso 2 miliardi di dollari di nuove azioni nel 2016, ha fatto debito e ha spremuto i mercati finanziari. I depositi ti comprano tempo, non ti comprano una fabbrica. Chi ti dice che Tesla si è finanziata “solo” con i preordini ti sta vendendo una bella favoletta.

Stessa azienda, due finali

La Model 3, alla fine, è arrivata. In ritardo, in mezzo all’inferno, ma è arrivata. Oggi è una delle auto elettriche più vendute al mondo e ha trasformato Tesla da produttore di nicchia a colosso. Chi aveva messo i 1.000 dollari ha avuto la sua macchina. La promessa è stata mantenuta.

Ora tieni questo in testa e guarda l’altra faccia della stessa identica azienda.

Nel 2017 Tesla annuncia la nuova Roadster, una supercar elettrica pazzesca. Stesso meccanismo: prenoti, lasci il deposito. Solo che qui i depositi erano da 5.000 dollari, fino a 250.000 per la Founders Series. Siamo nel 2026 e quella macchina non è ancora stata consegnata. Otto anni. C’è gente, tra cui pure Marques Brownlee, uno degli youtuber tech più seguiti del pianeta, che ha raccontato la fatica di farsi ridare indietro i soldi.

Stessa azienda, stesso identico trucco, due finali opposti. Da una parte un prodotto storico, dall’altra un deposito da decine di migliaia di dollari fermo da otto anni per qualcosa che non esiste.

È tutto qui il punto: vendere il futuro funziona finché poi quel futuro lo costruisci. Nel momento in cui smetti di consegnare, lo stesso meccanismo che ti aveva fatto sembrare un genio ti trasforma in uno che ha preso i soldi e non ha mantenuto.

Il pattern non è solo di Tesla

E la cosa interessante è che questo schema, una volta che lo vedi, lo riconosci ovunque.

Il Cybertruck di Tesla è la versione caricaturale del modello. Deposito ridotto a 100 dollari, prenotazioni dichiarate oltre il milione, numeri da capogiro. Peccato che quando poi la produzione è partita, la conversione in vendite vere sia stata bassissima. La lezione è semplice: un deposito da 100 dollari rimborsabili compra entusiasmo, non impegno. Più abbassi il deposito, più i numeri si gonfiano e meno valgono.

Fuori dall’auto è pieno di esempi. Star Citizen, un videogioco spaziale, ha raccolto centinaia di milioni di dollari vendendo astronavi virtuali di un gioco che dopo più di dieci anni è ancora in sviluppo. Apple con il Vision Pro ha usato la stessa logica di scarsità e prenotazione anticipata, trasformando i primi clienti in beta tester paganti. Tutto il mondo del crowdfunding hardware, da Kickstarter in giù, è questo: dai i soldi prima, il rischio di consegna te lo tieni tu.

Ci sono anche prodotti nati morti eh. Il Coolest Cooler, un frigo portatile, è stata una delle campagne Kickstarter più finanziate di sempre: oltre 13 milioni di dollari da 62.000 persone. Più di 20.000 di quei sostenitori la loro borsa frigo non l’hanno mai vista. Faraday Future, la startup che doveva essere la “ammazza Tesla”, dopo anni di hype e migliaia di prenotazioni dichiarate si è ritrovata, a guardare i conti veri, con 401 ordini pagati. Quattrocentouno.

Vendere la visione è facile, consegnarla è un altro sport.

Cosa mi porto a casa

Quello che mi resta in testa di questa storia, dopo averla studiata, è che il preordine non è marketing. È un evento finanziario travestito da marketing. Quando qualcuno mette un deposito ti sta dando tre cose insieme: cassa senza interessi, una prova che il mercato vuole quella cosa, e un esercito di persone che ora tifano per te perché hanno la pelle nel gioco. Per un’azienda a corto di soldi è oro.

Ma c’è il rovescio della medaglia, ed è la parte che mi tengo io che lavoro su prodotti veri tutti i giorni. Nel momento in cui vendi una promessa, ti carichi un debito di execution. La production hell è il conto. E quel conto arriva sempre, perché la gente che ti ha dato i soldi prima diventa la stessa gente che ti aspetta al varco se non consegni.

Mi capita spessissimo con i founder che seguo. Arrivano carichi: “facciamo una prevendita, validiamo la domanda, raccogliamo un po’ di cassa prima di costruire”. E in teoria hanno ragione, è esattamente la mossa di Tesla. Ma la domanda che faccio sempre non è “riesci a vendere il futuro?”. Quasi tutti, con una bella landing page e un po’ di hype, riescono a vendere qualcosa. La domanda è “sei sicuro di saperlo poi costruire e consegnare davvero?”. Perché lì si vede chi è Model 3 e chi è Roadster.

Quindi la cosa che ti lascio è una domanda che mi faccio anche io: quale pezzo di quello che stai costruendo potresti permetterti di vendere prima di averlo finito? E soprattutto, se lo facessi, saresti capace di consegnarlo davvero, o ti staresti solo comprando del tempo che non sai come ripagare?

Ci vediamo alla prossima.

Senza filtri,
Chri

P.S. Costruiamo insieme Senza Filtri

Ho creato un breve sondaggio anonimo per capire come migliorare la newsletter ed esserti più utile. Se ti va di rispondere a qualche domanda clicca qui (meno del tempo di prendere un caffè). Grazie mille.

[Video Youtube] I rischi del vibe coding per chi sviluppa

In questo video ti racconto quali sono i rischi del vibe coding per chi sviluppa prodotti digitali oggi.

[Guarda il video]

👋 Ciao, sono Chri. Fractional CTO e questa è Senza Filtri: la newsletter dove condivido il dietro le quinte del mio viaggio da imprenditore (esperienze, cosa ho imparato e tanti errori) alternando a qualche deep dive sui business che mi incuriosiscono.

Ogni progetto inizia con un piano, con una bella roadmap, con le sue belle colonne e con le scadenze, messe lì come se qualcuno sapesse davvero ciò che dovrà accadere (o magari come se avesse la sfera di cristallo).

E noi tecnici quella roadmap la trattiamo come un’entità superiore, una cosa decisa da qualcuno che non è lì con noi, ma sta in un’altra stanza, e che arriva giù, tra noi, per chiederci cieca obbedienza.

”Questo va consegnato entro il 30”, dice, e tu sei lì a fare i salti mortali per far tornare i conti.

Peccato che 9 volte su 10 i conti non tornano. Trovi la scadenza che non sta in piedi, un effort stimato alla bene e meglio da chi non scriverà una riga e una dipendenza che nessuno aveva visto. E quando salta, salta sempre dalla stessa parte: la nostra.

Per anni l’ho vissuta come un mio problema, pensando “sarò io che stimo di merda” (autostima alle stelle, come vedi), ma ho capito che il problema non era la stima, ma il momento in cui la roadmap veniva decisa e, soprattutto, chi c’era in quella stanza.

La roadmap calata dall’alto

Lo schema lo conosci: la roadmap la decide il business e successivamente viene calata sul team di prodotto, che a quel punto deve fare le magie per rispettarla. E chi sviluppa davvero, ovvero gli individual contributor, vengono coinvolti solo nella fase di discussione. Mai nella decisione.

Nella discussione ti chiedono “ce la fai per il 30?”. Hai già la data davanti, hai già la feature definita, hai già tutto definito. Puoi dire soltanto “sì”, oppure essere quello che frena il progetto. Nella decisione, invece, sei nella stanza di prima. Quando si decide cosa fare, perché, e in che ordine. Quando le scadenze sono ancora ipotesi e non promesse già fatte a un cliente.

Quasi sempre l’IC entra a giochi fatti. E gli si chiede pure di essere motivato.

Perché non funziona

Il motivo per cui questo schema fa acqua non è uno solo, sono tanti e sono tutti collegati.

Il primo è il più ovvio e il più ignorato: chi esegue ha informazioni che chi decide non ha. Il business stima a vista, il tecnico sa dove sono i campi minati (o i merdoni). Sa che quella cosa che “sembra mezza giornata” tocca un pezzo di codice che nessuno osa guardare da due anni. Sa quali sono le dipendenze vere. Decidere senza quelle informazioni vuol dire decidere alla cieca, e poi stupirsi che il muro arrivi.

Poi c’è una cosa che ho imparato a mie spese: i problemi è meglio scoprirli sempre prima. In fase di decisione un nodo costa una conversazione di mezz’ora. In fase di esecuzione costa uno sprint bruciato e una telefonata al cliente per dirgli che no, per il 30 non si fa. Più aspetti a tirare fuori il problema, più ti costa.

C’è il discorso dei trade-off, che secondo me è quello che pesa di più. Il trade-off vero lo può fare solo chi conosce il costo. “Questa feature intera sono tre settimane, ma una versione all’80% sono tre giorni.” Questa frase il business da solo non la può dire, perché non sa quanto costano le cose. E quasi sempre, indovina un po’, l’80% bastava. Solo che se nessuno te lo dice, parti per fare il 100% e ci sbatti la testa.

E poi c’è la parte umana, che è quella che cambia tutto a lungo termine. Un piano deciso con te lo difendi, mentre uno imposto dall’alto lo subisci. È la differenza tra un team che si fa in quattro per far funzionare le cose e un team che aspetta in silenzio il momento di poter dire “io l’avevo detto”. L’ho visto succedere, ed è una delle cose più tristi da vedere in un’azienda.

L’ultima la dico veloce perché è quella che esplode più tardi di tutte: le promesse irrealistiche non fanno male nel momento in cui le fai. Fanno male dopo, quando il cliente o il mercato presentano il conto. Coinvolgere chi esegue è il modo più economico che esista per non promettere cose impossibili. Costa una riunione adesso invece di un rapporto incrinato fra tre mesi.

Severo ma giusto, direbbe qualcuno.

Come provo a sistemarla

Allora, cosa faccio io quando entro in un’azienda da fractional e mi trovo davanti questa dinamica?

Innanzitutto, prima ancora di toccare processi e tool, cambio come vengono visti gli IC. Non più esecutori, ma pensatori, persone coinvolte nel prodotto e non solo braccia a cui dare il task. Sembra una banalità detta così, ma cambia tutto: se uno è un esecutore lo chiami quando il piano è pronto, se è un pensatore lo chiami mentre il piano si fa.

Questo vuol dire portarli nella stanza quando si pianifica. E qui arriva la parte difficile, perché un IC ragiona in modo diverso da un uomo di business. Parla un’altra lingua, ha altre priorità, guarda altri rischi. Il lavoro vero è trovare il modo di far parlare questi due mondi, e portare oggettività dove si può. (Su questa cosa del tradurre tra tech e business ci ho scritto una newsletter intera, come comunico ai non techy guys del management, perché è metà del mestiere.)

E ti dico una cosa controintuitiva: questa fatica non aiuta solo il team, aiuta anche il business. Perché un business che ha coinvolto il team ha argomenti veri per motivare le scelte, non solo agli stakeholder, ma alle persone che quelle scelte le devono fare. L’appartenenza al prodotto non te la regala nessuno, te la costruisci coinvolgendo.

Dove voglio arrivare quindi? Semplice, la mentalità di prodotto.

Ogni team funzionale che è owner end-to-end di un pezzo. Non “tu scrivi il codice di questa cosa”, ma “questa cosa è tua, dall’idea a quando gira in produzione”. Su team piccoli funziona benissimo, e io lavoro quasi sempre con startup dove il team di prodotto è massimo una decina di persone. Su strutture grandi è un altro discorso, lì entrano in gioco un botto di dinamiche che qui non sto a raccontare.

Lo so cosa stai pensando: “ma tutta questa roba porta via tempo allo sviluppo vero” ed hai ragione. E va detto chiaro, non ha senso nasconderlo. Solo che è un investimento, non un costo. Se ho chiaro tutto, ci metto meno. Se parto confuso, ci metto il triplo e rifaccio le cose due volte. Il tempo che “perdi” a pianificare insieme lo riguadagni in esecuzione con gli interessi. Non esiste nessuna formula universale, ogni team ha i suoi processi, metodi ed equilibri. Non sto vendendo un framework, ma voglio farti capire che si può fare e che dove l’ho fatto ha funzionato.

E adesso c’è pure l’AI

C’è un pezzo nuovo in tutta questa storia, ed è quello che mi ha fatto venire voglia di scriverne adesso e non un anno fa.

L’AI sta diventando sempre di più l’esecutore della visione.

Prima il contesto passava da persona a persona. La memoria del prodotto era umana, implicita, viveva nelle teste e nelle chiacchiere davanti alla macchinetta del caffè. Funzionava male, ma funzionava: alla peggio andavi a chiedere al collega “perché questa cosa è fatta così?”.

All’AI non puoi chiederlo davanti alla macchinetta. Per farla lavorare bene devi darle il contesto, e l’unico modo per darle il contesto è scriverlo. Tutto. Nero su bianco.

Il che significa che pianificare non è più mettere date su una roadmap. È costruire e mantenere una libreria di contesto prodotto scritta. Una cosa che serve agli umani per capire dove stanno andando, e che ora serve anche alla macchina per eseguire senza combinare disastri.

E sai qual è il bello? Che la roadmap calata dall’alto, quella decisa in una stanza senza chi esegue, salta proprio qui. Perché non ha contesto scritto, non ha visione condivisa, ha solo date. E se metti un’AI a eseguire una visione che il team non ha costruito e che non è scritta da nessuna parte, non ottieni velocità. Ottieni caos e più velocemente.

Improvvisamente saper scrivere il contesto, mantenerlo, tenerlo vivo, è diventata una competenza di prodotto. Non un di più.

Quindi

Eisenhower aveva ragione. Il piano in sé vale poco, salterà comunque al primo contatto con la realtà. Quello che vale è l’atto di pianificare insieme, con le persone giuste nella stanza al momento giusto, prima che le date diventino promesse.

Perché alla fine la roadmap serve a darti un punto da cui partire, sapendo già che da lì devierai. Per deviare nel modo giusto, devi aver già capito dall’inizio dove stai andando, ed ecco perché chi lo fa deve stare nella stanza delle decisioni, e non solo in quella delle esecuzioni.

Senza filtri,
Chri

P.S. Costruiamo insieme Senza Filtri

Ho creato un breve sondaggio anonimo per capire come migliorare la newsletter ed esserti più utile. Se ti va di rispondere a qualche domanda clicca qui (meno del tempo di prendere un caffè). Grazie mille.

[Video Youtube] Stiamo costruendo per un mondo che non esiste più

Aspettare ore per un download, stampare le mappe, configurare software per ore. Esperienze che mi hanno formato e che oggi, senza che me ne accorga, sono diventate i miei bias. In questo video ti racconto quali cicatrici digitali mi porto dietro, come si infilano nelle scelte di prodotto che faccio, e cosa sto facendo per non diventare irrilevante

[Guarda il video]

👋 Ciao, sono Chri. Fractional CTO e questa è Senza Filtri: la newsletter dove condivido il dietro le quinte del mio viaggio da imprenditore (esperienze, cosa ho imparato e tanti errori) alternando a qualche deep dive sui business che mi incuriosiscono.

Te lo dico subito, Stripe è una delle aziende che ammiro di più al mondo in termini di prodotto, e la cosa divertente è che fa la cosa più noiosa del pianeta (almeno per me, dopo 5 anni nel fintech): processare pagamenti. Ovvero, sposta soldi dalla carta di un tizio al conto di un altro tizio (”move the money from your client’s pocket into your pocket.” cit).

Stripe è diventata una macchina valutata fino a 95 miliardi nel 2021 e in una recente tender offer ha raggiunto addirittura i 159. Per capire come ci sono riusciti bisogna tornare nel 2010, quando accettare pagamenti online era una sbatta enorme.

Prima di Stripe: un girone dell’inferno

Mettiamoci nei panni di chi nel 2010 voleva far pagare qualcosa sul proprio sito.

Prima cosa: andavi in banca a chiedere un “merchant account”. Settimane di rotture burocratiche immense e gente in giacca e cravatta che ti guardava male perché eri una startup di due persone senza storico. Poi ti serviva un gateway di pagamento, quindi un altro fornitore, un altro contratto, un’altra integrazione. Poi dovevi passare un audit PCI DSS, lo standard di sicurezza delle carte, che da solo era un lavoro a tempo pieno. E infine ti gestivi frodi e chargeback a mano, pregando il buon dio che non ti si inculas...fregassero.

In pratica, prima ancora di sapere se il tuo prodotto sarebbe piaciuto a qualcuno, dovevi spendere settimane o mesi a parlare con banche e compliance. Era come dover costruire la centrale elettrica prima di poter accendere la lampadina.

C’era Paypal, certo, che aveva risolto la parte del wallet per chi compra. Ma integrarlo come venditore era comunque una sofferenza perché aveva (ed ha) API incoerenti, documentazione sparsa ovunque, redirect che ti sbattevano l’utente su una pagina con un altro brand, e un modello pensato più per le aste su eBay che per il mondo nuovo di SaaS e app.

Le prime volte che ho dovuto far accettare pagamenti a un prodotto, anni fa, il pensiero non era “che bella feature”, era “oddio, adesso devo aprire il fascicolo pagamenti”.

Quel muro lì, che tutti accettavano come inevitabile, è esattamente quello che due fratelli irlandesi hanno deciso di abbattere.

Due fratelli e una cartella chiamata /dev/payments

Patrick e John Collison vengono da un paesino in Irlanda. Programmatori precoci, avevano già venduto una prima azienda (Auctomatic) e si erano scontrati di continuo con lo stesso problema: ogni idea nuova che avevano si infrangeva sulla domanda “ok, ma come ci facciamo pagare?”.

A fine 2009 scrivono un prototipo. Lo chiamano, e già qui si capisce tutto, /dev/payments. Un nome che solo noi tecnici possiamo capire e amare. Due settimane dopo processano la prima transazione vera per 280 North, una startup della rete Y Combinator.

Nel 2010 fondano Stripe ed entrano in YC. Il pitch è di una semplicità assurda: “accetta pagamenti in minuti invece che in settimane”. E il posizionamento è una scelta strategica radicale, sintetizzata in due parole: “payments for developers”.

Tradotto: noi non vendiamo al CFO che firma i bonifici. Vendiamo a chi scrive il codice.

L’icona di tutto questo diventano le famose 7 righe di codice. Un piccolo snippet, un form e uno script, e il tuo sito accettava una carta e ti faceva arrivare i soldi sul conto. Tutto il casino di prima, banche, gateway, PCI, frodi, sparito dietro quelle righe. Se sapevi fare il deploy di un’app, sapevi anche accettare pagamenti. Punto.

“Dammi il tuo pc”

C’è un aneddoto che nel mondo startup è ormai leggenda, e si chiama “Collison installation”.

Nei primi tempi, quando un founder diceva “ah figo, sembra interessante, magari lo proviamo”, i Collison non rispondevano con una mail di follow-up. Rispondevano “dammi il tuo pc” e te lo installavano lì, in quel momento, seduti di fianco a te.

È il praticamente il manuale del “fai cose che non scalano” preso alla lettera. Faceva due cose insieme: azzerava l’attrito tra “mi interessa” e “sono in produzione”, trasformando ogni installazione in una sessione di user research dal vivo, dove vedevano con i loro occhi esattamente dove lo sviluppatore si bloccava, per poi tornare a casa e sistemare quel punto.

Il mito di Stripe in YC nasce lì: quei due che ti installano in mezz’ora una cosa che ti avrebbe consumato tempo per settimane.

Faccio il CTO per un attimo: perché 7 righe bastavano davvero

Qui devo mettermi il cappello da fractional CTO un secondo, ma prometto niente serpentese.

Il punto tecnico geniale di Stripe è la tokenizzazione. Quando un cliente inserisce la carta, i dati sensibili non passano (idealmente) mai dai server di chi vende. Il numero della carta va direttamente a Stripe tramite un componente che gira nel browser e Stripe ti restituisce un “token”. Il tuo server vede solo quell’etichetta e la usa per far partire il pagamento.

Immaginatelo come far viaggiare il numero della carta dentro una busta sigillata che solo Stripe può aprire. Tu, sul tuo server, vedi solo l’esterno della busta.

Sembra un dettaglio, ma è tanta roba e ti dico anche perché: tutta la parte più dolorosa della compliance PCI, quella che non ti faceva dormire la notte, se la prende in carico Stripe. Loro si certificano al livello più alto dell’industria, tu praticamente non tocchi mai i dati delle carte. La cosa che ti faceva più paura, sparisce dai tuoi pensieri.

E poi c’è il modo in cui hanno trattato l’API. Cioè non come un dettaglio tecnico, ma come il prodotto vero. Documentazione come dio comanda, una modalità test con chiavi immediate, versioning serio, messaggi di errore che ti dicevano davvero cosa avevi sbagliato. Dove i competitor ti vendevano “una piattaforma completa” con dentro un portale web pieno di menù, Stripe ti dava un’API e degli esempi che funzionavano al primo colpo.

La documentazione, di fatto, è il commerciale. Lo sviluppatore arrivava da solo dalla registrazione al primo pagamento, in pochi minuti, senza che nessuno gli telefonasse.

Da snippet a sistema operativo della finanza

Una volta che ti sei preso il developer, il gioco diventa un altro: prendere ogni pezzo rognoso del back-office finanziario che ogni startup sarebbe costretta a reinventare, e trasformarlo in un’API con dei default sensati.

E così negli anni lo snippet diventa una galassia. Billing per gli abbonamenti ricorrenti, quelli che ogni SaaS deve gestire e che a farli a mano sono un inferno di edge case. Connect per i marketplace, che ti permette di pagare driver, creator e venditori terzi con split automatici e verifiche. Radar, l’antifrode basato su machine learning che impara dai pattern di tutta la rete Stripe. Tax per le imposte. E poi roba quasi da banca vera: Atlas per costituire una società in Delaware con conto annesso, Issuing per emettere carte via API, Treasury per offrire conti.

La frase che si sono appiccicati addosso è “increase the GDP of the internet”. Aumentare il PIL di internet. Suona da slide motivazionale, lo so, ma è esattamente quello che fanno: abbassano la barriera d’ingresso così tanto che nascono business che altrimenti non sarebbero mai nati. E loro prendono una fetta di tutto quel volume nuovo.

I numeri che fanno dire wow

Il volume di pagamenti che passa da Stripe ha superato 1,4 trilioni di dollari nel 2024, in crescita del 38% sull’anno prima. Stiamo parlando di circa l’1,3% del PIL globale che transita da una sola azienda. Nel 2025, secondo le ultime comunicazioni, i business sulla piattaforma ne generano 1,9 di trilioni, vicino all’1,6% del PIL mondiale.

La storia delle valutazioni invece è un botto più ballerina, una specie di montagna russa che rimbalza su e giù manco fosse una crypto. Series H nel 2021, picco a 95 miliardi, la startup privata più valutata della Silicon Valley. Poi arriva il 2023, il mercato si raffredda, e raccolgono 6,5 miliardi a una valutazione dimezzata, sui 50, soprattutto per dare liquidità a dipendenti e investitori storici. Nel 2025 una tender offer la riporta a 91,5, praticamente di nuovo al picco. E nel 2026 si parla di 159 miliardi.

Oltre 5 milioni di business la usano, inclusa metà delle Fortune 100 e il 78% delle aziende della Forbes AI 50. È profittevole. E, dettaglio non da poco, non ha mai fatto l’IPO: preferisce le tender offer periodiche per dare cassa a chi deve uscire, mantenendo le mani libere.

Tutto questo, ripeto, per processare pagamenti. La cosa più noiosa del mondo.

I cugini di Stripe (e perché ti riguarda)

Stripe non è un caso isolato, è il capostipite di un pattern.

Twilio ha fatto la stessa identica cosa con le telefonate e gli SMS: prima ti serviva un team per integrare la telefonia, dopo bastavano poche righe. Plaid l’ha fatto con l’accesso ai conti bancari. Algolia con la ricerca. Tutti API-first, tutti con documentazione esemplare, tutti che ti fanno pagare di più dell’hosting grezzo ma ti fanno risparmiare ordini di grandezza di lavoro umano.

E indovina chi sta replicando lo stesso schema oggi, identico? Le API di AI. OpenAI, Anthropic, gli altri. Documentazione che è una demo, sandbox, chiavi immediate, pricing per quello che consumi. Quando uso Claude via API per i miei progetti, l’esperienza da sviluppatore è figlia diretta di quello che ha inventato Stripe quindici anni fa. Hanno definito loro la grammatica con cui si vende software agli sviluppatori.

Cosa ci portiamo a casa

Ci sono un paio di cose che mi restano in testa dopo aver studiato questa storia, e che uso quando do consigli ai miei clienti.

La dico così, “de botto”: la developer experience è obbligatoria. Per anni l’ho sentita trattare come una cosa carina, ma secondaria. Stripe dimostra il contrario, documentazione ottima, API coerenti ed esempi che funzionano possono valere più di uno sconto sul prezzo. Tant’è che quando scelgo un fornitore per un cliente, ormai la prima cosa che guardo è quanto è dolorosa l’integrazione, non quanto costa al mese.

E poi c’è la cosa che faccio più fatica a far digerire ai founder: cioè che i problemi più noiosi sono quasi sempre i più profittevoli. Compliance, pagamenti, tasse, riconciliazione, roba che nessuno vuole toccare, ma se riesci a nasconderla dietro un’interfaccia semplice crei una quantità di valore assurda. Mentre tutti rincorrevano l’app sexy del momento, Stripe è andata a sedersi sulla parte più regolata e barbosa dell’economia di internet, e ha vinto rendendola invisibile.

Il bello è che non è nemmeno la più economica. Su quel 2,9% più 30 centesimi una bella fetta se ne va comunque a banche e circuiti, e ci sono alternative più aggressive sul prezzo. Eppure vince lo stesso, perché ottimizza una risorsa che nel foglio Excel non la vedi: il tempo degli sviluppatori. Se ti faccio andare live tre mesi prima, quei tre mesi di fatturato in più valgono un botto più della differenza di commissione. Il costo vero non era la fee, era il tempo, e quasi nessuno lo mette a bilancio.

Attenzione però

La settimana scorsa, con OnlyFans, ti ho messo in guardia proprio da questi qua. Ti ho detto che chi ti processa i pagamenti ha il potere di spegnerti il business in 24 ore senza darti spiegazioni. Questo vale anche per Stripe. Ogni volta che un founder mi dice “tutto il mio fatturato passa da Stripe”, una parte di me pensa “che meraviglia di integrazione” e l’altra pensa “e il giorno che ti staccano?” (che non succede praticamente mai nel 99% dei casi, lo so).

Sono vere tutte e due le cose insieme. Lo strumento che ti dà i superpoteri è lo stesso che ti tiene per le palle. Stripe è l’azienda che ti fa partire in mezz’ora, ed è anche quella che, se un giorno decide che sei “high risk”, ti lascia con un sito che non incassa un euro. Ha vinto eliminando l’attrito, rendendosi invisibile, diventando il default. E “default” è esattamente la parola che descrive un’infrastruttura da cui poi non riesci più a uscire.

Per questo, ogni volta che valuto un tool per un cliente, dopo questa storia mi faccio una domanda fondamentale (rispetto a prima): lo sto scegliendo perché è davvero il migliore, o perché mi ha tolto così tante rotture che ho smesso di chiedermi cosa succede se un giorno non c’è più?

Resta il fatto che Stripe ha costruito un impero rispondendo a una domanda noiosissima che tutti gli altri evitavano: perché accettare pagamenti è così complicato? Da lì è uscito più dell’1% del PIL di internet. E il dubbio che mi porto a casa è quante altre domande noiose ci sono ancora là fuori, di quelle che tutti accettano come inevitabili, che aspettano solo qualcuno abbastanza ostinato da chiedersi “ma perché deve essere così difficile?”.

Ci vediamo alla prossima newsletter.

Senza filtri,
Chri

P.S. Costruiamo insieme Senza Filtri

Ho creato un breve sondaggio anonimo per capire come migliorare la newsletter ed esserti più utile. Se ti va di rispondere a qualche domanda clicca qui (meno del tempo di prendere un caffè). Grazie mille.

👋 Ciao, sono Chri. Fractional CTO e questa è Senza Filtri: la newsletter dove condivido il dietro le quinte del mio viaggio da imprenditore (esperienze, cosa ho imparato e tanti errori) alternando a qualche deep dive sui business che mi incuriosiscono.

Una startup era bloccata per andare in produzione perché a causa di problemi con la loro app mobile, l’app store gli bloccava la pubblicazione. Era all’inizio della mia carriera da fractional, non c’era niente di firmato: nessun contratto, nessuna fattura, nemmeno una mail con oggetto “conferma incarico”.

Li ho aiutati. Ho risolto. E poi ho aspettato.

Sai qual è stata la parte interessante? Quella relazione è diventata quasi due anni di collaborazione e attraverso quella startup ho conosciuto altri founder, altri team e altri clienti. Si è creata una rete che non esisteva e che se avessi risposto “prima dimmi come mi paghi, poi ne parliamo,” probabilmente non si sarebbe mai creata (e avrei perso tutto). Quindi, la parte interessante non è che mi hanno pagato, ma ciò che ne è uscito.

Però da qui in poi non voglio raccontarti la storia del “lavora gratis che poi arriva il karma” (al quale credo molto ma vabbè), che è il tipo di consiglio che ti aspetti da qualcuno che poi ti vende un corso da 997 euro su come fare personal branding. Quello che voglio esplorare è qualcosa di più preciso: perché la parola “gratis” è spesso il frame sbagliato con cui leggere certe situazioni.

Il consiglio che non sbaglia mai (tranne quando sbaglia)

“Non lavorare mai gratis.”

L’ho sentito un botto di volte dalle persone che conosco e che lavorano in modo autonomo da più anni di me. E capisco da dove viene: c’è una generazione intera di lavoratori autonomi che ha imparato a proprie spese cosa vuol dire svalutarsi, accettare per “visibilità”, fare sconti infiniti per non perdere il cliente, per poi ritrovarsi a fine mese senza soldi ma con un portfolio aggiornato.

Quel consiglio è nato come reazione a un problema reale e funziona bene come prima regola d’orientamento, soprattutto all’inizio del percorso.

Il problema è che preso alla lettera esclude una categoria enorme di cose che io faccio quasi ogni settimana e che, se ci penso bene, non ho nessuna intenzione di smettere di fare.

La discovery non la faccio pagare

Ogni call pre-contratto che faccio è tecnicamente non pagata. Ogni assessment tecnico che preparo per capire in che stato è il codice di una startup prima di mandare un’offerta, ogni analisi che mi faccio per capire quanto potrebbe durare un certo progetto e quali rischi nasconde, tutto lavoro non pagato.

Non ho mai trovato un modo sensato per far pagare quella fase e francamente non ho mai avuto davvero voglia di trovarlo.

La discovery non è un regalo che faccio al potenziale cliente. È l’investimento che mi permette di capire con chi sto lavorando, cosa serve davvero, se la collaborazione ha senso per entrambi. Senza quella fase, la proposta che mando è generica, costruita su assunzioni che probabilmente sono sbagliate. Con quella fase, è precisa: so cosa sto offrendo, a chi lo sto offrendo, se posso fare un buon lavoro o no.

Non farla mi costerebbe più che farla.

Eppure, se applico il principio “non lavorare mai gratis” alla lettera, quella fase dovrei eliminarla. O dovrei trasformarla in qualcosa che nella pratica nessuno paga e che, se iniziassi a chiedere, probabilmente mi farebbe saltare un pezzo di business che oggi funziona bene.

La parola “gratis” è sbagliata per descrivere quello che sta succedendo. Sto lavorando con una valuta diversa dal denaro immediato e il ritorno arriva in un altro momento o in un’altra forma.

Tre situazioni, tre valute

Sto cercando di capire che logica applico quando accetto di fare qualcosa senza compenso immediato.

La discovery è quella più semplice da spiegare perché non so esattamente cosa sto vendendo finché non capisco cosa serve. Chiamarla “gratis” è tecnicamente corretto, ma descrive male quello che sta succedendo.

L’emergenza che ho raccontato all’inizio era diversa e meno razionale. La startup di cui vi ho parlato non era un cliente con cui avevo già un rapporto, ma un contatto di qualcuno che conoscevo, e la decisione di aiutare era basata sulla lettura della situazione: analizzandolo, mi sembrava il tipo di contesto in cui entrare subito col piede giusto poteva portare qualcosa di positivo. E così è stato, anche se non potevo prevedere il timing (due anni di collaborazione) e la rete che avrebbe portato con sé.

Poi c’è la terza categoria, e qui bisogna pensare sia all’aspetto reputazionale, sia a quello relazionale: potrà capitare di lavorare con un cliente che sta attraversando un momento di difficoltà economica temporanea. In quel caso i pagamenti si accumulano, ma il rapporto è già in piedi. Ti trovi di fronte a un bivio: aspetti o pressi? Io personalmente ho scelto di aspettare, poi hanno saldato tutto appena hanno potuto, senza problemi. Ciò che è rimasto, oltre ai soldi, è la relazione: sanno che non sparisco al primo segnale di difficoltà e questo è un tipo di relazione e reputazione che non puoi costruire con i post su LinkedIn.

Il calcolo che cerco di fare

Ogni volta cerco di fare un ragionamento a sé, in modo esplicito. Non c’è una regola fissa da seguire e ho capito col tempo che la parola importante è “esplicito”, e non tanto il contenuto delle risposte. Deve essere tutto chiaro.

Mi chiedo sempre se c’è un ritorno probabile, in una qualunque valuta, e se quello che sto investendo è compatibile col tempo e lo spazio che ho in quel periodo, sia nella mia agenda, che nella mia testa. Se la risposta che ne esce è “sì” a entrambi, allora vado avanti e se la risposta è “no” anche solo per uno dei due, mi fermo e passo.

Non funziona sempre. A volte ho detto sì e non è venuto fuori niente di tangibile. A volte ho fatto il calcolo in fretta, mi sono fatto trascinare dal momento di una situazione senza fermarmi davvero a pensare, e ho investito più di quanto avrebbe avuto senso. Ogni volta che sbaglio è quasi sempre per quello: ho saltato il ragionamento esplicito e ho risposto d’istinto. L’istinto a volte ci prende, ma in questo tipo di valutazioni si sbaglia di più che in altre.

Il confine che non è sempre nitido

C’è una cosa che non voglio lasciare nel non detto.

Tra il scegliere di investire il proprio tempo in qualcosa che ritieni abbia un ritorno, e il trovarsi in una situazione in cui qualcuno si aspetta il tuo lavoro gratuito come default, c’è una differenza enorme. Il primo è strategia mentre il secondo è da merde (sì, hai letto bene). E credimi, la differenza tra le due è meno chiara di quanto potrebbe sembrare con una prima occhiata.

Quando qualcuno dà per scontato che tu debba fare qualcosa senza chiederti nulla esplicitamente, è un segnale. Quando una richiesta viene presentata come “un’opportunità per te”, ma il vantaggio concreto per l’altra parte è molto più definito del tuo, è un segnale. Quando ogni volta che si apre la possibilità di formalizzare il rapporto spunta fuori un motivo per rimandare, è un segnale.

Non li ho sempre visti in tempo. Ci sono stati momenti in cui me ne sono accorto quando avevo già investito più di quello che avrebbe avuto senso. Ogni volta che li riconosci prima è un po’ più facile riconoscerli la volta successiva. O almeno, questa è la versione ottimistica.

Quindi, la prossima volta che valuti qualcosa che non porta un compenso immediato, metti sul piatto tutto, non solo la voce “zero euro adesso”. Il ritorno economico differito, le competenze che costruisci, la rete che si allarga, la reputazione che si sedimenta.

Valuta tutto il contesto, non fermarti al compenso e non dire sempre sì. Il mio consiglio finale è di prendere in esame caso per caso e se ne vale la pena, buttati.

Ci vediamo nella prossima newsletter.

Senza filtri,
Chri

P.S. Costruiamo insieme Senza Filtri

Ho creato un breve sondaggio anonimo per capire come migliorare la newsletter ed esserti più utile. Se ti va di rispondere a qualche domanda clicca qui (meno del tempo di prendere un caffè). Grazie mille.

[Video Youtube] Il mercato degli MVP è morto

Il servizio con cui ho fatto metà del mio fatturato da Fractional CTO negli ultimi anni è morto in 18 mesi. Non per colpa del mercato, non per colpa dei clienti. Per colpa di Claude, Cursor, Lovable. In questo video ti racconto cosa sta succedendo al mercato del Fractional CTO, perché il vecchio modello “io costruisco il tuo MVP” non regge più.

[Guarda il video]

👋 Ciao, sono Chri. Fractional CTO e questa è Senza Filtri: la newsletter dove condivido il dietro le quinte del mio viaggio da imprenditore (esperienze, cosa ho imparato e tanti errori) alternando a qualche deep dive sui business che mi incuriosiscono.

Per capire il fenomeno di OnlyFans devi osservare cosa succedeva nel 2016.

Siamo nel pieno della creator economy: influencer su Instagram, YouTube, gente che aveva costruito in anni di lavoro gratuito un sacco di audience e seguito genuino. Monetizzare, però, era un gran casino. O eri nella top 1% e quindi ti pagavano per il product placement, oppure ti ritrovavi ad essere carne da macello per la pubblicità programmatica che ti dava due spicci ogni mille visualizzazioni.

Patreon stava provando a risolvere questo problema con il modello membership ad abbonamento mensile, in modo da far accedere gli utenti a contenuti esclusivi. Per un po’ stava funzionando anche bene per podcaster, artisti e creator generici, ma c’era un problema strutturale: nel 2017 le policy sui contenuti espliciti stavano già cominciando a diventare stringenti per non perdere i payment processor. Quindi se eri un/a sex worker, un/a performer di adult content o un/a creator che faceva roba oltre il “limite”, Patreon non era più casa tua.

La cosa scolvongente se ci pensiamo adesso è che nessuna delle piattaforme grandi aveva un payment button integrato nativamente. Su Instagram pubblicavi gratis, su Twitter pubblicavi gratis, su Snapchat pubblicavi gratis. Per farti pagare dovevi mandare la gente da un’altra parte. E in quel salto perdevi il 90% delle persone.

Quel buco era enorme e nessuno lo stava riempiendo. Praticamente è come avere un negozio dove la gente entra, prova la roba, dice “wow” e poi non hai una cassa per farli pagare.

Tim Stokely e il prestito del papà

OnlyFans nasce a Londra a novembre 2016. Il fondatore è Tim Stokely, un imprenditore inglese che prima di questa idea ne aveva già provate un paio nell’industria del mondo adult con risultati modesti. Una si chiamava Customs4U: i fan potevano chiedere video personalizzati alle performer adult, una specie di Cameo per il porno. Non sfondò, ma Stokely si fece le ossa su come funzionano davvero le transazioni intime tra creator e fan.

Il padre di Tim, Guy Stokely, ex banchiere, gli prestò 10.000 sterline per partire dicendogli, testuali parole: “Tim, questa è l’ultima volta”. Si sbagliava di brutto, ma questo Tim lo avrebbe scoperto dopo.

La visione iniziale, secondo Stokely stesso, non era il porno. Era una piattaforma social-style con un payment button integrato per qualsiasi tipo di creator. Fitness, cucina, musica, comedy. Il pitch era molto chiaro: replicare l’esperienza di Twitter o Instagram (feed, profili, messaggi) ma con la possibilità di mettere contenuti dietro un paywall granulare.

Una scelta architetturale fece il resto: dal giorno uno, per processare i pagamenti, ogni utente doveva essere maggiorenne e verificato. Questa cosa, fatta per ragioni puramente bancarie, diventò un effetto collaterale gigantesco. Avere un’utenza tutta verificata ti permette di essere molto più liberale sui contenuti. E se sei più liberale sui contenuti in un mondo dove tutti gli altri stanno stringendo le maglie, sai chi arriva da te? Esatto.

Nel primo anno OnlyFans processò 3 milioni di dollari di transazioni totali. Son tanti, ma nemmeno troppi.

Poi nel 2018 arrivò una mail.

Il pivot che nessuno ammette

La mail era di Leonid Radvinsky, un imprenditore americano che a 17 anni, dalla casa della madre in Illinois, aveva fondato un network di affiliazione per siti adult. A 22 anni gestiva MyFreeCams, una delle piattaforme di webcam adult più grosse del mondo, con oltre 100.000 modelle. Radvinsky aveva capito una cosa che a Stokely sfuggiva ancora: il futuro non era nello streaming live caotico, era negli abbonamenti asincroni basati su relazioni parasociali.

A ottobre 2018 Radvinsky comprò il 75% di Fenix International, la società che possiede OnlyFans. A novembre comprò anche il resto (la cifra non è mai stata resa pubblica).

Da quel momento il prodotto rimase identico ma la traiettoria cambiò. Nessuno ha mai detto “ok ragazzi, da oggi siamo una piattaforma per adult content”. Non c’è un memo, non c’è un comunicato stampa. Semplicemente, Radvinsky portò dentro la sua expertise nel monetizzare l’intimità digitale e la community di sex worker, che già stavano arrivando attratti dalle policy permissive, iniziò a esplodere.

Poi a marzo 2020 arrivò il COVID.

Il product-market event più grande della storia recente

Nel 2019 OnlyFans aveva 120.000 creator. Nel 2020, 1 milione. Nel 2024, oltre 4 milioni.

Gli utenti registrati passarono da 13 milioni nel 2019 a 377 milioni nel 2024.

Il volume lordo transato: 2,2 miliardi nel 2020, 7,22 miliardi nel 2024.

Quello che successe a marzo 2020 è il product-market event più potente che io abbia mai visto in tempo reale, e ne ho visti un botto negli anni ormai. L’industria del porno tradizionale si fermò. Milioni di persone persero il lavoro o si ritrovarono confinate in casa con tempo libero e disperazione finanziaria. Altri milioni si ritrovarono soli, senza socialità fisica, a cercare un’intimità qualsiasi su internet.

OnlyFans era l’unica piattaforma che aveva l’infrastruttura giusta nel momento giusto: paywall granulare, payment button integrato, policy permissive, verifica dell’età già fatta. Tutto il resto del mercato era inadeguato: Pornhub era gratuito e centrato sul video on demand, le cam erano live e caotiche, Patreon stava bandendo gli espliciti.

Quando il mercato ti esplode in mano e sei l’unico negozio aperto in città, vinci anche se non sei il più bravo. Vinci perché ci sei.

E in mezzo a quel boom, ad aprile 2020, OnlyFans fece anche il salto culturale definitivo perché persino Beyoncé infilò una riga su OnlyFans dentro “Savage Remix” di Megan Thee Stallion (”on that demon time she might start an OnlyFans”). Una singola citazione di una delle icone pop più potenti del pianeta. Solo con quella citazione portò il traffico della piattaforma su del 15% in 24 ore. Da quel momento OnlyFans smise di essere “quella cosa lì che non si nomina” e diventò argomento da talk show.

42 persone, 7 miliardi, zero app

Nel 2022 OnlyFans gestiva un volume globale di miliardi di dollari con 42 dipendenti a tempo pieno. Quarantadue, manco fossero una startup early stage. L’utile netto era di circa 15,7 milioni di dollari per singolo dipendente. Apple e Google, le aziende più profittevoli della storia del tech, si attestano storicamente tra 1 e 2 milioni di profitto per dipendente. OnlyFans li aveva fatti sembrare lenti.

Come c’erano riusciti secondo me? Tre cose.

La prima è che lo stack è banale. Backend in Node.js, frontend in React, database misto PostgreSQL per le transazioni e MongoDB per i metadati, hosting AWS con Amplify per l’autenticazione e S3 per i media. Niente di rivoluzionario. È esattamente lo stesso stack che useresti per costruire un qualsiasi SaaS. Il prodotto in sé è un Twitter con il bottone “paga per sbloccare”.

La seconda è una decisione architettonica che sembra una debolezza, ma è il vero genio del modello. OnlyFans non ha mai avuto un’app nativa per il suo prodotto principale. Le linee guida di Apple App Store e Google Play vietano categoricamente app con contenuti sessualmente espliciti. Quindi OnlyFans è rimasto un’esperienza solo web, anche su mobile. Gli utenti si fanno la scorciatoia sulla home dello smartphone e fingono che sia un’app.

Apparentemente è un disastro nell’era mobile-first ma in realtà è il colpo di genio/fortuna perché non passare da Apple e Google significa non pagare il 30% di “tassa app store” su ogni transazione. Su 7,22 miliardi di volume lordo, la tassa elusa è oltre 2 miliardi di dollari all’anno. È il motivo per cui il take rate del 20% gli basta per fare margini stellari mentre Patreon, che invece passa dagli app store, fa fatica.

La terza cosa è un pò più più subdola perché hanno creato OFTV, un’app sì regolarmente approvata su App Store e Google Play, ma che ospita solo contenuti SFW: fitness, cucina, podcast. Zero nudità. Serve a due cose: dimostrare a banche e investitori che esiste un ecosistema “pulito” attorno al brand, e funzionare da imbuto di marketing per portare nuovi utenti verso il sito web vero, quello dove si fanno i soldi. È un cavallo di Troia che ha attraversato i muri di Apple e Google indisturbato.

L’incidente Bella Thorne

Ad agosto 2020 l’attrice Bella Thorne aprì un account OnlyFans. Incassò 1 milione di dollari in 24 ore. Record assoluto.

Poi fece una cosa che le si ritorse contro in modo brutale. Mandò un messaggio privato a pagamento a tutti i suoi abbonati al costo di 200 dollari, lasciando intendere nel marketing che contenesse nudo integrale. Chi pagava sbloccava una foto in lingerie identica a quelle che lei stessa pubblicava gratis su Instagram.

Migliaia di utenti si sentirono truffati e chiesero il chargeback alla loro banca. Per chi non lo sa, il chargeback è quando contesti l’addebito sulla carta di credito. Per un business adult, classificato dalle banche come “high risk merchant”, una valanga di chargeback è un evento estintivo: Visa e Mastercard hanno soglie precise oltre le quali ti chiudono l’account.

OnlyFans dovette reagire in 48 ore con misure punitive applicate a tutti, retroattivamente. Tetto massimo ai PPV abbassato da 200 a 50 dollari. Mance massime limitate a 100 dollari. Ciclo di pagamento ai creator esteso da settimanale a 30 giorni di attesa.

I sex worker che vivevano di quella piattaforma, quelli che avevano costruito la valutazione miliardaria, si ritrovarono dall’oggi al domani con liquidità mensile invece che settimanale e tetti che gli dimezzavano i guadagni. Tutto perché una celebrità entrata per due settimane aveva fatto un esperimento di marketing aggressivo.

Questo ti fa capire che i tuoi power user costruiscono il valore, ma chi ti rompe l’ecosistema sono quasi sempre i casi marginali ad alta visibilità. E le policy alla fine le fai pensando a loro, non a chi ti ha portato fin lì.

La quasi-morte: agosto 2021

Il momento in cui OnlyFans è stato più vicino all’estinzione non c’entra niente con la concorrenza. C’entra con le banche.

A dicembre 2020 un’inchiesta del New York Times rivelò che su Pornhub circolava materiale di abuso minorile. Mastercard, Visa e Discover staccarono i pagamenti a Pornhub nel giro di 48 ore. Pornhub dovette eliminare il 70% dei video dalla piattaforma in una notte.

OnlyFans guardò la scena e si terrorizzò. Se le carte di credito decidono di staccarti, non hai un business. Non hai più niente. Hai un sito che non può incassare un euro.

Il 19 agosto 2021 OnlyFans annunciò che a partire dal primo ottobre avrebbe bannato tutti i contenuti sessualmente espliciti. La motivazione ufficiale, data al Financial Times: “pressioni ingiuste dei partner bancari”.

Quello che successe nei giorni dopo è uno dei casi studio più affascinanti di power dynamics su internet. I creator, l’ACLU, il collettivo Hacking//Hustling presentarono esposti alla Federal Trade Commission. Si organizzò una rivolta della community. La stampa pubblicò pezzi durissimi confrontando OnlyFans con Tumblr, che nel 2018 aveva bannato il NSFW e aveva perso il 30% del traffico in una settimana, finendo svenduta a 3 milioni di dollari.

Sei giorni dopo l’annuncio, OnlyFans fece marcia indietro. Tweet di scuse, “abbiamo ottenuto le rassicurazioni necessarie dai partner bancari”. Nessuno ha mai spiegato cosa fosse cambiato però... chissà...

Apriamo gli occhi un attimo, perché questo accaduto fa riflettere.

Tutti pensano che il potere su internet sia nelle piattaforme: Meta, Google, Amazon. La verità è che il potere vero è uno strato sotto, nei payment processor. Visa, Mastercard, Stripe. Possono spegnerti un business da 7 miliardi in 24 ore senza dare spiegazioni a nessuno. La tua infrastruttura tecnica perfetta, il tuo prodotto amato, la tua community fedele non valgono niente se Mastercard decide che sei “high risk” e ti stacca i pagamenti.

A maggio 2026 OnlyFans ha venduto il 16% ad Architect Capital per 535 milioni. Il pitch dell’operazione, raccontato dai CEO, è usare quei soldi per costruirsi un’infrastruttura finanziaria autonoma, prestiti e servizi bancari diretti ai creator. Stanno cercando di smettere di dipendere dalle banche diventando una banca. E ha senso se ci pensi, è l’unica mossa che resta.

Il lato oscuro: i chatter e l’illusione dell’intimità

C’è una parte di OnlyFans che la narrazione “creator economy + empowerment” non racconta mai.

Il prodotto che OnlyFans vende davvero non è il porno. Il porno è gratis ovunque su internet, non avrebbe senso pagarlo qui. Quello che vende è l’illusione della connessione intima personale. Il fan paga perché crede di star parlando direttamente con la creator nei DM, di star costruendo una relazione, di star ricevendo attenzione personalizzata.

Il problema è che quando una creator inizia a fare numeri seri, i DM diventano umanamente ingestibili. Quindi appalta la gestione dell’account a quelle che si chiamano “OnlyFans agencies”. E queste agenzie assumono “chatter” che operano dalle Filippine, dall’India, dal Sud America. Pagati 2 dollari l’ora, in turni di 8 ore, gestiscono in parallelo decine di conversazioni fingendosi la creator. Conoscono a memoria la sua biografia finta, simulano il suo tono, mappano le vulnerabilità del cliente (la sua solitudine, i suoi problemi di lavoro) e le sfruttano per spingere PPV da 50 dollari.

L’intera catena è un dispositivo industriale per estrarre soldi dalla solitudine maschile contemporanea. Il fan paga per un’empatia che non esiste. La creator a quel punto è solo il volto sul profilo, separata dalle chat che le pagano l’affitto. Il chatter è un impiegato sottopagato del Terzo Mondo che produce finta affezione lavorando su KPI di vendita.

E adesso le agenzie più aggressive stanno passando agli LLM. Cioè a chatbot AI che simulano la creator H24 senza pause, senza stipendio, senza supervisione umana. Stanno automatizzando l’industria dell’intimità sintetica.

Quando senti la narrazione “OnlyFans è empowerment”, ricordati che il guadagno mediano di un creator sulla piattaforma è 180 dollari al mese. La distribuzione è una power law perché il top 1% incassa oltre un terzo del totale. Tutto il resto è gente che guadagna meno di un lavoro part-time, in cambio di un’impronta digitale incancellabile.

Ci siamo: cosa ci portiamo a casa?

Quello che mi resta in testa di questa storia, dopo averla studiata, è prima di tutto la cosa del pivot non dichiarato. Stokely ha sempre detto che OnlyFans non era stata costruita per l’industria adult. Tecnicamente è vero, era una piattaforma generica. Ma quando il mercato vota con il portafoglio per un certo uso, ed è chiaro che lì c’è il product-market fit, hai due scelte: combatti il pivot per difendere la tua visione originale, oppure lo assecondi silenziosamente senza farlo diventare un comunicato stampa. Stokely ha scelto la seconda, Radvinsky l’ha accelerata. Patreon ha scelto la prima e si è fatta scappare un mercato da 7 miliardi.

Altra cosa che ho notato è quella dei mercati taboo come fossato competitivo. Quando il caso d’uso è socialmente stigmatizzato, le Big Tech non possono entrare. Meta non può tollerare il NSFW perché Coca-Cola, Disney e Procter & Gamble si arrabbierebbero e perderebbe consenso. Google non può ospitarlo perché altrimenti perderebbe gli inserzionisti. App Store e Play Store non lo accettano. Lo stigma stesso diventa la barriera all’ingresso. Snapchat è cresciuto sul sexting, Tinder sull’hookup, Reddit sui sub NSFW. Il tabù è un fossato che le aziende rispettabili non possono attraversare anche quando ne avrebbero la capacità tecnica.

Grazie a Onlyfans possiamo dire che il vero potere infrastrutturale non è dove credi che sia. Tu pensi sia in AWS, in Google, in Microsoft. È in Visa e Mastercard. Sono loro che decidono chi può esistere come business su internet. È una cosa che vale anche per i clienti più piccoli che seguo: ogni volta che qualcuno mi dice “ho costruito un business sopra Stripe” o “tutto il mio fatturato passa da PayPal”, io mi chiedo cosa succede il giorno in cui per qualche motivo ti staccano. OnlyFans sta vendendo quote a investitori finanziari specializzati per affrancarsi proprio da questa dipendenza. È una mossa che dovrebbe studiare chiunque operi in settori controversi.

In conclusione

Ogni prodotto ha un uso che il founder è imbarazzato a raccontare alla suocera. A volte è un bug, a volte è una nicchia divertente, a volte è il vero motivo per cui il prodotto cresce.

Stokely voleva costruire un Patreon più flessibile. Il mercato ha votato per altro. Lui non ha combattuto, ha lasciato fare, e nel mezzo è diventato miliardario.

La cosa più scomoda della storia di OnlyFans, almeno per chi come me lavora su prodotti tutti i giorni, è proprio questa: il successo non è arrivato perché qualcuno ha avuto una visione, è arrivato perché qualcuno ha smesso di difenderne una. E quando ci penso, sento che è una lezione che vale per qualsiasi prodotto si stia costruendo oggi, anche per quelli che con i mercati tabù non c’entrano niente.

Ci vediamo alla prossima newsletter.

Senza filtri,
Chri

P.S. Costruiamo insieme Senza Filtri

Ho creato un breve sondaggio anonimo per capire come migliorare la newsletter ed esserti più utile. Se ti va di rispondere a qualche domanda clicca qui (meno del tempo di prendere un caffè). Grazie mille.

👋 Ciao, sono Chri. Fractional CTO e questa è Senza Filtri: la newsletter dove condivido il dietro le quinte del mio viaggio da imprenditore (esperienze, cosa ho imparato e tanti errori) alternando a qualche deep dive sui business che mi incuriosiscono.

Una delle domande che mi fanno più spesso ultimamente è “Te che sei nerd di computer, come usi l’AI per lavorare?”.

E ci sta, perché di chiacchiere generiche sul tema ne girano un botto. Ci sono tanti che parlano di AI come se la usassero seriamente, pochi però che mostrano completamente tutto senza comprare un corso (furbacchioni).

Quindi questa newsletter è il tentativo di rispondere una volta per tutte. Sei aree del mio business, una per sezione. Tool nominati per nome e cognome (stile Conte in pandemia), workflow preciso con immagini e riferimenti.

Partiamo però dal framework di base generico che è comune a tutte le aree.

Il “mio” framework AI

Per tanti mesi io con l’AI ho fatto la stessa cosa che fanno tutti: aprivo una chat, scrivevo una richiesta, ottenevo una risposta. A volte buona, a volte mediocre, a volte da buttare. Il problema era che la qualità del risultato sembrava casuale, e quando ti capita di buttare via il 40% di quello che ottieni, smetti di fidarti dello strumento. È così che la maggior parte delle persone si convincono che “l’AI non è ancora pronta”, perché l’hanno usata in modo non strutturato e si sono rotti i coglioni di setacciare l’output.

Spinto dal migliorare questa cosa, ho trovato quello che fa il team di Every con il loro approccio al compound engineering. L’idea, riassumibile in due righe, è questa: invece di usare l’AI come un assistente al quale chiedi una mano per il singolo task, la usi come un sistema che si auto-rafforza, dove ogni esecuzione produce contesto utile per le successive, e dove gli agenti AI fanno review del lavoro di altri agenti AI prima che il risultato arrivi a te.

Tempo 0 secondi ho “rubato” il metodo, l’ho riadattato al mio lavoro, e da lì in poi tutto è cambiato. Quello che è uscito dalla mia versione del framework sono quattro fasi che ormai applico, con sfumature diverse, a praticamente ogni attività del mio business.

FASE I: il contesto. Prima ancora di chiedere all’AI di fare qualcosa, decido quali informazioni le devo passare e da dove devono arrivare. Knowledge base di un cliente, transcript di una call, documento markdown con i requisiti, esempi di output passati che mi sono piaciuti, vincoli operativi.

Dentro il contesto ci sono due tipi di informazioni diverse, ed è importante distinguerle. Una parte è dinamica e cambia da task a task: i dati specifici del cliente di turno, i requisiti del singolo lavoro, le ultime call. Un’altra parte è invece statica, e sono le regole di base di quell’area. Ogni area del mio business ha uno o più file markdown specifici che descrivono cose come gli anti-pattern da evitare assolutamente, le convenzioni che voglio rispettare sempre, i vincoli operativi che non cambiano mai. Per il contenuto sono la mia style guide e il file degli anti-pattern di scrittura. Per il codice di un progetto sono le convenzioni del repository, gli ADR storici, i pattern vietati. Per le offerte sono i template di servizio, le condizioni standard, i pricing di riferimento. Sembra una banalità, ma se l’AI non le ha in contesto le ignora puntualmente, e tu te ne accorgi al primo output.

Se il contesto è generico, il risultato è generico. Se il contesto è preciso, beh… puoi immaginare.

FASE II: la pianificazione del task. Prima di toccare l’esecuzione vera e propria, ragiono con l’AI su cosa significa quel task. Quali sono i requisiti, gli edge case, l’output atteso, i vincoli, gli step. Questa fase produce un piano scritto, di solito in markdown, a volte in HTML quando voglio renderlo navigabile (perché HTML te lo faccio dire da lui). Il piano diventa l’input strutturato della fase successiva. È la fase che ha più impatto sulla qualità finale, ed è quella che la maggior parte delle persone salta perché sembra “perdere tempo prima di iniziare”, in realtà è dove si fa il vero lavoro.

FASE III: l’esecuzione. A questo punto l’AI esegue sul piano. È la fase più visibile, ed è anche quella di cui parla la maggior parte della gente, ma è la meno strategica delle quattro. Se contesto e pianificazione sono fatti bene, l’esecuzione è (quasi) automatica. Se sono fatti male, l’esecuzione produce un risultato che sembra buono al primo sguardo e si rivela inutilizzabile alla seconda lettura.

FASE IV: la review, ed è doppia. C’è la review umana, dove sono io a leggere, correggere, integrare, ridire. E c’è la review fatta da un altro agente AI, separato da quello che ha eseguito, con istruzioni e focus diversi. È il pezzo che ho preso più di tutti da Every: avere un agente che fa review del lavoro di un altro agente prima che il risultato arrivi a me. Significa che quando lo vedo io, ha già passato un primo filtro che intercetta gli errori stupidi e mi fa concentrare sulle cose che davvero richiedono il mio giudizio.

Le sei aree che ti racconto adesso sono tutte costruite sopra questo scheletro. Cambia il tipo di contesto, cambia la pianificazione, cambia chi fa la review e con che criteri. Ma le quattro fasi sono sempre lì.

1. Il core business: la tecnologia

Per anni il mio lavoro da Fractional CTO era stato “non sviluppo più, faccio strategia, advisory, decisioni architetturali, gestisco team” (detto alla brutta). L’idea di rimettere mano direttamente al codice di una startup era fuori scope. Lo delegavo, scrivevo le specifiche, facevo review delle PR, correggevo le scelte e nei casi peggiori riscrivevo io stesso alcune parti perché era più veloce farlo che spiegarlo.

Oggi con l’AI le cose sono un po’ cambiate. Perché adesso son tornato molto più in prima linea riuscendo a portare valore come CTO e come sviluppatore (non lo faccio per tutti ovviamente, impazzirei). Ma il valore che riesco a portare ora è davvero 3x rispetto a prima.

Lo stack è questo semplice: Claude Code e Codex (cento dollari al mese ciascuno, sono i due abbonamenti più produttivi che ho mai pagato), più Cursor che tengo nella versione free perché lo uso solo per fare review del codice generato, non per generarlo. Il set di skill è quello di Every:Compound Engineering (non mi invento nulla)

Sul fronte contesto, per ogni progetto cliente ho un set di markdown che descrive l’architettura, le convenzioni di codice, i pattern accettabili e quelli vietati, le regole di branching, i tool di testing usati, gli ADR (architectural decision records) presi nel tempo. Quando lancio un task, il coding agent ha già tutta questa roba caricata in contesto, e non parte mai da zero come se fosse appena arrivato sul progetto. È la differenza tra dare un task a un dev senior che è in azienda da due anni e darlo a uno che è arrivato il giorno prima.

Quando un cliente ha più repository (tipicamente frontend, backend, magari una mobile app e magari altri servizii separati), il contesto non può vivere solo dentro i singoli repo, perché un sacco di task sono full-stack e toccano due o tre repository contemporaneamente. Quindi mantengo una cartella docs nella root folder del cliente, condivisa tra tutti i repo, con tutto il contesto trasversale: architettura ad alto livello, contratti API tra servizi, convenzioni di naming condivise, ADR che valgono per più di un repo, modelli dati cross-servizio. Poi ogni singolo repo mantiene la sua docs interna con quello che è specifico solo a lui. Quando il coding agent lavora in modalità full-stack parte dalla docs della root e scende nelle docs dei singoli repo che sta toccando, quando lavora su un repo solo va direttamente lì. È un accorgimento di struttura piccolo, ma fa la differenza tra un agent che capisce il sistema e uno che capisce solo il pezzo che ha sotto gli occhi.

Sul fronte pianificazione, prima di toccare codice faccio brainstorming tecnologico con l’AI. Output del brainstorming: o un markdown strutturato che diventa input per l’agent, oppure un HTML leggibile che apro in browser, scrollo, verifico, correggo. L’HTML è la parte che cambia tutto, perché vedere un piano formattato e navigabile è completamente diverso da rileggere il proprio Google Doc lungo tre pagine. Vedi subito se la struttura regge, dove sono i buchi, quali decisioni non hai ancora preso.

Solo dopo che il piano è validato, il coding agent esegue. E qui entra in gioco la review automatica: prima ancora che io guardi il risultato, il codice generato passa per un secondo agente configurato come reviewer, con un prompt focalizzato su errori comuni nel tipo di task corrente (migration, refactor, nuova feature, fix), su pattern vietati nel progetto, su rischi di regressione. Solo dopo questo passaggio il risultato mi arriva in mano per la review umana finale.

Sembra macchinoso a parole, ma il setup lo fai una volta e poi gira. E il risparmio in cose stupide intercettate prima del mio occhio è enorme.

Ti faccio un esempio concreto. Ho lavorato per un cliente ad una migrazione da MongoDB a PostgreSQL. Lavorone enorme: ripensare lo schema dati, riscrivere le query, gestire la transizione infrastrutturale, la migrazione dei dati in produzione e (ovviamente) testare tutto. Il tipo di progetto che sei mesi fa avrei delegato completamente a uno sviluppatore, seguendolo passo passo, facendo call di kickoff e discutendo se quell’indice serviva davvero o se fosse una prematura ottimizzazione.

Questa volta ho fatto diversamente, lavorando in autonomia end-to-end con l’AI. Risultato sbalorditivo, migrazione fatta in 2 mesi. Su questo farò un articolo separato, perché è andato tutto liscio (più o meno).

Il cambiamento concreto è che il ciclo tra “penso una cosa” e “vedo il risultato funzionare” è passato da giorni a minuti. C’è stato un momento in cui ho cambiato idea su come gestire una relazione nel database. In un flusso tradizionale avrei scritto un commento sulla PR, aspettato che il collega la leggesse, aspettato l’alternativa, fatto review dell’alternativa. Qui ho cambiato idea, aggiornato il piano, fatto rilanciare l’agent sulla parte impattata, testato la nuova struttura. Venti minuti.

La confidence che hai nel gestire questo tipo di attività cambia completamente. Decidi cose che prima non avresti deciso, perché il costo di provare era troppo alto.

2. Content creation: il Content OS

Tutto quello che pubblico, dalla newsletter che stai leggendo al video del venerdì su YouTube, ai post LinkedIn delle mattine, esce da un repository che ho chiamato Content OS.

Il Content OS è un progetto in markdown che ho costruito apposta per me, con cartelle organizzate per piattaforma e per status (idea, in progress, to review, published), e un set di skill custom che ho scritto per le fasi del workflow.

Anche qui le quattro fasi del framework valgono, basta sostituire “codice” con “contenuto”.

Il contesto, in questo caso, è una style guide in markdown lunga un paio di centinaia di righe che descrive il mio tono di voce, le espressioni che uso, i riferimenti culturali che faccio (che non prende mai, ‘sto fango…), le strutture di apertura e chiusura che funzionano. Più un secondo file di anti-pattern che elenca le cose da non fare mai (frasi da guru motivazionale, simmetrie forzate, tic da AI tipo “Non è X, è Y”). E infine gli ultimi cinque-dieci post pubblicati, che servono da riferimento per l’evoluzione recente dello stile. La style guide è anche lei un file che si auto-aggiorna ogni volta che pubblico un nuovo pezzo: una skill confronta il post appena pubblicato con la guida attuale e aggiunge i pattern nuovi che ha riconosciuto.

La pianificazione è il momento in cui un’idea grezza diventa un brief strutturato. Scrivo /idea capture e cattura il pensiero. Scrivo /write brainstorm e parte una sessione di domande e risposte che mi aiuta a tirare fuori storia, esempi concreti, frasi forti. Da lì arrivo al brief con angolo, hook, struttura a sezioni.

Quello che fa la vera differenza in questo processo è che tutto questo non lo faccio scrivendo, ma lo faccio a voce. Uso VoiceInk, un tool di dettatura AI per Mac che trasforma la voce in testo in tempo reale dentro qualsiasi text input mi serva. La differenza tra scrivere e parlare, quando si tratta di creare contenuti, è abissale e me ne sono accorto solo dopo averla provata seriamente.

Quando parli, ragioni a voce alta e non costruisci la frase perfetta, racconti. E quando l’AI ti fa domande di follow-up sui dubbi che hai espresso, sui passaggi che hai dato per scontati, sugli esempi che non hai fatto, ti costringe a razionalizzare cose che nella tua testa erano implicite. È letteralmente un’intervista, dove l’AI fa il giornalista e io faccio l’intervistato. In una singola sessione di mezz’ora a voce, di solito tiro fuori il materiale per due o tre contenuti diversi, perché un’idea ne apre un’altra e una domanda di follow-up porta su un filone nuovo.

Per me questa è la cosa più sottovalutata di tutto l’uso dell’AI lato content. L’AI qui non sta scrivendo al posto mio (sarebbe terribile e si vedrebbe subito alla prima parola). Mi sta intervistando e mi sta aiutando a mettere a terra la competenza e il valore che ho già, ma che da solo non saprei verbalizzare con la stessa pulizia. Quello che esce dall’esecuzione successiva è poi figlio di quella conversazione registrata, non di una mia richiesta a freddo.

L’esecuzione è /write draft e mi tira fuori una prima bozza nel mio tono. Non è quasi mai pubblicabile così com’è, ma è un punto di partenza che mi farebbe perdere una mezza giornata a partire dal foglio bianco.

La review è doppia. /review lancia un agente che controlla il draft contro la style guide e gli anti-pattern, mi segnala dove ho frasi che puzzano di AI, dove la struttura è troppo simile ai post precedenti, dove l’argomento sta diventando da life coach generico invece che da Fractional CTO. Poi entro io con la review umana finale cambiando cose e riscrivendo paragrafi.

E quando arriva il momento, sincronizzo su Notion per farmi aiutare con un’ulteriore review da parte di Veronica con un bel /sync push. /sync pull fa il viceversa quando loro hanno aggiornato lo stato di un pezzo.

Probabilmente questa newsletter è uno degli esempi più concreti che ti capiterà di leggere quest’anno: una newsletter scritta dentro un sistema che ho costruito io per scrivere newsletter, dove ti sto raccontando il sistema stesso. Inception spostati.

E lo stesso Content OS gestisce anche tutta la parte di acquisizione, che è una delle leve che ho aperto più di recente: i lead magnet li genero molto più velocemente, le thumbnail della newsletter e del canale YouTube le tiro fuori con Higgsfield e i caroselli LinkedIn li produco partendo dal contenuto principale.

[Se ti sta piacendo la newsletter e non sei iscritto, è il momento giusto per farlo]

Iscriviti ora

3. Discovery e knowledge clienti: Fathom + Business OS

Ogni call con un cliente, sia di discovery che operativa, viene registrata. Il tool che uso è Fathom, un note taker AI che oltre a generare il transcript ti dà anche action items e riassunti automatici. Costa il giusto e funziona meglio degli altri che ho provato.

Il transcript però non lo uso così com’è. Per me è materia prima.

Per ogni cliente ho una cartella dentro un secondo progetto markdown che ho chiamato Business OS. Dentro quella cartella ci sono tutti i transcript delle call con quel cliente, le decisioni prese e perché, il contesto storico (chi sono, cosa fanno, dove stanno andando), i pattern che ho osservato (come comunicano, dove fanno fatica, su cosa girano in tondo), le persone chiave, le rogne aperte, i deliverable concordati, gli ADR di business. Tutto strutturato in modo che un agente possa pescarlo e usarlo come contesto.

Sopra quella knowledge base ci ragiono con l’AI. Prima di una call operativa con un cliente lancio una skill che fa una cosa specifica: pesca le ultime due o tre call con quel cliente, le mette in fila con quello che era rimasto in sospeso e mi tira fuori una mini-agenda con tre o quattro punti da affrontare ordinati per urgenza. In cinque minuti ho il contesto pieno di un cliente.

Prima di una discovery con un cliente nuovo, il flusso è diverso. Carico in contesto le informazioni che ho su di loro (sito, eventuali documenti che mi hanno mandato, contesto sull’industry), e faccio brainstorming sul tipo di outcome che potrebbero servire. Esco dalla discovery con domande già in testa, ipotesi da verificare, e una mappa mentale di dove probabilmente sta il valore. Questo cambia completamente la qualità della call. Non sto più ascoltando per la prima volta tutto, sto verificando ipotesi e cercando segnali che confermino o smontino quello che già mi ero immaginato.

A questo punto la review è meno automatica e più umana, perché siamo sul fronte relazionale e il mio giudizio diretto conta di più. Però anche qui ho un secondo agente che, dopo la call, prende il transcript fresco e lo confronta con la knowledge base esistente: segnala se ci sono contraddizioni con quello che mi avevano detto prima, decisioni che hanno cambiato, persone nuove menzionate, rischi che si stanno alzando. Roba che a occhio nudo dopo una giornata di call ti sfugge.

Ah e una piccolezza, ho un’automazione su n8n che analizza il transcript e estrapola una lista di to do che poi mi mette direttamente su Notion (se sono riferiti a me).

4. Sales: offerte HTML personalizzate

Sempre dentro Business OS c’è una sezione dedicata alle offerte, e questa è la parte dove il framework cambia un po’ di forma. Ti racconto come funziona, in ordine.

Quando arriva il momento di pitchare un cliente, parto con tutto il suo materiale già caricato in contesto (transcript di discovery, mappa degli obiettivi, vincoli espressi, persone coinvolte, segnali su budget e tempistiche) più i miei template di servizio (pacchetti, deliverable tipici, prezzi di riferimento, condizioni standard). A quel punto, prima ancora di generare l’offerta, decido con l’AI quale taglio darle. Stesso servizio, ma per un cliente in early stage lo strutturo diversamente rispetto a un cliente in fase di scale. Per un founder tecnico parlo di una cosa, per un founder business di un’altra.

Solo quando il taglio è chiaro, l’AI genera l’offerta in HTML, strutturata come un mini-sito a sezioni: contesto del cliente, obiettivi che andremo a coprire, servizi inclusi, deliverable misurabili, retainer mensile, durata. La pubblico su offers.christianvarisco.com con un accesso privato protetto da password. Il cliente riceve un link, entra, naviga l’offerta come fosse una landing dedicata a lui, e se vuole può scaricarla in PDF direttamente dalla pagina.

Prima che il cliente la veda, però, l’offerta passa per un secondo agente reviewer che fa un check di coerenza: ogni sezione è allineata con i dati del cliente, non ci sono deliverable promessi che poi non compaiono nel pricing, il pricing è allineato ai miei template. Solo dopo entro io, rileggo, aggiusto il tono dove serve, taglio le parti che diventano troppo generiche.

Perché lo faccio così? Perché un’offerta in HTML spacca 100 volte di più di un PDF sepolto in una cartella Drive che il cliente non aprirà mai più dopo la prima call. È sempre online, sempre aggiornata e il cliente può tornarci in qualsiasi momento senza dover frugare nelle mail. Ma soprattutto, quando un cliente la riceve, già da come è confezionata capisce che dall’altra parte non c’è un quaqquaraquà qualsiasi con un template scaricato da Canva. È un segnale (prego eh).

5. Amministrazione: autofatture e tool esteri

Questa è la parte meno glamour della newsletter, ma forse quella che mi fa risparmiare più tempo psicologico al mese.

Lavoro con un sacco di tool americani o comunque esteri. Ogni mese tra Claude Code, Codex, Fathom, Higgsfield, server, dominio, AWS e altri tool minori, mi ritrovo con una decina di fatture da paesi diversi che il commercialista deve poter usare per fare autofatture.

Una volta era una rottura pazzesca. Aprivo le mail una per una, scaricavo i PDF, li rinominavo a mano, li mettevo in una cartella Drive seguendo un naming consistente che ovviamente sbagliavo tre volte su dieci, manco fossi un archivista alle prime armi, mandavo il link al commercialista, gli rispondevo alle domande quando mi diceva che una fattura non si capiva di chi era. Tempo totale: una mezza giornata al mese di lavoro morto, da fare puntualmente in fondo al mese quando hai zero voglia di farlo.

Adesso c’è un’automazione (anche questa scritta come skill custom) che fa tutto il flusso. Pesca le mail con allegati che provengono dai provider che le emettono, riconosce il tipo di documento (fattura, ricevuta, note di credito), lo rinomina, lo mette nella cartella Drive del mese corrente. Il commercialista entra in cartella, prende tutto e ci fa quel che vuole.

La review è banale ma c’è: ogni mese guardo il riepilogo per quindici minuti, controllo che gli importi tornino con quello che mi aspetto di aver speso, e se qualcosa non quadra vado a guardare la singola fattura. Fine.

Non è sexy. Ma quelle due orette di lavoro morto al mese, moltiplicata per dodici, son 3 giorni di vita all’anno che ora passo in maniera più produttiva (guardo i tik e tok).

6. Strategy: l’AI come socio

L’ultima area è anche quella un pò più strana se vogliamo, perché è quella che si avvicina di più al tipo di lavoro che teoricamente è “il mio”.

Pensiero strategico sul business. Decisioni di posizionamento. Lettura del mercato. Capire dove sta andando il mondo dei Fractional, cosa stanno facendo gli altri (sì, vi osservo tutti) e dove c’è spazio per differenziarsi. Capire quando vale la pena aprire una nuova linea di servizio e quando invece sto perdendo terreno.

Per tanto tempo questa era la parte che mi tenevo strettissima, perché “è quella in cui aggiungo valore”. Poi mi sono accorto che fare tutto da solo nel proprio cervello ha un sacco di limiti tra cui: confirmation bias, blind spot, mancanza di confronto reale con un interlocutore che ti dica “guarda che non torna” senza temere di farti incazzare.

L’AI in questa fase è diventata quasi un socio.

Tutto parte da una cartella dentro Business OS dove tengo strutturati i numeri del business (ricavi, marginalità, mix dei clienti), gli obiettivi annuali, le decisioni strategiche prese (e quelle scartate, con il perché), le riflessioni che ho buttato giù nei mesi precedenti, i feedback dei clienti, i pattern che ho osservato nel mercato. È il backup esterno del mio cervello da Fractional, ed è il primo input che entra nelle sessioni strategiche.

Da lì in poi il framework cambia un po’ forma, perché in fase strategica non pianifico un task e poi lo eseguo separatamente, ma ci ragiono su. Discuto a voce alta con Claudio (lo chiamiamo tutti così dai), buttiamo giù mappe, scenari e contro-argomenti. A volte gli delego ricerche di mercato vere e proprie: “guarda come si sta posizionando il mondo del Fractional CTO in Italia, fammi una mappa dei competitor diretti e adiacenti, identifica le narrative emergenti, segnalami dove vedi pattern che non sto cogliendo”. Roba che sei mesi fa avrei dovuto fare a mano io, o pagare una caterva di soldi a qualcuno per farla.

Sulla review invece il framework si conferma, ma con una variante che vale solo qui. Sul fronte strategico non lascio fare a un altro agente, perché la qualità del giudizio dipende dal contesto profondo del business e da pezzi di intuito che fatico anche solo a verbalizzare. La review me la faccio io con un trucchetto: rileggo i ragionamenti a distanza di una settimana. Spesso quello che mi era sembrato brillante una settimana fa, riletto a freddo, è un’idea normale o addirittura sbagliata.

Il punto qui, per essere chiari, è che decido sempre io. Ma avere un interlocutore competente, che non ha agenda, che non si stanca, che ricorda tutto, che ti porta dati freschi quando serve, è una cosa profondamente diversa rispetto al ragionare da solo. Anche solo come sparring partner.

Ora, le riflessioni

Detto tutto il pratico, ci sono un paio di cose da dire, che fanno parte del pezzo tanto quanto i tool e i workflow.

Sono diventato dipendente dall’AI.

Non è un’esagerazione retorica. Se domani mattina mi togliessero tutto, dovrei riadattarmi a un modo di lavorare che ormai non ricordo più. E lo ammetto, farei fatica. Sarei meno produttivo, meno lucido, meno autonomo su una marea di cose che ho disimparato a fare da solo.

E qui sta il paradosso. Questa dipendenza è esattamente quello che mi ha permesso di evolvere il business. Sono indipendente su attività che prima avrei dovuto delegare a persone da gestire, da onboardare, da pagare anche nei mesi in cui non c’erano abbastanza progetti da giustificarle. L’AI ha reso il mio business più sostenibile, più piccolo e forse ancora più mio.

E qui c’è una seconda riflessione che mi gira in testa da quando ho letto una newsletter recente di Elena Verna (se non sai chi è, male). Elena ha ribadito un concetto di cui si parla da un pò: la HI-C, High-Impact Individual Contributor. L’idea è che il vecchio modello di carriera (più persone sotto di te, più impatto hai) sta diventando obsoleto. La nuova carriera ad alto impatto può essere quella di un IC che ha le competenze e gli strumenti per portare un progetto end-to-end senza un team intero dietro. Lei stessa è tornata IC dopo essere stata VP, e racconta che dopo qualche mese di disorientamento (la classica domanda “ma mi sto promuovendo o mi sto demolendo lo status?”) ha capito che è stata la scelta più giusta della sua carriera recente.

Leggendola mi sono accorto che è esattamente quello che sta succedendo a me, in piccolo. Senza un cambio di titolo, senza un annuncio, ho avuto una mini epifania: dove posso, sto tornando IC. Non ho rinunciato al ruolo di Fractional CTO, ma alcune cose che prima mi serviva delegare per averle, adesso conviene farle io con un coding agent o con uno stack di skill custom. È un altro modo di fare impatto, e probabilmente è più allineato a come mi piace davvero lavorare di quanto lo fosse il modello “salgo nella scala, gestisco più persone, tocco meno mestiere”.

E non è solo qualcosa che riguarda me. Qualche giorno prima di leggere quella newsletter di Elena, in una chat su Slack con un cliente che mi chiedeva come strutturare il team di prodotto avevo scritto quasi alla lettera lo stesso concetto (alla brutta).

Poi quando ho letto quella newsletter di Elena, qualche giorno dopo, mi sono accorto che stavo proponendo esattamente la stessa cosa: spostare l’impatto dalle scale gerarchiche al singolo che porta a termine il progetto end-to-end, con l’AI come moltiplicatore di possibilità. Quindi è un pattern che non sto solo vivendo in prima persona, è un pattern che sto consigliando attivamente anche nei team dei miei clienti.

Penso che oggi un business di questo tipo (fractional, consulenza, freelance, scegli il termine che preferisci) sia molto più facile da far partire da soli rispetto a cinque anni fa. La parte operativa la deleghi, la parte di giudizio la tieni. Ed è la parte di giudizio quella che il cliente sta comprando.

Però attenzione, perché il rovescio della medaglia esiste eccome.

L’AI è un moltiplicatore. Moltiplica quello che già sai fare. Se hai vent’anni di esperienza tecnica, l’AI ti fa lavorare come se ne avessi quaranta. Se di esperienza ne hai poca, ti fa sembrare un junior dignitoso quando i task sono semplici, e crolla subito quando i problemi diventano interessanti. Quello che viene moltiplicato sono sempre le tue competenze e il tuo giudizio. Senza la base, lo stack che ti ho raccontato è inutile, e probabilmente anche pericoloso.

E resta che sono ancora io quello che decide cosa costruire, per chi, in che ordine, con che criterio. Il giorno in cui l’AI si avvicinerà bene a quella parte là, dovrò ripensare di nuovo tutto. Ma non è oggi. E preoccuparmi adesso di quel giorno mi sembra solo un modo per non sfruttare la finestra che ho davanti.

Lo stack, per chi lo vuole copiare

Per chi è arrivato fin qui e vuole la lista pulita: Claude Code e Codex per il coding agent, Cursor free per la review del codice generato, Fathom per le call con i clienti, Gemini come chat classica (incluso in Google Workspace), Higgsfield per le thumbnail di newsletter e YouTube, Notion come database condiviso (senza Notion AI, non l’ho mai trovato all’altezza), più due repository markdown costruiti su misura (Content OS per i contenuti, Business OS per il resto) sopra una serie di skill scritte da me.

Niente di tutto questo è copiabile uno a uno. Il valore non sta nei tool, sta nelle quattro fasi che applichi sopra. I tool cambieranno tra sei mesi, garantito. Il framework lo costruisci solo tu, su misura del tuo lavoro, dei tuoi clienti, del tuo modo di pensare. Però se ti aspettavi di vedere “i 5 tool AI che usa un fractional CTO”, almeno adesso li hai.

Rispondi a questa mail e condividilo agli amici, sono davvero curioso di sentire come la stai vivendo dal tuo lato. Soprattutto se la stai vivendo diversamente da me.

Ci vediamo alla prossima newsletter.

Senza filtri,
Chri

P.S. Costruiamo insieme Senza Filtri

Ho creato un breve sondaggio anonimo per capire come migliorare la newsletter ed esserti più utile. Se ti va di rispondere a qualche domanda clicca qui (meno del tempo di prendere un caffè). Grazie mille.

[Video Youtube] La moda dei “Fractional”: perché tutti lo scrivono ma sbagliano

Oggi chiunque usa la parola Fractional. Secondo me stiamo sbagliando parola, e stiamo svuotando un concetto che ha un senso preciso. In questo video racconto da dove nasce il Fractional, che esigenza risolve davvero, e perché la C di "chief" non è un dettaglio ma è esattamente il punto. Non è una lezione, è il mio punto di vista. Ognuno poi si chiama come vuole.

[Guarda il video]

👋 Ciao, sono Chri. Fractional CTO e questa è Senza Filtri: la newsletter dove condivido il dietro le quinte del mio viaggio da imprenditore (esperienze, cosa ho imparato e tanti errori) alternando a qualche deep dive sui business che mi incuriosiscono.

Il debito tecnico è quella cosa di cui tutti parlano in astratto, ma che nessuno quantifica mai sul serio.

Prova a chiedere a un CTO: “Quanto debito tecnico avete?” Ti risponderà qualcosa tipo “eh, un po’”, oppure “nella parte di autenticazione c’è da sistemare qualcosa”, oppure il classico “è sotto controllo”. Ma se gli chiedi un numero, una stima, un’idea concreta di quanto tempo il team perde ogni settimana per colpa del debito accumulato, vedrai una faccia che dice tutto.

Non lo sa, nessuno lo sa.

Non compare nei report al board, non ha un KPI in nessuna dashboard, nessun PM lo mette nel backlog come priorità alta.

Non è neanche una questione di competenza dei team, perché ho visto developer bravissimi accumulare debito tecnico come se non ci fosse un domani. Tutto questo perché nessuno gli aveva detto di fermarsi a misurare ogni tanto.

Il colesterolo buono

Qui di solito casca l’asino: non tutto il debito tecnico è cattivo.

Il colesterolo HDL, quello buono, non solo non fa male: tiene pulite le arterie e si porta via quello cattivo. In dosi giuste, serve. Il debito tecnico volontario funziona allo stesso modo. Lo prendi consapevolmente perché in quel momento ti serve qualcos’altro più della perfezione, di solito velocità. Sai esattamente dove stai tagliando l’angolo, sai perché, e da qualche parte (idealmente scritto, non solo nella tua testa) c’è il piano per tornarci.

È debito tecnico? Sì, assolutamente. Ma è debito che hai scelto di prendere, che hai documentato, e che sai dove si trova.

Quando ero un developer alle prime armi non l’avrei mai accettata come scelta. Mi sarebbe sembrata una resa. Ero quello che voleva il codice perfetto, che passava ore a rifattorizzare cose che funzionavano benissimo solo perché non gli piaceva come erano scritte. Manco fossi il custode di un tempio sacro del codice pulito (svegliati Chri)

Ci sono voluti anni e qualche scadenza saltata per capire una cosa semplice: se sai dove hai tagliato, puoi tornare a sistemare. Se non lo sai, sei nei guai. Il punto rimane la consapevolezza e non la perfezione.

Il colesterolo cattivo

E poi c’è l’altro tipo. Quello che si accumula senza che nessuno se ne accorga.

“Tanto lo sistemiamo nella prossima sprint.” “Per ora mettiamo un workaround, poi rifacciamo.” “Funziona, non tocchiamolo.”

Le conosci vero? Se avessi un euro per ogni volta che ho sentito queste frasi, potrei permettermi una Ferrari.

Nella newsletter su come valuto la qualità dei prodotti digitali avevo scritto che le scorciatoie si accumulano e ognuna sembra innocua nel momento in cui la prendi. È vero, ma c’è un pezzo che non avevo raccontato: il debito tecnico cattivo non è solo questione di scorciatoie. È anche questione di contesto perso. Un dev scrive un pezzo di codice con una logica specifica in mente, sei mesi dopo se ne va, arriva un altro che guarda il codice, non capisce perché è fatto così e ci costruisce sopra qualcosa di nuovo. Si ritrova con fondamenta incomprensibili, stratificate.

Il caso peggiore che ho visto è stato di una volta dove il mio team non riusciva più a fare deploy senza rompere qualcosa. Guardando il codice ho trovato un file di configurazione con un commento che diceva: “NON TOCCARE QUESTO FILE. SE LO TOCCHI SI ROMPE TUTTO.” E nessuno sapeva perché, sai come mai? Perché il collega che l’aveva scritto non lavorava più lì da due anni. Quel file era diventato il totem sacro che nessuno osava toccare, attorno al quale tutto il resto doveva girare.

L’abbiamo toccato (guardati questo prima di procedere): https://www.facebook.com/watch/?v=1084588443450)

Si è rotto tutto. Ci abbiamo messo una settimana a rimettere insieme i pezzi e a capire cosa diavolo faceva quel file. Ma almeno adesso il team sapeva come funzionava il proprio sistema, invece di girarci attorno come fosse una maledizione.

Lo zi, se nel tuo codice c’è un file con un commento del genere, sappi che hai un problema.

Come te ne accorgi (prima che esploda)

I sintomi del debito tecnico cattivo non arrivano tutti insieme, si innescano a catena e ognuno preso singolarmente sembra gestibile.

Prima i deploy rallentano. Facevi deploy due volte al giorno, poi una volta al giorno, poi due volte a settimana, poi “quando siamo sicuri che non si rompa niente”.

Siccome i deploy rallentano, il team inizia a raggruppare più modifiche insieme e siccome ogni deploy tocca più cose, i bug aumentano. Correggi qualcosa qui, si rompe qualcos’altro là. A quel punto nessuno si fida più della suite di test (se ce n’è una) e partono i test manuali sempre più lunghi prima di ogni rilascio. Le feature nuove richiedono sempre più tempo perché ogni modifica deve fare i conti con tutto il casino che si è accumulato. Il product manager chiede “quanto ci vuole per aggiungere questa cosa?” e la risposta del team passa da “un paio di giorni” a “dipende” a “non possiamo stimarlo finché non capiamo come si collega al resto”. Quel “dipende” è un segnale fortissimo.

E alla fine c’è il mio indicatore preferito: il tempo di onboarding di un collega nuovo.

Se un developer senior impiega più di due settimane per essere produttivo o c’è debito tecnico, o è un software davvero complesso. Significa che il codice è diventato così intrecciato che nemmeno uno sviluppatore con tanta esperienza riesce a capirlo.

La domanda che faccio sempre ai team quando entro in un nuovo progetto è semplice: “Quanto tempo perdete ogni settimana per colpa di roba che sapete che andrebbe sistemata, ma non avete mai tempo di sistemare?”

Le risposte vanno dal 10% al 40%. Il QUARANTA per cento. Quasi metà del tempo di un team che lavora su cose che non dovrebbe dover fare.

La spending review del codice

Nella newsletter su come risparmio 788 euro l’anno costruendomi i tool con l’AI raccontavo della mia spending review degli abbonamenti: apri il conto, guardi tutti gli addebiti ricorrenti e ti chiedi per ognuno se ti serve davvero.

Il debito tecnico funziona allo stesso modo, serve una spending review sul codice.

Con i miei clienti lo faccio così. Una volta al trimestre, ci sediamo col team tecnico e facciamo una mappa del debito. Non serve niente di complicato: un foglio condiviso dove ogni developer scrive le tre cose del codebase che gli fanno perdere più tempo. Le cose che lo rallentano, quelle dove ogni volta dice “questo andrebbe riscritto”.

Poi le ordini per impatto sul business, non per importanza tecnica, che è la trappola in cui cadono tutti. Quel pezzo di codice bacato nel sistema di pagamenti che costringe il team a fare check manuali ogni settimana? Priorità alta. Quella classe che ha nomi di variabili orrendi ma funziona perfettamente? Può aspettare.

E poi la parte più difficile: comunicarlo ai non-tech. Perché provare a spiegare il debito tecnico a un CEO che vuole solo nuove feature è come spiegare il colesterolo a uno che vuole solo mangiare la carbonara in pace. Non gli interessa il meccanismo, gli interessa capire cosa succede se non se ne occupa.

Io la metto così: “Ogni sprint, il 20% del tempo lo dedichiamo a ripagare debito tecnico. Se non lo facciamo, tra sei mesi quel 20% diventa 40%, e tra un anno il team non riesce più a rilasciare niente.” Di solito funziona, i numeri parlano anche a chi non capisce il codice.

Con un mio cliente abbiamo fatto esattamente questo esercizio: il suo team ha tirato fuori una lista di quattordici cose, sì, ben quattordici. Poi ne abbiamo scelte tre per il primo trimestre, le tre che facevano perdere più tempo in assoluto. Ma le altre undici stanno lì, le sappiamo, ci arriveremo, diciamo che almeno adesso le conosciamo.

Quando il debito tecnico uccide (e quando è giusto tenerlo)

Ho visto startup morire per debito tecnico, non nel senso drammatico del termine, però avevano raggiunto un punto dove aggiungere qualsiasi cosa al prodotto costava così tanto che non riuscivano più a stare al passo col mercato. I competitor più giovani, li superavano in velocità e riscrivere da zero non era un’opzione percorribile, dato che dovevi fermare il prodotto per sei mesi (e non si poteva fare).

Quello è il punto di non ritorno. E ci arrivi un commit alla volta.

Però, e qui devo essere onesto, ci sono situazioni dove il debito tecnico va bene così. Se stai validando un’idea e non sai ancora se il prodotto avrà un mercato, non ha senso investire in un’architettura perfetta. Se il mercato sta cambiando velocemente e devi pivotare, forse quel codice lo butterai via comunque tra tre mesi. Se hai una finestra di mercato stretta e devi entrarci adesso, il debito tecnico è il prezzo di ingresso.

Il punto è che l’obiettivo non è zero debito tecnico. Quello non esiste, è un’utopia da sviluppatore estremista quale ero io a ventitré anni. L’obiettivo è debito tecnico sotto controllo: sai quanto ne hai, sai dove si trova, e hai un piano per gestirlo.

Fai le analisi periodicamente, e quando i numeri salgono troppo intervieni prima che diventi un problema serio. Non è più complicato di così, anche se arrivarci lo è stato eccome.

Quand’è stata l’ultima volta che hai fatto le “analisi del sangue” al tuo codebase?

Rispondi a questa mail, sono curioso di sapere come lo gestite voi.

Ci vediamo alla prossima newsletter.

Senza filtri,
Chri

P.S. Costruiamo insieme Senza Filtri

Ho creato un breve sondaggio anonimo per capire come migliorare la newsletter ed esserti più utile. Se ti va di rispondere a qualche domanda clicca qui (meno del tempo di prendere un caffè). Grazie mille.

👋 Ciao, sono Chri. Fractional CTO e questa è Senza Filtri: la newsletter dove condivido il dietro le quinte del mio viaggio da imprenditore (esperienze, cosa ho imparato e tanti errori) alternando a qualche deep dive sui business che mi incuriosiscono.

Mi ricordo il giorno in cui ho ricevuto l’invito a Google+. Estate 2011, gli inviti erano limitati e tutti li volevano, era tipo il primo giorno di WoW (se non lo conosci, meglio per te, ci ho perso la vita dietro a sto gioco) in cui stavi in coda per entrare nel server.

Ho aperto la piattaforma, ho guardato l’interfaccia pulita, ho trascinato quattro amici nelle Circles e ho pensato: “Finalmente qualcuno ha fatto Facebook come si deve.”

E poi niente… perchééé… non ci sono più tornato.

Tra l’altro non ero l’unico, dato che il tempo medio che gli utenti passavano su Google+ era di 3,3 minuti al mese.

Su Facebook nello stesso periodo si stava 7 ore e mezza. In pratica per ogni minuto che passavi su Google+, ne passavi mille su Facebook.

La storia di Google+ è una di quelle che chi costruisce prodotti dovrebbe studiarsi a memoria: si parla di un’azienda che alla fine aveva tutto, dai soldi infiniti fino agli ingegneri migliori al mondo, con una distribuzione potentissima (basti pensare a GMail, YouTube, Android, Search), eppure è riuscita comunque a creare qualcosa che nessuno aveva chiesto. Ecco perché è importante parlarne.

La paura che ha fatto nascere un mostro

Per capire Google+ bisogna capire cosa stava succedendo dentro Google nel 2010.

Facebook aveva raggiunto i 500 milioni di utenti e stava costruendo qualcosa che Google non possedeva: un database di relazioni umane reali, con nomi, facce, amicizie, interessi. Roba che il motore di ricerca non poteva catturare. Urs Holzle, uno dei primi dieci dipendenti di Google nella storia, mandò un memo interno avvertendo che l’azienda sarebbe stata “schiacciata” se non avesse reagito.

Vic Gundotra, un ex Microsoft che era diventato VP di Google, divenne quello che un ex collega ha descritto come “il tarlo costante nell’orecchio di Larry Page: Facebook ci ammazzerà.”

Quando Larry Page tornò CEO ad aprile 2011 (sostituendo Eric Schmidt), fece una cosa che nella storia di Google non si era mai vista: legò il 25% del bonus annuale di ogni singolo dipendente al successo della strategia social. Raga, ingegneri di Search, Maps, Chrome, gente che col social non c’entrava assolutamente niente, si ritrovò con la busta paga legata a Google+.

Il progetto aveva un nome in codice : “Emerald Sea”, dal nome di un quadro di Bierstadt del 1878 che raffigurava un’onda gigantesca che sta per capovolgere una nave. Bradley Horowitz, il VP di prodotto, fece dipingere un murale di quel quadro di fronte all’ascensore del team. Il messaggio era chiaro: o cavalchiamo quest’onda o affoghiamo (cringe as fuck).

Tra l’altro, un ingegnere di Google di nome Steve Yegge scrisse uno sfogo interno di 3.700 parole su come Google non capisse le piattaforme. La tesi: “Facebook ha successo perché ha costruito un’intera costellazione di prodotti permettendo ad altre persone di fare il lavoro. Google+ è nato praticamente senza API, avevamo una singola, misera API” che lui soprannominò “la Stalker API.” E sempre Yegge pubblicò questo sfogo accidentalmente su Google+ stesso, in pubblico invece che internamente. Diventò virale, finì su CNN e Washington Post. Non lo licenziarono. E tutto quello che aveva previsto si avverò.

Ma prima di affondare, per un paio d’anni sembrò che stesse funzionando. Almeno a guardare i numeri.

Va che numeri (e che buchi)

Il lancio fu il 28 giugno 2011. Dieci milioni di utenti in due settimane, 90 milioni entro fine anno. Sulla carta, numeri da capogiro.

Il problema è che quei numeri erano in piedi con lo scotch. Google creava automaticamente un profilo Google+ per chiunque avesse un account Gmail, YouTube o Android. Poi ridefinì “utente attivo” includendo chiunque cliccasse un pulsante +1 o commentasse su YouTube (attraverso l’integrazione forzata, ma ci arriviamo).

I numeri reali raccontavano un’altra storia:

Account registrati: oltre 500 milioni, creati in automatico.

“Utenti attivi mensili” dichiarati da Google: 540 milioni, contando chiunque toccasse un qualsiasi prodotto Google con funzionalità social.

Utenti che visitavano davvero lo stream di Google+: 300 milioni secondo Google, ma il New York Times scoprì che quasi la metà non aveva mai aperto il sito.

Tempo medio mensile su Google+ secondo ComScore, a gennaio 2012: 3,3 minuti. Su Facebook: 7 ore e 30 minuti. Addirittura su MySpace, che era già in declino, si stava quasi il triplo rispetto a Google+.

L’investimento stimato da Forbes, calcolato poche settimane dopo il lancio, era di circa 585 milioni di dollari. Dentro c’erano 125 milioni l’anno per 500 ingegneri dedicati, più tre acquisizioni strategiche: Slide per 179 milioni, On2 per 123 milioni, Widevine per 158 milioni. E questo era il costo iniziale, non quello degli otto anni successivi.

Per dare un’idea del finale: quando Google chiuse Google+ nel 2019, la class action per il data breach venne risolta per 7,5 milioni di dollari. Con 1,7 milioni di persone che fecero richiesta, ognuno ricevette 2 dollari e 15 centesimi.

Da 585 milioni a 2 dollari e 15 centesimi a testa. Chapeau.

La feature migliore era anche il problema peggiore

Circles era l’idea più innovativa di Google+. Potevi organizzare i contatti in cerchie (famiglia, amici, lavoro, fotografi) e decidere esattamente chi vedeva cosa ogni volta che postavi qualcosa. L’interfaccia era stata progettata da Andy Hertzfeld, uno dei designer originali del primo Macintosh, con un drag-and-drop che per gli standard di Google era quasi rivoluzionario.

L’idea veniva da un’osservazione vera: nella vita reale non parliamo allo stesso modo con la famiglia, i colleghi e gli amici del bar. Facebook nel 2011 aveva un modello binario, o sei amico di qualcuno o non lo sei, e tutto quello che posti lo vedono tutti.

Circles risolveva un problema reale di privacy ma creava un effetto collaterale devastante.

Siccome tutti erano incentivati a condividere in modo privato, il feed pubblico era vuoto. Chi arrivava su Google+ per la prima volta trovava il deserto. E siccome trovava il deserto, non postava. E siccome non postava, il feed restava vuoto per il prossimo che arrivava.

Quella che era una feature che doveva rendere Google+ migliore per la privacy, stava diventando il suo tallone d’Achille. Il prodotto si stava sabotando da solo e proprio usando la sua innovazione principale.

L’integrazione forzata e la rivolta di YouTube

Google non volle costruire “solo” un social network, bensì provò a innestarlo in modo chirurgico su ogni prodotto che possedeva.

A gennaio 2012, “Search Plus Your World” iniziò a infilare risultati di Google+ nella ricerca. Ingegneri di Facebook, Twitter e MySpace, guidati da Blake Ross (il co-creatore di Firefox), costruirono un tool che si chiamava “Don’t Be Evil” e che dimostrava come Google avesse i dati per includere anche gli altri social ma scegliesse di non farlo. In pratica ti sbattevano in faccia il motto di Google per farti notare che non lo stavano rispettando.

Ma il vero disastro fu YouTube.

A novembre 2013 Google decise che per commentare un video su YouTube serviva un account Google+, con tanto di policy sul nome reale. Il cofondatore di YouTube, Jawed Karim, che non postava niente da otto anni, ruppe il silenzio con un commento che è diventato leggendario: “why the f*** do I need a google+ account to comment on a video?”

La rivolta fu la più grande nella storia di Google. 223.000 firme su Change.org, 30.000 commenti arrabbiati sul post di annuncio, 900 topic aperti nel Product Forum in 24 ore. YouTuber come TotalBiscuit e PewDiePie disabilitarono i commenti per protesta. E nacque un meme: “Bob is building an army”, un omino ASCII che veniva incollato ovunque nei commenti come atto di resistenza contro Google+. Gli utenti riempirono YouTube di arte ASCII di carrarmati e roba peggiore per rompere gli algoritmi di ranking dei commenti. Non era una protesta educata, era una guerriglia digitale.

Google fece marcia indietro nell’estate 2014, ammettendo che la policy sui nomi e l’integrazione forzata avevano creato “esperienze inutilmente difficili.”

Da CTO, questa cosa mi fa pensare un bel po’, perché puoi avere la distribuzione più potente del mondo, ma se la usi per forzare un prodotto che la gente non vuole, stai cannando (e pure tanto). In questo modo accumuli solo debito reputazionale che prima o poi ti crolla addosso.

La città fantasma con un quartiere vivo

Mentre il mondo mainstream considerava Google+ una sorta di città fantasma, per i fotografi era diventato il posto migliore di internet (che paradosso meraviglioso). Perché? Beh, Facebook comprimeva le immagini fino a renderle irriconiscibili per risparmiare banda, invece Google+ le mostrava enormi, in alta risoluzione e senza compressione. Eccoli lì, i fotografi impazziti.

Trey Ratcliff, un fotografo HDR, aveva un seguito su Google+ paragonabile a Madonna e Lady Gaga sulla stessa piattaforma. Community come “The Photo Community” raccoglievano decine di migliaia di membri attivi. Il 30 giugno 2012 migliaia di Photo Walk coordinate si svolsero in tutto il mondo. Hashtag giornalieri come #WaterfallWednesday e #MountainMonday tenevano vivo un ecosistema creativo che Facebook non si sognava nemmeno.

Anche gli utenti che giocavano di ruolo con i giochi da tavolo tipo D&D avevano trovato lo strumento perfetto: Hangouts. Utile per le sessioni di D&D online, prima che Roll20 diventasse mainstream. VICE nel 2019 documentò come in effetti lo stesso Roll20 fosse “una porzione significativa della presentazione e dell’approccio di Roll20 deriva da quei primi giorni su Google Hangouts.” E quindi, alla fine, c’era gente che su Google+ ci viveva davvero.

Il paradosso è che la stessa piattaforma era contemporaneamente città fantasma per la massa e metropoli viva per le nicchie. E se Google avesse puntato su quello? Se invece di rincorrere Facebook avesse detto “ok, siamo il posto dei fotografi, dei nerd, delle community verticali”? Probabilmente no, non sarebbe mai successo, non è nel DNA di Google fare cose di nicchia. Ma ci penso ogni tanto, perché rincorrendo quello che non poteva avere, ha distrutto quello che funzionava davvero.

Il giorno della chiusura, un utente avviò un gruppo “Google+ Mass Migration” che raccolse 1.500 membri in pochi giorni. Qualcuno fece una petizione con 18.000 firme. Il 2 aprile 2019 ci fu una livestream d’addio. La community si frammentò tra MeWe, Mastodon, Discord e Reddit. Come scrisse qualcuno cinque anni dopo: “Non credo che ci ritroveremo mai tutti nello stesso posto, ma è stato bello finché è durato.” (Pensa te…)

Il data breach che ha chiuso tutto

La fine di Google+ non arrivò per il basso engagement, almeno non ufficialmente, ma arrivò per un bug.

Nel marzo 2018, durante un audit interno chiamato “Project Strobe” (nato sull’onda dello scandalo Cambridge Analytica di Facebook), gli ingegneri di Google scoprirono che un bug nell’API People esisteva dal 2015. Per tre anni, 438 app di terze parti avevano potuto accedere a dati di profilo non pubblici degli amici degli utenti, senza autorizzazione. Circa 500.000 account potenzialmente esposti.

Google sistemò il bug immediatamente e poi decise di non dire niente a nessuno.

I memo interni mostravano che la leadership temeva “attenzione regolatoria e danni reputazionali.” Sundar Pichai venne informato della decisione di non divulgare.

Il Wall Street Journal scoprì tutto a ottobre 2018 e pubblicò l’inchiesta. Google tirò fuori il suo post su Project Strobe pochi minuti dopo, annunciando contemporaneamente la chiusura di Google+ e ammettendo, quasi di sfuggita, che il 90% delle sessioni durava meno di cinque secondi. A dicembre saltò fuori un secondo bug, 52,5 milioni di account esposti. La chiusura venne anticipata e il 2 aprile 2019 Google+ cessò di esistere.

La cosa che mi colpisce di più è la promessa tradita. Google+ era nato anche per rimediare ai disastri di privacy di Google Buzz, che nel 2010 aveva esposto le liste contatti Gmail e si era beccato una multa FTC da 8,5 milioni di dollari e 20 anni di audit sulla privacy. E poi è morto per lo stesso identico tipo di problema, tre prodotti dopo. Come quelli che cambiano framework ogni sei mesi e si portano dietro sempre gli stessi bug.

Lo stesso film, stessa fine

Google+ non è un caso isolato. È un pattern (per Google sopratutto).

Apple Ping, social musicale integrato in iTunes, 2010. Un milione di iscritti in 48 ore. Steve Jobs invitò Zuckerberg a cena per integrare Facebook, l’accordo saltò. Senza social graph, Ping era un negozio che fingeva di essere un bar. Chiuso nel 2012. Windows Phone di Microsoft: 7,2 miliardi per Nokia, write-down da 7,6 miliardi, perdite sopra i 10 miliardi. Bill Gates l’ha definito il suo “più grande errore.” Stessa storia, cifre diverse.

L’eccezione è Threads di Meta. Lancio identico al pattern Google+: 100 milioni di iscritti in 5 giorni grazie a Instagram, poi un calo dell’82% degli utenti attivi giornalieri nel primo mese. Ma a differenza di Google+, Meta è stata paziente, ha iterato, e soprattutto ha beneficiato dell’autodistruzione di X sotto Elon Musk. Threads oggi è sopra i 275 milioni di utenti attivi mensili. La distribuzione può funzionare, ma serve pazienza vera e un competitor che si spara nei piedi da solo.

Quello che Google+ ha lasciato

Google+ non è stato un fallimento totale dal punto di vista tecnico. Google Photos, uno dei prodotti di maggior successo dell’ecosistema Google, è nato dalle funzionalità foto di Google+. Hangouts si è evoluto in Google Meet, che durante il COVID ha raggiunto 100 milioni di utenti giornalieri. Il login unificato di Google che usi ogni giorno per accedere a mille app deve qualcosa all’identity layer costruito per Google+.

Poi c’è il capitolo che ancora oggi mi fa girare le palle: Google Reader. L’aggregatore RSS che mezza internet amava. Google spostò ingegneri da Reader a Google+ perché, come confermò un ex product manager, “i membri del team Reader erano considerati gli unici in Google che capissero davvero il social.” Reader fu chiuso a luglio 2013. Google+ ad aprile 2019. Google sacrificò un prodotto che la gente amava per un prodotto che la gente tollerava. E poi chiuse anche quello.

Morgan Knutson, un ex dipendente, scrisse su Twitter: “Sono ancora incazzato per il bait and switch che mi hanno fatto, dicendomi che avrei lavorato su Chrome e poi mettendomi su questo maledetto pezzo di merda.”

La domanda che mi faccio ancora

Ogni volta che lavoro con una startup e qualcuno mi dice “se integriamo il nostro prodotto con X, gli utenti arriveranno da soli”, mi torna in mente Google+. Gli utenti arrivano, certo. Poi guardano, non capiscono perché restare, e quindi se ne vanno.

Google aveva i soldi, gli ingegneri, la distribuzione e la tecnologia. Il giorno del lancio il titolo in borsa aggiunse 20 miliardi di capitalizzazione. Otto anni dopo chiusero tutto e mandarono 2 dollari e 15 centesimi a chi aveva fatto causa.

La cosa che mi porto a casa da questa storia non è la solita “costruisci per gli utenti, non per te”. Quella la sappiamo tutti. È che Google sapeva benissimo cosa stava facendo, non erano stupidi, avevano i dati, avevano i feedback. La rivolta di YouTube nel 2013 era un segnale impossibile da ignorare eppure hanno continuato per altri cinque anni. Perché quando hai investito 585 milioni e ci hai legato il bonus di tutta l’azienda, ammettere che non funziona è quasi più difficile che continuare a buttarci soldi.

Questa è la parte della storia che mi fa più paura, perché la vedo succedere anche nel piccolo. Un sacco di startup continuano a spingere feature che nessuno usa perché “ci abbiamo messo tre mesi a costruirla”, i team non pivotano perché “abbiamo già comunicato la roadmap”.

Il costo più grande non sono i 585 milioni. È Google Reader, sono i 1.000 ingegneri spostati da prodotti che funzionavano, è la fiducia degli utenti di YouTube bruciata per anni. Il costo più grande è sempre quello che sacrifichi per tenere in vita qualcosa che dovresti lasciar morire.

Ci vediamo alla prossima newsletter.

Senza filtri,
Chri

P.S. Costruiamo insieme Senza Filtri

Ho creato un breve sondaggio anonimo per capire come migliorare la newsletter ed esserti più utile. Se ti va di rispondere a qualche domanda clicca qui (meno del tempo di prendere un caffè). Grazie mille.

[Video Youtube] Quello che non ti dicono del lavorare in proprio

Tutti ti raccontano i vantaggi di lavorare in proprio. Nessuno ti racconta le decisioni alle 23, i clienti che non pagano per 60 giorni, e la solitudine di non avere nessuno che ti dice se stai facendo la cosa giusta. Dopo quasi quattro anni da Fractional CTO, racconto le cose che avrei voluto sapere prima.

[Guarda il video]

👋 Ciao, sono Chri. Fractional CTO e questa è Senza Filtri: la newsletter dove condivido il dietro le quinte del mio viaggio da imprenditore (esperienze, cosa ho imparato e tanti errori) alternando a qualche deep dive sui business che mi incuriosiscono.

“Vai agli eventi. Fai networking. Stringi mani”

Questo è stato il primo consiglio che mi hanno dato quando ho iniziato a lavorare in proprio.

Sono una persona introversa anche se non si direbbe. L’idea di piazzarmi in una sala piena di gente, col bicchiere in mano, a cercare di infilarmi in conversazioni con sconosciuti mi fa venire l’ansia. Eppure l’ho fatto, perché me l’avevano detto tutti e quindi doveva essere giusto, no?

Ci sono andato, ho stretto mani, ho distribuito bigliettini da visita (quelli vecchio stile, non quelli fighi che ho fatto ultimamente).

Clienti trovati in quel modo? Zero, o come direbbe il Pancio: TARALLO 👌🏻

Gli eventi funzionano, non lo negherò. Però forse lo fanno per certe persone e non per me. Nessuno mi aveva detto la cosa più importante: prima di cercare clienti, devi capire che tipo di persona sei, e da lì riuscirai a costruire il tuo modo di trovarli, senza tentare di copiare quello di qualcun altro.

La fase del cacciatore disperato

Prima di fare il Fractional CTO avevo una società (zerocento). Facevamo un botto di outbound: cold email, proposte a freddo, il classico “spara a raffica e vedi cosa colpisci”.

Qualcosa arrivava, per carità. Ma era un lavoro massacrante, e i clienti che arrivavano così erano quasi sempre quelli peggiori. Quelli che ti confrontano con altri tre preventivi, che ti trattano come un fornitore intercambiabile, che ti chiedono lo sconto prima ancora di sapere cosa fai. Manco fossimo al mercato del pesce.

Quando quella società è fallita (sì, è fallita, e magari un giorno ci scrivo una newsletter dedicata), mi sono ritrovato da solo. Di nuovo punto e a capo. E con un problema molto concreto: dovevo trovare clienti, da zero, senza un brand aziendale dietro, senza un sito fighetto, senza niente.

Il primo anno da Fractional è stato una rottura pazzesca, circolavo tra contatti, mandavo messaggi e cercavo di farmi conoscere. Il problema non era il lavoro in sé, ma trovare chi potesse darmelo, e ogni giorno mi rendevo conto che questa corsa continua non era sostenibile, perché mentre cercavo clienti dovevo comunque lavorare per quei pochi che avevo. Ero incastrato nella ruota del criceto: pedalavo un botto, ma non andavo da nessuna parte.

Il primo passo che nessuno ti dice

Ora ti dico cosa ha funzionato all’inizio, e non parlerò di LinkedIn o degli eventi, e nemmeno di una strategia marketing da manuale, ma di una cosa più “semplice”: la mia rete più stretta. Le persone che avevano già lavorato con me e che conoscevano già il mio valore hanno potuto promuoverlo meglio di quanto avrei potuto fare io sparando a raffica e soprattutto a freddo. Sono tornato da chi mi conosceva già.

I miei primi clienti da Fractional CTO sono stati contatti che avevo prima di partire. Gente con cui avevo collaborato nella società precedente, che sapeva come lavoravo e di cosa ero capace. Un founder con cui avevo fatto un progetto due anni prima mi ha richiamato dicendomi “sto tirando su un team tech e non so da dove partire, ti va di darmi una mano?”. Alcuni li ho seguiti anche gratis all’inizio, ma questa è un’altra storia.

Ho capito che prima di costruire qualsiasi “sistema” per trovare clienti, la cosa più intelligente da fare era tornare da chi mi conosceva già. Magari ti sembrerà banale perché non è una strategia mega complessa ed è “poco scalabile”, però ti assicuro che è letteralmente una parte delle fondamenta sulle quali potrai costruire il tuo business.

Costruire la base (e smetterla di rincorrere)

Ecco, qui arriviamo alla cosa che ho capito col tempo e che probabilmente è la più importante di tutta questa newsletter.

Tutti si ossessionano col trovare nuovi clienti. È comprensibile, perché quando sei all’inizio hai bisogno di entrate e l’istinto è quello di cercare, cercare, cercare. Ma intanto trascuri quelli che hai già.

Io facevo lo stesso errore: avevo 2-3 clienti, startup in fasi diverse, e invece di concentrarmi su farli stare benissimo, spendevo metà del mio tempo a cercarne di nuovi. Come se avere più clienti fosse automaticamente la soluzione a tutto.

Poi ho letto “Customer Success Manifesto” di Jay Goncalves, un libro che consiglio a chiunque faccia il freelance o gestisca clienti. Il concetto centrale è che puoi aumentare i profitti anche del 25-100% senza acquisire un singolo cliente nuovo. Solo trattando meglio quelli che hai, lavorando sulla retention, sul lifetime value, sull’esperienza che gli fai vivere.

E attenzione, perché qui c’è una sfumatura che ci tengo a dire: tenere i clienti non significa obbligarli a restare. Non sto parlando di vincolarli con contratti capestro o di renderli dipendenti da te. Sto parlando di fare un lavoro talmente buono che non hanno motivo di andarsene. Per un Fractional CTO questo vuol dire cose molto concrete: decisioni tech che gli fanno risparmiare soldi veri o processi che funzionano anche quando tu non ci sei. Se il tuo lavoro genera risultati tangibili, il cliente resta perché gli conviene, non perché è incastrato.

Quando ho iniziato a ragionare così è successa una cosa che non mi aspettavo: i clienti soddisfatti hanno iniziato a portarmi altri clienti. Un founder con cui avevo lavorato bene ha parlato di me a un altro founder del suo network. Quello mi ha chiamato, abbiamo fatto una discovery call, e in venti minuti eravamo d’accordo su tutto. Non ha confrontato preventivi, non ha nemmeno trattato sul prezzo, neanche professando il classico “ci penso e ti faccio sapere”. Si fidava già dal momento in cui ero stato consigliato da qualcuno che conosceva.

Nella mia esperienza, i clienti con cui lavori bene tendono a presentarti gente simile a loro. Il referral non è solo un canale di acquisizione, è un filtro qualitativo. Difficilmente un buon cliente ti passa un brutto cliente. E questo nel mondo startup è ancora più vero, perché i founder parlano tra di loro, si confrontano, si passano i contatti. Se fai un buon lavoro con uno, lo sanno in tre.

C’è anche un altro aspetto che non è banale: avere una buona base di clienti ricorrenti ti dà la serenità economica per poter scegliere. Perché un conto è valutare un potenziale cliente con tranquillità, prenderti il tempo di capire se è un match, e un conto è dover accettare qualsiasi cosa perché il mese prossimo devi pagare le bollette. La base clienti è il tuo paracadute finanziario, ed è quello che ti permette di passare da “accetto tutto” a “scelgo io”.

I contenuti: il magnete lento

Dopo la società fallita, ho iniziato a creare contenuti in maniera più costante e spinta. LinkedIn, newsletter, roba così. Sempre con una prospettiva personale, raccontando quello che vedevo lavorando con le startup, ma mai salendo in cattedra a fare il maestrino.

Non avevo un piano editoriale perfetto, non avevo una “strategia di content marketing” con i fiocchi. Raccontavo quello che vedevo, quello che sbagliavo, quello che imparavo. Tipo quella volta che ho scritto un post su come avevo gestito male una migrazione e mi sono preso un sacco di commenti di gente che ci si riconosceva. Roba onesta, non il solito “5 consigli per scalare la tua startup”.

Col tempo mi sono accorto di una cosa strana: le persone arrivavano in discovery call e già sapevano chi ero. Mi ricordo una call dove il tipo mi fa “ah ma io ti seguo da un anno, ho letto quel tuo post e sono d’accordo”. A quel punto non dovevo neanche vendermi, ma riuscire solo a capire se fosse un “match”, che è tutta un’altra sensazione rispetto al “convincimi che vali il prezzo che chiedi”.

Il ROI dei contenuti è praticamente impossibile da misurare con precisione, e questa è una cosa che devi accettare se vuoi percorrere questa strada. L’unica metrica che riesco a monitorare è quante discovery call diventano clienti, e da quando creo contenuti con costanza quel numero è salito parecchio. Ma il vero ritorno è ancora più difficile da quantificare: è il fatto che non devi più spiegare chi sei a ogni call, è il fatto che le persone ti contattano loro. Un effetto cumulativo che si costruisce piano piano, e se cerchi il risultato immediato ti frustrerai. Ma quando arriva, cambia tutto.

La scomoda verità

Prima che qualcuno pensi “facile per te dire di non cercare clienti”, devo essere onesto.

Per arrivare al punto in cui non cerchi più, devi prima aver cercato. Devi aver fatto la gavetta, aver lavorato anche gratis per costruirti un portfolio, aver provato cose che non funzionavano per te (tipo gli eventi, nel mio caso). Devi aver costruito una base, una reputazione, un track record che parla per te.

Il consiglio “non cercare clienti” è vero, ma è incompleto. Funziona solo dopo che hai fatto il lavoro di costruirti uno zoccolo duro: clienti ricorrenti che ti garantiscono stabilità, contenuti che parlano per te quando non ci sei e una rete di persone che ti conosce e si fida abbastanza da presentarti ad altri.

È un accumulo di anni di lavoro fatto bene, relazioni curate, e contenuti onesti. Roba che richiede tempo e pazienza, due cose che nessun corso da “10k al mese in 30 giorni” ti insegnerà mai. E no, non ho una formula segreta nemmeno io, sto ancora imparando a farlo meglio.

Se sei ancora nella fase “cacciatore”

Se oggi sei nella fase in cui rincorri i clienti, non ti dico di smettere domani. Però ti racconto cosa avrei voluto che qualcuno mi dicesse quando ero in quel punto.

La prima cosa che farei se dovessi ricominciare da zero è prendere il telefono e chiamare le persone con cui ho già lavorato. Non per vendergli qualcosa, ma per sapere come va il progetto, se hanno bisogno di una mano, se conoscono qualcuno che potrebbe averne bisogno. Sembra una roba da niente, ma la fiducia è già lì e non devi costruirla da zero. Ogni cold message che mandi a uno sconosciuto ti costa dieci volte lo sforzo di una chiamata a qualcuno che già sa come lavori.

E nel frattempo, i clienti che hai adesso, anche se sono pochi, anche se sono piccoli, falli stare benissimo. Perché quando un founder chiede al suo amico founder “conosci un CTO bravo?”, tu vuoi essere il nome che esce. E quel nome esce solo se il lavoro che hai fatto parla da solo.

Il passaggio da cacciatore a calamita ci ho messo anni a farlo e probabilmente ci metterai tempo anche tu. Ma a un certo punto ti accorgi che il telefono squilla senza che tu abbia mandato niente a nessuno. E quella, dopo anni passati a rincorrere, è una bella sensazione. Magari non la più bella in assoluto, sto diventando vecchio e la memoria fa brutti scherzi, ma ci siamo capiti.

Ci vediamo alla prossima newsletter.

Senza filtri,
Chri

P.S. Come sempre, se vuoi rispondere a questa mail condividendo la tua esperienza, leggo tutto e rispondo (quasi) sempre.

P.P.S. Costruiamo insieme Senza Filtri

Ho creato un breve sondaggio anonimo per capire come migliorare la newsletter ed esserti più utile. Se ti va di rispondere a qualche domanda clicca qui (meno del tempo di prendere un caffè). Grazie mille.

[Video Youtube] Saper programmare non basta più

In questo video ti racconto cosa sta succedendo al mestiere dello sviluppatore, cosa perde valore, cosa ne guadagna e perché chi sa davvero cosa costruire vale più che mai.

[Guarda il video]

👋 Ciao, sono Chri. Fractional CTO e questa è Senza Filtri: la newsletter dove condivido il dietro le quinte del mio viaggio da imprenditore (esperienze, cosa ho imparato e tanti errori) alternando a qualche deep dive sui business che mi incuriosiscono.

Me la ricordo ancora la prima volta che ho sentito quella suoneria: quel ritmato “tu-du-du-du” (lo posso sentire ancora mentre lo scrivo e so che lo senti anche tu mentre lo leggi), che usciva dalle casse del PC mentre stavi facendo tutt’altro.

Mi ero installato Skype dopo che un’amico mi aveva detto che potevi chiamare gratis (trigger, parola magica). Nel 2004 parlare di “telefonare” e “gratis” nella stessa frase era qualcosa di inconcepibile.

Per la mia generazione, Skype era la quintessenza di internet, quella che dimostrava che funzionava davvero. Non era come scrollare un sito o leggere un thread su un forum, era parlare con qualcuno, vederlo in faccia, sentirlo ridere e conoscerne la voce. Tutto questo in tempo reale, a prescindere da quale parte del pianeta ti stesse chiamando e per di più senza spendere un centesimo. Praticamente magia, ma ci siamo talmente abituati talmente in fretta a questa comodità che ci siamo dimenticati di quanto fosse importante.

Poi a un certo punto ho smesso di usarlo. Non ricordo nemmeno quando esattamente, e credo sia questo il dettaglio più triste di tutta la storia.

Prima di Skype: telefonare costava un rene

Per capire perché Skype è stato rivoluzionario bisogna capire com’era telefonare nel 2003.

Le chiamate internazionali costavano un botto. Le compagnie telefoniche ti facevano pagare in base alla distanza, come se i dati viaggiassero in treno e servisse il biglietto per ogni fermata. Chiamare gli Stati Uniti dall’Italia poteva costare 1-2 euro al minuto. Le famiglie con parenti all’estero controllavano il timer con l’ansia, perché ogni secondo era soldi che se ne andavano.

Il VoIP esisteva già, per carità. Ma era roba da smanettoni: dovevi configurare client SIP, aprire porte sul router, pregare che la qualità audio non facesse sembrare la chiamata una trasmissione dal fondo dell’oceano. MSN Messenger aveva le chiamate vocali, ma la qualità era imbarazzante. Yahoo Messenger uguale.

Skype arrivò e fece sembrare tutti gli altri dei bambini.

Tre ragazzi estoni e un videogioco

La storia di Skype inizia negli anni ‘80, nell’Estonia sovietica. E già qui ti rendi conto che non è una storia normale.

Ahti Heinla, Priit Kasesalu e Jaan Tallinn erano amici dalle superiori. Nel 1989, a 17 anni, scrissero Kosmonaut, che poi divenne SkyRoads nel 1993: il primo videogioco estone venduto a livello internazionale. Ci guadagnarono 5.000 dollari. Tallinn aveva iniziato a programmare a 12 anni, dietro la cortina di ferro, con quello che c’era.

Alla fine degli anni ‘90, la loro azienda stava andando in bancarotta. Presero dei lavori da remoto per un operatore telefonico svedese, Tele2, a 330 dollari al giorno a testa. Ed è lì che incrociarono la strada di Niklas Zennström e Janus Friis, due imprenditori nordici con un’idea fissa: usare il peer-to-peer per smontare le industrie tradizionali.

Il primo tentativo fu Kazaa, un software di file-sharing P2P che divenne l’app più scaricata al mondo. L’industria discografica li trascinò in tribunale. Dovettero vendere tutto.

Ma l’intuizione tecnica rimase: se il P2P poteva spostare file enormi senza server centrali, poteva fare lo stesso con la voce.

“Il modo tradizionale di comunicare per telefono non ha più senso,” disse Zennström. “Se puoi usare le risorse dei computer degli utenti, puoi fare le cose molto più efficientemente.”

Ci vollero 26 rifiuti da venture capitalist e un anno intero per raccogliere 1,5 milioni di euro. Ma il 29 agosto 2003 uscì la prima beta. Solo Windows, solo chiamate vocali. 10.000 download il primo giorno.

La magia del peer-to-peer (spiegata semplice)

Ok, qui devo fare il CTO per un attimo, ma prometto di non esagerare col serpentese.

I servizi VoIP tradizionali funzionavano come un centralino: ogni chiamata passava attraverso un server dell’azienda. Più utenti avevi, più server ti servivano, più soldi bruciavi. Era un modello che scalava col portafoglio.

Skype fece una cosa geniale e un po’ pazza: trasformò i computer degli utenti stessi nell’infrastruttura.

Il tuo PC non era solo un telefono, era anche un pezzo della rete. Se avevi una connessione veloce e un IP pubblico, il tuo computer veniva promosso silenziosamente a “supernodo”, senza che tu ne sapessi niente. I supernodi facevano il lavoro sporco: tenevano un pezzo della rubrica distribuita degli utenti online e facevano da ponte quando due persone dietro un firewall non riuscivano a connettersi direttamente.

Al picco, circa 48.000 computer di utenti ignari reggevano l’intera rete Skype. Il costo infrastrutturale per l’azienda? Praticamente zero. La rete cresceva automaticamente con la base utenti: più gente la usava, più forte diventava.

E la parte più elegante era come risolveva il NAT traversal, cioè il fatto che la maggior parte dei computer casalinghi era dietro un router e non poteva ricevere connessioni dirette. Skype provava prima una connessione diretta tra i due utenti. Se non funzionava, trovava un terzo utente con un IP pubblico e lo usava come ponte.

E se anche l’UDP era bloccato, tipo nei firewall aziendali paranoici, riusciva a far passare la voce sulla porta 443, quella del traffico web cifrato, che praticamente nessun firewall blocca.

Risultato: Skype funzionava ovunque. Anche nelle banche con le policy di rete più restrittive del pianeta. Un utente dell’epoca scrisse: “È l’unica app VoIP che passa il firewall della nostra banca, ed è estremamente restrittivo.”

Nel 2003, quando mettere su una farm di server globale per il VoIP costava una fortuna, questa architettura era un colpo di genio.

Ma nascondeva un problema strutturale, e adesso ci arriviamo.

Va che numeri

La crescita di Skype è una di quelle curve che ti fanno girare la testa:

• 2003: 10.000 download il primo giorno della beta

• 2004: 13 milioni di utenti, 80.000 nuovi al giorno

• 2005: 54 milioni di utenti registrati (anno dell’acquisizione eBay)

• 2010: 663 milioni di utenti, 860 milioni di dollari di ricavi, 207 miliardi di minuti di chiamate

• 2013: 280 milioni di utenti attivi al mese, oltre 2 miliardi di minuti di chiamate al giorno

• Al picco: Skype gestiva circa il 40% di tutte le chiamate internazionali del pianeta

Rileggi l’ultimo punto. Il quaranta percento del traffico vocale internazionale del mondo passava da un’app gratuita costruita da un team a Tallinn, Estonia, un paese da 1,3 milioni di abitanti. Nessuna compagnia telefonica tradizionale ci si avvicinava nemmeno lontanamente.

E il modello freemium era estremo: solo il 6-7% degli utenti pagava qualcosa (le chiamate verso numeri di telefono tradizionali, SkypeOut). Il resto era tutto gratis. 194 miliardi di minuti di conversazione non fatturati in un solo anno.

Tre proprietari in otto anni

E qui la storia si complica.

Nel 2005, eBay compra Skype per 2,6 miliardi di dollari. L’idea? Far parlare compratori e venditori sulle aste. Peccato che chi compra su eBay preferisce l’anonimato di una mail, non la voce di uno sconosciuto che gli vuole vendere un divano usato. Due anni dopo, eBay svaluta di 1,4 miliardi. La tesi delle sinergie era una vaccata.

Ma il pezzo assurdo è un altro. Quando eBay comprò Skype, non comprò la tecnologia di base. Il “Global Index”, l’algoritmo P2P che faceva funzionare tutto, era rimasto in una società separata chiamata Joltid, controllata dai fondatori Zennström e Friis. eBay aveva comprato il marchio, gli utenti, il team. Ma il pulsante di spegnimento era rimasto in mano ai fondatori.

Quando eBay provò a modificare il protocollo nel 2009, Joltid fece causa chiedendo 75 milioni di dollari al giorno di danni e minacciando di revocare la licenza. Cosa che avrebbe spento Skype a livello globale, così, da un giorno all’altro.

Da CTO, questa storia mi fa venire la pelle d’oca. Comprare un prodotto senza possedere la proprietà intellettuale del componente critico è come comprare una casa scoprendo poi che le fondamenta sono in affitto e il proprietario può sfrattarti quando vuole. Se c’è una due diligence da studiare a fondo come caso a scuola, è questa.

La crisi si risolse con eBay che vendette il 65% a Silver Lake per 1,9 miliardi, ridando quote e posti in consiglio ai fondatori. La IP finalmente passò alla società.

Silver Lake tenne Skype 18 mesi e la rivendette a Microsoft per 8,5 miliardi. Un ritorno di 3x in un anno e mezzo: uno dei deal più riusciti nella storia del private equity tech.

Steve Ballmer la definì “il futuro delle comunicazioni in tempo reale.” Per gli analisti era follia pura: il prezzo era circa 10 volte i ricavi, e Skype aveva chiuso il 2010 con 7 milioni di perdita netta.

Nel 2017 Microsoft lanciò Teams, costruito internamente. Oggi Teams ha 320 milioni di utenti attivi al mese. Microsoft ha speso 8,5 miliardi per comprare le lezioni che poi ha usato per costruire il sostituto. La tecnologia è stata assorbita, il prodotto scartato.

A volte mi chiedo se Microsoft abbia mai davvero voluto salvare Skype come prodotto, o se fin dall’inizio l’obiettivo fosse assorbire il talent, i brevetti e la base utenti per poi fare le cose a modo suo. Non lo sapremo mai probabilmente.

Il redesign che nessuno voleva

Ma prima di morire per mano di Teams, Skype si era già data la zappa sui piedi da sola.

Nel 2017, sotto Microsoft, il team di prodotto decise di svecchiare l’app. Qualcuno a Redmond evidentemente si era svegliato una mattina terrorizzato che Snapchat gli stesse rubando gli utenti (ma quale utente, scusa?). Il risultato fu un disastro: storie effimere alla Snapchat, filtri facciali, colori accesi, navigazione a swipe, emoji dappertutto.

Una nonna che voleva vedere i nipoti in America si ritrovava a navigare un’interfaccia pensata per adolescenti che si mandano foto con le orecchie da cane. Un professionista che doveva fare una call con un cliente doveva prima capire dove cavolo fosse finito il pulsante per chiamare.

Le recensioni sugli App Store precipitarono da 3,5 a 1,5 stelle in poche settimane. Microsoft fu costretta a scusarsi pubblicamente e a fare rollback.

La percezione di Skype come strumento affidabile andò a farsi benedire. È una dinamica che vedo ripetersi con i miei clienti: iniziano a guardare cosa fanno i competitor, aggiungono feature che non c’entrano niente col loro core, e piano piano il prodotto diventa una cosa che non sa più cosa vuole essere. Ogni volta che succede mi torna in mente Skype e quel redesign del 2017.

Il paradosso del COVID: morire alla propria festa

Eccoci arrivati al momento che rende questa storia un caso studio perfetto. Marzo 2020, il mondo è chiuso in casa e tutti hanno bisogno di una cosa sola: videochiamare.

Il mercato per cui Skype era nata esplode come mai nella storia dell’umanità.

Un anno dopo? Zoom al 50% e Skype al 6,6%.

I numeri nel dettaglio sono ancora più brutali:

• Zoom: da 10 milioni di utenti giornalieri a 300 milioni. Un aumento del 2.900%

• Microsoft Teams: da 20 milioni a 75 milioni, poi a 300+ milioni mensili

• Skype: da 24 milioni a 40 milioni. Un +70%, poi di nuovo giù a 36 milioni

L’azienda che aveva inventato la videochiamata di massa non è riuscita a sopravvivere al momento in cui la videochiamata è diventata essenziale.

Perché? Per un motivo stupidamente semplice: l’attrito.

Su Zoom, cliccavi un link e eri dentro. Non serviva un account, non serviva scaricare niente di obbligatorio, non serviva aggiungerti alla rubrica. Un insegnante che non aveva mai fatto una videochiamata poteva radunare una classe di trenta ragazzini in cinque minuti.

Su Skype? Scarica il client, registrati con un account Microsoft, trova lo Skype ID dell’altro (spesso una stringa incomprensibile tipo “live:marco.rossi_1847”), invia una richiesta di contatto, aspetta che la accetti, poi chiama. Nel mezzo di una pandemia globale, dove nonni in lockdown volevano vedere i nipoti e medici dovevano visitare pazienti anziani da remoto, questo percorso era un muro.

Eric Yuan, fondatore di Zoom, lo aveva già capito. Aveva lasciato Cisco WebEx perché, come disse lui stesso, “dopo ogni meeting ero imbarazzato perché non avevo mai visto un singolo cliente felice”. A quel punto aveva provato a convincere il management a ricostruire da zero, ma nessuno lo ascoltò, anzi avevano semplicemente pensato che fosse pazzo. Così se ne andò e costruì Zoom con una sola ossessione: che la call diventasse un’azione semplice per chiunque, senza bisogno di mille spiegazioni.

Quello che Skype ha lasciato

Liquidare Skype come un semplice fallimento sarebbe profondamente sbagliato. L’eredità è enorme, solo che è diventata invisibile.

Il codec che alimenta Internet. Skype sviluppò SILK, un codec audio che adattava dinamicamente la qualità della voce alla banda disponibile. SILK divenne la base di Opus, lo standard IETF ora obbligatorio per WebRTC. Ogni videochiamata da browser, ogni chat vocale su Discord, ogni meeting su Zoom da web usa tecnologia che discende direttamente da Skype. Il DNA tecnico di Skype è più vivo oggi di quanto Skype stessa lo sia mai stata.

La Skype mafia. I capitali e le competenze generate dalle exit hanno trasformato l’Estonia, un paese da un milione e trecentomila abitanti, in un hub startup europeo. Gli ex Skype hanno fondato Wise (trasferimenti di denaro), Bolt (il competitor europeo di Uber), Pipedrive, Veriff e Starship Technologies, i robot per le consegne autonome fondati proprio da Ahti Heinla, l’architetto tecnico originale di Skype. La PayPal mafia della Silicon Valley ha il suo equivalente baltico, e tutto è partito da un ufficio a Tallinn.

Jaan Tallinn e l’AI safety. Il programmatore estone che a 12 anni iniziava a scrivere codice e a 17 faceva il suo primo videogioco, oggi è uno dei più importanti finanziatori della ricerca sulla sicurezza dell’AI al mondo. Ha co-fondato il Future of Life Institute e ha guidato gli investimenti Series A sia in DeepMind che in Anthropic.

Quando la CNBC gli chiese del futuro di Skype, rispose: “Sono preoccupato che gli esseri umani vengano spazzati via, quindi è improbabile che avremo bisogno di Skype se dovesse succedere.”

L’uomo che ha costruito lo strumento per connettere l’umanità ora spende la sua fortuna per evitare che venga distrutta dall’AI. Da un videogioco nell’Estonia sovietica del 1989 alla ricerca sull’AI safety nel 2026: è un arco narrativo che nemmeno uno sceneggiatore riuscirebbe a inventarsi.

L’architettura è destino

La lezione più profonda di questa storia non è sulla cattiva gestione, anche se ne abbonda.

È su cosa succede quando cambi il DNA di un prodotto.

Skype nacque peer-to-peer: distribuita, leggera, indipendente. La sua architettura non era solo una scelta tecnica, era la sua identità. Quando Microsoft centralizzò i server, sostituì il protocollo, appesantì l’interfaccia e subordinò la roadmap alla strategia corporate, non stavano aggiornando Skype. Stavano facendo un trapianto d’organi che il corpo ha rigettato.

L’architettura P2P nel 2003 era un vantaggio competitivo asimmetrico: una startup baltica senza soldi per i server poteva battere compagnie telefoniche miliardarie sfruttando i computer degli utenti. Nel 2017, quella stessa architettura era un vincolo: gli smartphone non potevano fare da supernodi, la sincronizzazione multi-device era un casino, le call di gruppo si inchiodavano oltre 25 persone.

L’ho visto da vicino: una startup che seguivo aveva scelto un monolite con database condiviso perché era veloce da lanciare, e per i primi 30 clienti era perfetto. Al centocinquesimo, ogni deploy era un’operazione chirurgica e ogni feature nuova rischiava di rompere qualcosa. La scelta architetturale che li aveva fatti crescere nel primo anno era diventata la catena che li rallentava al terzo. E la cosa più difficile non è capirlo intellettualmente. È avere il coraggio di riscrivere le fondamenta mentre il prodotto è in produzione e gli utenti ci lavorano sopra ogni giorno.

Yuan l’ha capito: non puoi prendere un tool per chiamate vocali del 2003 e trasformarlo in una piattaforma di videoconferenza moderna aggiungendo pezzi, devi costruirla da zero. Zoom ha fatto esattamente questo. Skype, appesantita da tre proprietari, otto leader diversi in dieci anni e vent’anni di debito tecnico accumulato, non ce l’ha fatta.

La domanda che mi porto a casa

Ogni volta che lavoro su un prodotto mi chiedo: stiamo costruendo sulla nostra forza vera o stiamo rincorrendo quello che fanno gli altri?

Skype ha aggiunto storie, filtri e emoji invece di rendere più semplice entrare in una chiamata. Ha rincorso Snapchat invece di ascoltare i propri utenti.

Quando il mondo intero ha avuto bisogno di videochiamare, la risposta non era in un’app con vent’anni di storia e il nome nel dizionario. Era in un tool costruito da zero da un ingegnere che si era stancato di vedere clienti infelici.

“Facciamo call su Skype” non lo dice più nessuno.

Ma ogni volta che apri una videochiamata da browser, il codec che trasporta la tua voce è un discendente diretto di quel software scritto in un ufficio a Tallinn vent’anni fa.

Skype ha lasciato la chat. Il suo codice, però, è ancora in ogni chiamata che facciamo.

Ci vediamo alla prossima newsletter.

Senza filtri,
Chri

P.S. Costruiamo insieme Senza Filtri

Ho creato un breve sondaggio anonimo per capire come migliorare la newsletter ed esserti più utile. Se ti va di rispondere a qualche domanda clicca qui (meno del tempo di prendere un caffè). Grazie mille.

[Video Youtube] Il mio 2025 da Fractional CTO

Ho messo a nudo tutto il mio 2025 da Fractional CTO. I numeri del business, i contenuti, i clienti persi per colpa mia, e la nascita di mia figlia che ha cambiato tutto.

[Guarda il video]

👋 Ciao, sono Chri. Fractional CTO e questa è Senza Filtri: la newsletter dove condivido il dietro le quinte del mio viaggio da imprenditore (esperienze, cosa ho imparato e tanti errori) alternando a qualche deep dive sui business che mi incuriosiscono.

Quando ero piccolo esisteva una rivista chiamata “Giochi per il mio computer.”

Assieme ad essa, dentro potevi trovare un CD con le demo dei giochi da provare, di solito erano cinque o sei e una volta che li avevi provati potevi decidere se comprarne uno. Ci pensavi bene, perché se ti sbagliavi erano ben cinquantamila lire buttate, mica poche.

Oppure c’erano i totem al supermercato, quei cosi con delle cuffie attaccate dove potevi ascoltare I CD prima di comprarli.

Poi te ne stavi lì in piedi, con delle cuffie che avevano usato almeno altre duecento persone prima di te (igienico… ‘na merda…) e ascoltavi tre o quattro tracce per capire se valesse la pena proseguire con l’acquisto.

Quel modello ti poneva di fronte a una conseguenza importante: dato che dovevi spendere una grossa cifra in un colpo solo, prima di comprare ci pensavi prima (bene). Valutavi, leggevi qualche recensione sulla rivista, magari chiedevi anche all’amico che l’aveva già comprato.

Ogni decisione di spesa diventava consapevole e non ti concedevi lo sbaglio perché altrimenti avresti perso i soldi.

Inoltre, non meno importante, ciò che compravi diventava effettivamente tuo: il CD era tuo, il gioco era tuo, e persino roba come Photoshop che costava un botto (se lo acquistavi) diventava tuo per sempre.

Non era meglio e non voglio fare il nostalgico rompicoglioni, però era diverso e quella diversità aveva delle conseguenze sul modo in cui ragionavamo prima di comprare qualcosa.

Come siamo finiti a noleggiare tutto

Il passaggio è stato graduale e all’inizio sembrava una cosa fantastica.

In realtà c’è stata una fase intermedia che nessuno racconta mai: la pirateria. Prima di Spotify, prima di Netflix, c’è stato Napster. E poi eMule, i Torrent, Megaupload (ve lo raccontavo in questa newsletter)

Per una generazione intera, il passaggio dal “compro il CD” al “pago l’abbonamento” è passato attraverso il “scarico tutto gratis”. E onestamente, la pirateria ha dimostrato una cosa fondamentale: le persone non vogliono rubare, vogliono accesso facile. Quando Spotify è arrivato e ha offerto un’alternativa comoda e legale a 9.99 al mese, milioni di persone hanno smesso di scaricare e hanno iniziato a pagare. Lo stesso con Netflix per i film.

La promessa è bellissima: paghi poco, hai accesso a tutto e hai sempre l’ultima versione.

Per un po’ ha funzionato davvero. Non dovevi più scegliere quale album comprare perché potevi ascoltarli tutti. Non dovevi più scegliere quale film noleggiare perché li avevi tutti. Adobe Creative Cloud ha tolto la barriera dei 2.000 euro per Photoshop e l’ha sostituita con 60 euro al mese. Era un upgrade enorme rispetto a prima e non lo nego.

Il problema è che quel modello ha funzionato così bene che tutti hanno voluto copiarlo. E quando dico tutti, intendo proprio tutti. Software, musica, film, serie TV, giornali, app di meditazione persino l’app della bibbia. Raga, ci sono app per il meteo in abbonamento. BMW ha provato a vendere il riscaldamento dei sedili in abbonamento. I sedili riscaldati della tua auto, in subscription. Ci rendiamo conto?

Se ci pensi è ironico: siamo passati dalla pirateria agli abbonamenti perché volevamo accedere in modo comodo ai contenuti, ma adesso stiamo iniziando a odiare gli abbonamenti (o almeno, io sono tra questi) perché sono diventati un modo “comodo” per svuotarci il conto.

E quindi, alla fine, qualcosa si è rotto.

La tassa silenziosa

La situazione è bella infame perché spendi di più su importi più piccoli e non sfrutti tutto.

Nessun singolo abbonamento sembra caro. “Sono solo 9.99”, “sono solo 12.99”, “sono solo 24.99”. Presi singolarmente sono cifre ridicole. Sommati a fine mese diventano centinaia di euro che escono dal conto senza che tu ci abbia pensato neanche un secondo.

E poi c’è il free trial. Quel meccanismo geniale per cui ti iscrivi per provare, ti dimentichi di cancellare, e dopo 14 giorni ti ritrovi un addebito. Di chi è la colpa? Di entrambi. Del sistema, che è progettato apposta per sfruttare la tua inerzia e tua, perché lo sapevi e l’hai fatto lo stesso. Io per primo dimentico di cancellare i free trial, non sono immune a sta roba, eh.

C’è anche il vincolo annuale: paghi l’abbonamento annuale perché costa meno del mensile, ma poi sei bloccato per un anno anche se dopo due mesi ti rendi conto che non lo usi. I tuoi dati sono dentro quella piattaforma, le tue abitudini sono costruite attorno a quel tool, e migrare è una rottura pazzesca.

E il costo non è neanche solo economico. C’è tutta la parte mentale: gestire quindici abbonamenti, ricordarsi le scadenze, valutare se rinnovare o no, tenere traccia di quale carta è collegata a cosa. È lavoro che non produce niente, energia che sprechi per gestire roba che dovrebbe semplificarti la vita e invece te la complica.

Il paradosso della scelta

C’è un effetto collaterale della subscription economy di cui si parla poco: quando tutto costa poco al mese, provi tutto. E quando provi tutto, non impari a usare bene niente.

Lo vedo su di me. L’anno scorso per il mio business avevo abbonamenti per: Anthropic, OpenAI, Google, Mistral, Perplexity e Grok. Sei abbonamenti AI. Saltavo da uno all’altro, provavo il modello nuovo, tornavo al vecchio, poi ne usciva un altro e ricominciavo il giro. Una giostra infinita che mi dava l’illusione di essere aggiornato quando in realtà stavo solo spendendo soldi.

Quest’anno ho fatto una spending review serie e il risultato è stato questo: alla fine avevo bisogno solo di Anthropic e Google, due abbonamenti soltanto. Ho scalato da sei a due. Non male, no? La cosa sorprendente però è che lavoro anche meglio perché conosco questi strumenti in profondità, so dove funzionano e come, ho costruito dei workflow solidi invece di rincorrere la novità dell’ultima settimana. Avere meno scelta mi ha reso più efficace, senza “distrazioni”, perché il modello subscription ti spinge nella direzione opposta: prova tutto, paga poco per ognuno, ma non impegnarti e non approfondire niente.

Che poi, se ci pensi, è la stessa dinamica delle app di dating… ma questa è un’altra newsletter.

La promessa tradita

E qui arriviamo al punto che mi fa più incazzare, perché le aziende che hanno creato il modello subscription lo sanno benissimo che funziona così. Ci contano.

La promessa iniziale era: paghi meno, hai sempre l’ultimo aggiornamento, sei più libero di prima. Facciamo il punto su come è andata.

I prezzi salgono. Netflix è partito a 7.99, adesso per il piano senza pubblicità siamo quasi al doppio. E sì, se non paghi di più ti mettono la pubblicità dentro un servizio che stai già pagando. Spotify aumenta, Adobe aumenta, tutti aumentano. E tu paghi, perché ormai sei dentro e uscire costa più che restare.

Le feature peggiorano o finiscono dietro paywall. Roba che prima era inclusa adesso diventa un add-on. È come se il tuo padrone di casa a un certo punto ti facesse pagare un extra per usare il balcone. Lo stesso balcone che c’era già quando hai firmato il contratto.

Ti faccio un esempio concreto con Notion. Che io uso e pago volentieri, sia chiaro. Ma a un certo punto hanno introdotto l’AI dentro al prodotto, una feature che nessuno aveva chiesto, e l’hanno messa come add-on a 10 dollari al mese per persona. Se hai un team di dieci persone sono 100 dollari in più al mese per qualcosa che prima non esisteva e che probabilmente non userai mai a pieno regime. È il classico meccanismo: ti aggiungo qualcosa, te lo faccio provare gratis per un mese, poi vediamo se te ne accorgi quando inizia a costarti.

E la libertà? Quella è la parte più grossa della promessa tradita. Sei meno libero di prima. Quando compravi Photoshop in scatola, Adobe poteva anche fallire il giorno dopo e tu continuavi a usare il software. Oggi se Adobe decide di cambiare i termini del servizio, tu non hai alternative. I tuoi file, i tuoi progetti, le tue abitudini di lavoro sono tutti dentro il loro ecosistema. Non possiedi più niente di quello che usi tutti i giorni, e la cosa che mi fa impazzire è che ci siamo arrivati un passo alla volta senza quasi accorgercene.

Quando il pricing diventa una decisione di prodotto

Questa spending review che ho fatto sui miei tool AI mi ha costretto a ragionare su una cosa che vedo anche nel mio lavoro con le startup.

Qualche mese fa un founder mi ha chiesto consiglio sul pricing del suo prodotto. La prima cosa che mi ha detto è stata: “Facciamo un abbonamento mensile, come fanno tutti.” Gli ho chiesto perché. Mi ha guardato come se la risposta fosse ovvia: “perché è il modello standard.”

Abbiamo ragionato insieme e alla fine ha scelto un modello diverso: una versione gratuita con le feature base e un upgrade one-time per le feature avanzate. Niente abbonamento, niente rinnovo, niente “sono solo X euro al mese”. I primi numeri gli stanno dando ragione, perché i suoi utenti avevano già troppi abbonamenti e un acquisto singolo era una barriera psicologica molto più bassa.

Il punto è che il mercato è cambiato. I potenziali clienti di quel founder hanno già 30 abbonamenti e la loro soglia di tolleranza per aggiungerne un altro è molto più bassa di qualche anno fa. Il subscription model non è sbagliato in sé, ma non è l’unica opzione e non è automaticamente la migliore. La domanda “perché un abbonamento e non un’altra forma?” andrebbe fatta sempre, e quasi nessuno se la fa.

Dall’altro lato c’è il tema del make vs buy, di cui ho parlato nella newsletter su come ho risparmiato 788 euro l’anno costruendomi i tool con l’AI. Saper valutare cosa comprare, cosa costruire internamente e cosa eliminare del tutto è una competenza che quasi nessuno sviluppa. Io stesso ci ho messo anni a costruirmela, e ancora adesso a volte sbaglio. L’anno scorso ho tenuto un abbonamento per mesi convinto che “prima o poi mi sarebbe servito” (e non mi è mai servito). È che cancellare qualcosa ti dà l’ansia di perdertelo, anche quando non lo usi. È lo stesso meccanismo per cui tieni vestiti nell’armadio che non metti da tre anni “perché non si sa mai”.

La maggior parte delle persone e delle aziende non fa mai questo esercizio. Rinnovano tutto in automatico perché “si è sempre fatto così” o perché “sono solo 10 euro al mese”. Moltiplicato per 20 tool fanno 200 euro al mese che forse non servono a niente.

Uscire dalla trappola

E qui ti sembrerà che io stia dicendo che gli abbonamenti sono il male: ma non è questo il punto, anche perché alcuni hanno senso e li pago pure voilentieri. Per esempio YouTube Premium per me vale ogni centesimo, lo uso ogni giorno, idem Notion. Non tutto va eliminato, e non tutto va costruito da zero.

Ma non è per forza giusto che tutto sia in abbonamento. Ci siamo abituati a questo modello come se fosse l’unica possibilità e non lo è. Ci sono segnali di inversione: alcuni developer stanno tornando al one-time purchase per i loro tool, il freemium intelligente sta guadagnando terreno, e i consumatori stanno iniziando a cancellare abbonamenti che davano per scontati da anni.

Io ho iniziato a fare una cosa semplice: una volta ogni sei mesi apro il conto, guardo tutti gli addebiti ricorrenti e mi chiedo per ognuno se mi serve davvero. La mia spending review. Non è che sia un esercizio piacevole, tra l’altro. Ti ritrovi davanti a cose che paghi da un anno e che non apri da mesi. Ti senti pure un po’ scemo, però funziona.

Quando compravi il CD al supermercato dopo averlo ascoltato al totem con le cuffie, ci pensavi prima di spendere quei soldi. Quella attenzione non è sparita, è solo sepolta sotto una montagna di “sono solo 9.99 al mese”.

Quanti abbonamenti stai pagando adesso che non ricordi nemmeno di avere?

Rispondi a questa mail, sono curioso di sapere com’è messa la tua lista.

Ci vediamo alla prossima newsletter.

Senza filtri,
Chri

P.S. Costruiamo insieme Senza Filtri

Ho creato un breve sondaggio anonimo per capire come migliorare la newsletter ed esserti più utile. Se ti va di rispondere a qualche domanda clicca qui (meno del tempo di prendere un caffè). Grazie mille.

[Piccola interruzione] Ho pubblicato il mio primo video

Perché ho deciso di fare video? Perché proprio ora? In questo primo video rispondo proprio a questa domanda. Mi raccomando iscriviti, metti like e lascia un commento con qualsiasi feedback o con la tua opinione.

[Guarda il video]

👋 Ciao, sono Chri. Fractional CTO e questa è Senza Filtri: la newsletter dove condivido il dietro le quinte del mio viaggio da imprenditore (esperienze, cosa ho imparato e tanti errori) alternando a qualche deep dive sui business che mi incuriosiscono.

Ogni mattina la prima cosa che apro è GitHub. Non le mail e nemmeno LinkedIn. Ma GitHub. Fa talmente parte della mia routine che a volte mi dimentico che c’è stato tutt’altro mondo prima.

GitHub è gratis. Per me, per te, per tutti gli sviluppatori del pianeta. Puoi caricare tutto il codice che vuoi, collaborare con chi vuoi, e non paghi un centesimo.

Eppure Microsoft ha pagato 7,5 miliardi di dollari per comprarlo e oggi gli genera più di 2 miliardi di dollari all’anno.

Qualcosa non torna, no? O forse torna fin troppo bene. E la storia di come ci sono arrivati è una delle più belle che abbia mai studiato.

Prima di GitHub: il medioevo del codice

Per capire perché GitHub è stato rivoluzionario, bisogna capire com’era la vita prima del 2008. E fidati, non era bella.

Il controllo del versionamento esisteva. C’era SVN, c’era CVS. Sistemi centralizzati dove tutto il codice stava su un singolo server. Se il server andava giù, non potevi fare niente. Se eri offline, non potevi nemmeno salvare le modifiche. E fare il merge del codice tra colleghi era una bella rottura.

Contribuire a un progetto open source poi era un’impresa. Dovevi scaricare il codice, fare le modifiche, creare un file di patch, formattarlo nel modo giusto, mandarlo via mail a una mailing list, e sperare che qualcuno lo leggesse. Se avevi fortuna ti rispondevano dopo qualche settimana.

SourceForge esisteva ma era pensato per scaricare software, non per collaborare. L’interfaccia era brutta, lenta, e non c’era nulla di sociale.

Poi nel 2005 Linus Torvalds, il creatore di Linux, si trovò in una situazione assurda: il tool che usava per gestire il kernel gli revocò la licenza gratuita. E Linus, da Linus, cosa fece? Si scrisse il suo sistema di controllo versione in una decina di giorni.

Lo chiamò Git. Potentissimo, ma anche ostico da morire. Comandi a riga di comando che sembravano scritti in aramaico. Per un programmatore esperto andava bene, per tutti gli altri era come guidare una Formula 1 quando al massimo sapevi andare in bicicletta.

Mancava qualcosa: un pezzo che rendesse Git… umano.

Quattro tizi in un bar di San Francisco

Ottobre 2007. Tom Preston-Werner e Chris Wanstrath si ritrovano allo Zeke’s Sports Bar di San Francisco dopo un meetup Ruby che si chiamava, giuro, “I Can Has Ruby”.

Preston-Werner stava lavorando su una libreria Ruby per interfacciarsi con Git e aveva un’idea: creare un posto sul web dove caricare i repository Git, navigarli con un’interfaccia grafica, e collaborare senza dover configurare server Unix e chiavi SSH a mano.

Un “hub” per Git. GitHub.

Wanstrath acconsentì immediatamente e iniziarono a scrivere codice lo stesso mese. Il 19 ottobre Wanstrath fece il primo commit della storia di GitHub. A gennaio si unì PJ Hyett seguito da Scott Chacon, uno dei massimi esperti di Git al mondo.

Registrarono la società come “Logical Awesome LLC” (forse il miglior nome mai dato a un’azienda, anche se purtroppo poi lo cambiarono) e nell’aprile del 2008 la aprirono al pubblico.

Preston-Werner all’epoca lavorava in una startup che si chiamava Powerset. Quando Microsoft acquisì Powerset nel 2008, gli offrì un bonus da 300.000 dollari per restare. Lui rifiutò per concentrarsi su GitHub, che in quel momento non generava praticamente nulla. Dieci anni dopo la stessa Microsoft pagò 7,5 miliardi per quel side project. Vorrei tanto aver visto la faccia del manager di Powerset quel giorno.

Il primo giorno fecero 1.000 dollari di ricavi. Senza un investitore, senza un ufficio, senza nemmeno pagarsi lo stipendio. Lavoravano dai bar del quartiere North Beach e comunicavano su Campfire di 37signals.

Geoffrey Grosenbach, uno dei primi utenti, si offrì letteralmente di spedirgli un assegno per posta perché si sentiva in colpa a non pagare.

Quando i tuoi utenti ti pregano di farli pagare, hai capito che hai qualcosa tra le mani.

La pull request che ha cambiato il modo di scrivere codice

Tecnicamente GitHub non ha inventato niente di nuovo, Git esisteva già e l’hosting del codice pure.

Quello che hanno realmente inventato è stato il modo in cui le persone possono collaborare sul codice. E non è roba da poco.

Hanno preso il “fork”, che nella cultura open source era praticamente una parolaccia (significava spaccare una community, creare un progetto rivale, roba da scisma religioso), e l’hanno trasformato in un bottone. Clicchi Fork, ti crei la tua copia, fai esperimenti e quello che vuoi senza rompere niente a nessuno.

E poi hanno costruito la pull request come la conosciamo oggi.

Prima di GitHub, proporre una modifica a un progetto significava formattare una patch e mandarla per email a una mailing list. Con la pull request di GitHub clicchi un bottone, scrivi cosa hai cambiato e perché, le persone commentano direttamente sulle righe di codice, si apre una discussione, e alla fine qualcuno fa merge con un click.

Sembra scontato adesso, ma nel 2008 era fantascienza. La pull request ha abbassato la barriera d’ingresso all’open source in un modo che prima era impensabile. Chiunque poteva proporre una modifica a qualsiasi progetto al mondo, direttamente dal browser.

E poi c’era tutto il social layer: profili sviluppatore con activity feed, i famosi “quadratini verdi” dei contributi (che hanno creato più dipendenza di un raid settimanale su WoW), stelle ai repository, follower. GitHub non era solo un posto dove mettere il codice, era diventato un social network per chi scrive software e il tuo profilo, alla fine, diventava il tuo curriculum.

Scott Chacon, uno dei co-fondatori, ha detto una cosa che mi è rimasta in testa: “È quasi impossibile ricordare com’era l’open source prima di GitHub.”

Ha ragione. È come cercare di ricordare com’era cercare qualcosa su internet prima di Google.

Va che numeri

Partiamo da dove sono partiti loro: 1.000 dollari il primo giorno. A luglio 2009, 100.000 utenti. Il 95% del traffico era organico. Niente marketing, niente ads, niente sales team.

Oggi:

• Più di 150 milioni di sviluppatori

• Oltre 420 milioni di repository

• 2 miliardi di dollari di fatturato annuo

• Il 90% delle aziende Fortune 100 lo usa

• 4,7 milioni di abbonati paganti a Copilot

• Circa 230 nuovi repository creati ogni minuto

Da quattro persone in un bar a 6.000 dipendenti.

E la parte che mi ha stupito di più: per quattro anni non hanno preso un centesimo da investitori esterni. Erano profittevoli dal primo giorno.

Il paradosso del bootstrap

Questa è la parte della storia che mi ha fatto riflettere.

GitHub per quattro anni è stata un’azienda bootstrapped e profittevole. I fondatori giravano le conferenze a parlare di quanto fosse pericoloso prendere soldi dai VC troppo presto. Preston-Werner diceva: “Crediamo ancora che prendere troppi soldi troppo presto possa essere dannoso per un’azienda. Siamo passati quattro anni e mezzo definendo noi stessi prima di accettare capitale esterno.”

Poi nel luglio 2012 hanno preso 100 milioni di dollari da Andreessen Horowitz. La più grande Serie A che a16z avesse mai scritto in quel momento. Valutazione: 750 milioni.

Ipocriti? Non proprio.

Quando hanno preso quei soldi, GitHub era già GitHub. Avevano 1,7 milioni di utenti, erano profittevoli, avevano un brand fortissimo nella community degli sviluppatori. Non avevano bisogno dei soldi per non morire. Li hanno presi per scalare l’offerta enterprise e aprire mercati nuovi.

Come disse Preston-Werner: “La nostra azienda è profittevole da anni, cresce veloce e non ha bisogno di soldi. Allora perché prenderli? Perché vogliamo essere migliori.”

Quando negoziare con i VC è una scelta e non una questione di sopravvivenza, è tutto un altro sport raga.

Nel 2015 arrivò un Series B da 250 milioni guidata da Sequoia, valutazione 2 miliardi. Totale raccolto: 350 milioni. Sei anni dopo il Series A, Microsoft pagò 7,5 miliardi. Solo a16z fece un ritorno di circa un miliardo sul loro investimento da 100 milioni.

La monetizzazione al contrario

Repository pubblici? Gratis, illimitati. Pull request, issue, hosting, collaborazione? Tutto gratis. Alla fine hanno reso gratuiti anche i repository privati per uso individuale (ci arriviamo).

I soldi arrivano quando il team ha bisogno di controlli di sicurezza avanzati, SSO, compliance, governance, e tutta quella roba che serve a far dormire tranquilli i CISO e i dipartimenti legali.

E qui scatta il meccanismo geniale.

Uno sviluppatore usa GitHub nel weekend per i suoi progetti personali. Il lunedì arriva in ufficio, si ritrova a combattere con il SVN aziendale, e pensa: “Ma perché non usiamo GitHub?” Ne parla al team, il team ne parla al CTO, il CTO chiede un budget, e il contratto enterprise si chiude praticamente da solo.

GitHub non ha mai avuto bisogno di un grande team di vendita che facesse cold call ai dirigenti. Gli sviluppatori erano il team di vendita e ogni utente gratuito era un potenziale champion dentro la propria azienda.

Chris Wanstrath la metteva con più ironia: “I nostri amici volevano pagare, ed era una cosa nuova, perché avevo passato anni cercando di fare soldi da loro senza riuscirci.”

Entro il 2016 GitHub Enterprise generava il 50% dei ricavi, con una crescita vicina al 300% annuo nei primi anni. Non vendevano hosting Git, quello era diventato una commodity. Vendevano l’accesso a un ecosistema che i loro sviluppatori usavano già, con le garanzie di sicurezza e compliance che il reparto IT pretendeva.

Il nemico diventa alleato (per 7,5 miliardi)

Il 4 giugno 2018 Microsoft annuncia l’acquisizione di GitHub per 7,5 miliardi in azioni.

L’ironia era colossale. L’ex CEO Steve Ballmer nel 2001 aveva definito Linux “un cancro”. E adesso Microsoft pagava 7,5 miliardi per la piattaforma dove vive praticamente tutto l’open source del mondo.

La community reagì come ti aspetteresti. GitLab vide 10 volte il volume normale di migrazioni. In una singola ora, 13.000 progetti vennero spostati via, c’era gente che parlava di un “abbraccio mortale” di Microsoft. Petizioni, thread furiosi, meme ovunque.

Nat Friedman, il nuovo CEO scelto per guidare GitHub, andò su Reddit e disse una frase che valeva più di qualsiasi comunicato stampa: “Se Microsoft rovina questa cosa, perderemo la fiducia degli sviluppatori per un’intera generazione.”

E poi Microsoft fece la mossa più intelligente possibile: rese i repository privati gratuiti per tutti.

Pensa alla scena: tu compri un’azienda per 7,5 miliardi e la prima cosa che fai è rendere gratis qualcosa che prima era a pagamento.

Follia? No, strategia pura. Ogni sviluppatore in più sulla piattaforma è un futuro cliente Azure, Copilot, enterprise. Tutto l’ecosistema Microsoft ne beneficia.

I numeri gli hanno dato ragione in modo spettacolare. Da 28 milioni di utenti al momento dell’acquisizione a più di 150 milioni oggi. Da circa 250 milioni di fatturato a 2 miliardi. E Copilot, il tool di AI per scrivere codice, da solo genera più ricavi di quanti ne facesse tutta GitHub prima dell’acquisizione.

Satya Nadella aveva capito una cosa che Ballmer non avrebbe mai capito: gli sviluppatori non li possiedi, li conquisti diventando così utile che non possono più fare a meno di te.

Il pattern che si ripete

Se ci fai caso, è lo stesso copione ogni volta.

Slack: gli sviluppatori lo adorano, lo portano in azienda, l’azienda paga. Venduto a Salesforce per 27,7 miliardi.

MongoDB: Community Edition gratuita, la usi sul tuo progetto, quando devi andare in produzione l’azienda compra Atlas. Oggi 1,6 miliardi di fatturato.

Docker: miliardi di download gratuiti, poi le aziende pagano per le funzionalità enterprise e la sicurezza.

Ma attenzione, non tutti ci riescono. Docker per anni ha provato a vendere top-down all’enterprise, con un team di vendita tradizionale, e ha quasi fallito con 335 milioni investiti e meno di 75 milioni di fatturato. Solo quando è tornato al modello bottom-up, dal developer all’azienda, è passato da 11 a 135 milioni in due anni.

La cosa che ho capito lavorando con le startup è che la differenza tra chi crea miliardi con questo approccio e chi ci brucia i soldi è una sola: la pazienza. La stragrande maggioranza dei tuoi utenti non pagherà mai, e vanno trattati come il bene più prezioso che hai, perché sono loro che costruiscono il network effect che rende il prodotto indispensabile.

La domanda che mi porto a casa

Ogni volta che lavoro con una startup e parliamo di pricing, c’è sempre quel momento in cui qualcuno dice: “Ma se lo diamo gratis, come facciamo soldi?”

Preston-Werner aveva una frase per rispondere: “GitHub Everywhere.” Gratis per chiunque facesse open source, studiasse, o lavorasse per conto suo. Le aziende, quelle sì, pagano.

Alla fine, “everywhere” è esattamente dove sono finiti. 150 milioni di sviluppatori, 2 miliardi di fatturato.

La domanda che mi faccio è: quanto del valore del tuo prodotto stai regalando per costruire il network che un giorno lo renderà indispensabile?

Ci vediamo nella prossima newsletter

Senza filtri,
Chri

P.S. Costruiamo insieme Senza Filtri

Ho creato un breve sondaggio anonimo per capire come migliorare la newsletter ed esserti più utile. Se ti va di rispondere a qualche domanda clicca qui (meno del tempo di prendere un caffè). Grazie mille.

Primo giorno con un nuovo cliente. Il founder mi accoglie in call, condivide lo schermo e mi mostra il repository. “Ecco, questo è il codice. Da dove vuoi partire?”

“Dal business.”

Non se l’aspettava. Mi aveva assunto come CTO e la prima cosa che gli chiedo è stata quella di raccontarmi come funziona l’azienda, chi sono i clienti, dove vogliono arrivare tra sei mesi. Roba che non c’entra niente con il codice.

Questa scena, con variazioni diverse, si ripete quasi ogni volta che entro in una nuova startup. Mi chiamano per un motivo e il vero lavoro da fare è un altro.

In questo numero di Senza Filtri voglio raccontarti cosa succede davvero nei miei primi 90 giorni quando entro in una startup e perché è molto diverso da quello che la maggior parte dei founder si immagina.

Giorni 0-30: non tocco il codice (quasi)

Una delle prime volte che sono entrato in una startup come Fractional CTO ho fatto esattamente quello che tutti si aspettano. Mi sono seduto, ho aperto il repository, ho letto il codice per giorni, ho analizzato l’architettura e ho preparato un bel documento con tutte le mie raccomandazioni tecniche. Potrebbe sembrare un lavoro impeccabile, peccato che stessi risolvendo i problemi sbagliati.

Non avevo capito dove voleva andare il business. Non avevo parlato con gli utenti, non avevo guardato i numeri, non avevo chiesto ai founder cosa li teneva svegli la notte al di là del codice. Avevo fatto il CTO da manuale e il risultato era un documento che non serviva a niente. Ho dovuto rifare tutto da capo, una rottura pazzesca.

Da quella volta ho cambiato completamente approccio.

Oggi quando entro in una startup la prima cosa che faccio è sedermi con i founder e fargli un botto di domande che non c’entrano niente con la tecnologia. Chi sono i vostri utenti, come li raggiungete, dove perdete le persone nel flusso, qual è il modello di business, dove volete essere tra sei mesi. Roba da business manager, non da CTO.

Poi guardo il prodotto, ma in ottica di prodotto: come è costruito, dove funziona, dove fa schifo, quali sono le frizioni che gli utenti sentono. E solo dopo tutto questo arrivo alla tecnologia. Lo stack, l’architettura, il team, come shippano.

Lo so che sembra controintuitivo per un CTO, ma la realtà è che senza capire il business qualsiasi decisione tecnica è campata in aria. Puoi avere l’architettura più elegante del mondo, ma se stai costruendo la cosa sbagliata non importa a nessuno.

Le urgenze che nessuno aveva visto

C’è un pattern che si ripete ogni volta: io e i founder parliamo in fase di discovery, quindi sappiamo sempre quali sono gli obiettivi quando arrivo, anche se tra quelli concordati e la realtà c’è quasi sempre uno scarto; perché entri, inizi a guardare le cose da vicino e alla fine trovi un botto di urgenze che non erano state preventivate.

A volte manca qualcuno che abbia una vera direzione di prodotto, un mindset di product management. In quei casi coinvolgo persone della mia rete con competenze verticali, perché è una cosa che posso fare io ma che preferisco delegare a chi la fa meglio di me.

Altre volte ci sono cose da fare prima di quelle che avevamo pianificato, cose che i founder non vedevano perché erano troppo dentro al day-to-day per accorgersene.

La startup che ti raccontavo all’inizio è l’esempio perfetto; mi avevano chiamato per velocizzare lo sviluppo, avevano un team piccolo, il prodotto cresceva e sentivano di star andando troppo lenti. Quindi il mio ruolo è stato: iniziare a fare domande, capire il business, parlare col team e osservare il prodotto.

Mi sono reso conto che non avevano ancora validato quello che stavano costruendo: stavano mettendo feature su feature senza aver capito quello che serviva davvero ai loro utenti.

Gli ho suggerito di non investire sullo sviluppo tradizionale ma di usare strumenti di AI per ricostruire un MVP leggero e iterare direttamente con i clienti. Zero intermediari tra chi parla con gli utenti e chi modifica il prodotto. Ne ho parlato anche nella newsletter su come l’AI ha ribaltato il mio lavoro: quando uno strumento ti permette di fare in quattro giorni quello che prima prendeva quattro mesi, il collo di bottiglia si sposta.

Non era quello che si aspettavano dal CTO, ma era quello che serviva.

Il mio lavoro nei primi 30 giorni alla fine è tutto qui: capire quali sono le vere urgenze e avere il coraggio di dire “questa cosa che avevamo pianificato può aspettare, facciamo prima quest’altra”. Non è sempre facile da far digerire, ma è per questo che mi pagano.

Giorni 30-60: adesso si fa

Passati i primi 30 giorni il contesto è chiaro. So dove siamo, so dove dobbiamo andare, so quali sono i problemi veri. E adesso bisogna iniziare a portare risultati, perché le analisi vanno bene ma a un certo punto servono le cose fatte.

Quello che faccio è prendere i problemi che ho identificato e li trasformo in un piano di lavoro concreto, qualcosa che in genere dura due settimane. In questa fase servono quick win, low hanging fruit che dimostrino al team e ai founder che le cose stanno andando nella direzione giusta. Ecco perché i primi sprint sono i più importanti, perché danno ritorno a ciò che ci sarà dopo.

In parallelo metto a terra una metodologia di lavoro, un flusso che permetta a tutti di sapere cosa fare, come farlo e quando è fatto. Sprint, priorità chiare, ownership definita. È roba che sembra banale ma che nella maggior parte delle startup early stage semplicemente non esiste. Quello che succede quando la introduci è che le persone smettono di rincorrersi e iniziano a lavorare nella stessa direzione. Prima ognuno aveva la sua idea di cosa fosse urgente, adesso c’è una lista condivisa e si va avanti insieme.

Ma c’è un prerequisito senza il quale niente di tutto questo funziona: la trasparenza.

La mia capacità di essere efficace dipende dalla fiducia e dalla trasparenza dei founder. Ho bisogno di sapere dove si vuole arrivare, quanta runway c’è, qual è il burn rate, se ci sono problemi nel team che non emergono nelle riunioni. Se hai 18 mesi di runway possiamo ragionare con calma. Se ne hai 6, ogni decisione ha un peso diverso e io ho bisogno di saperlo per non pianificare come se il tempo fosse infinito.

Giorni 60-90: far fare

Se i primi 30 giorni sono “capire” e i secondi sono “fare”, gli ultimi 30 sono “far fare”. Il mio ruolo qui cambia, passo da quello che fa le cose a quello che mette gli altri nelle condizioni di farle. Si tratta di qualcosa che ho provato sulla mia pelle: in una delle prime esperienze come leader è andato tutto bene finché c’ero io, però appena ho ridotto il mio coinvolgimento, il team ha iniziato a rallentare. Erano bravi, ma ogni decisione passava ancora da me, col risultato che avevo costruito un sistema che dipendeva dalla mia presenza. E quando me ne sono andato… beh, si è visto.

Da lì ho capito che il mio lavoro non è risolvere i problemi. È mettere le persone nelle condizioni di risolverli da sole.

Quindi in questa fase si inizia a ragionare in ottica di team: quali sono i gap di competenze, se serve assumere qualcuno, e se sì chi e per fare cosa. Come ridistribuiamo le responsabilità con le persone che ci sono. I processi che abbiamo messo a terra nei 30-60 adesso devono girare in autonomia.

Con i primi risultati in mano si costruisce una roadmap a 3-6 mesi che sia realistica, basata su quello che abbiamo imparato nei primi 60 giorni. Si definiscono le metriche per capire se stiamo andando nella direzione giusta, e non parlo solo di KPI tecnici ma anche di prodotto e di business, perché se il team tech non sa come il suo lavoro impatta sul business sta lavorando al buio.

E la relazione con i founder cambia. Nei primi 30 giorni erano update operativi, “ho guardato questo, ho trovato quello”. Adesso sono conversazioni strategiche su dove siamo, dove possiamo andare e cosa serve per arrivarci. Il segnale che le cose stanno funzionando è quando il founder smette di chiederti “cosa facciamo?” e inizia a dirti “ho pensato che potremmo fare così, che ne dici?”.

Io sono un Fractional CTO, non sono lì per sempre. Se quando me ne vado il team non è autonomo, ho fallito.

La cosa che dico sempre ai founder

C’è una cosa che ripeto a ogni founder prima di iniziare a lavorare insieme: trattami come un co-founder, non come un consulente esterno.

È come gli avvocati: per creare una buona strategia difensiva devono conoscere i fatti. Tutti i fatti, anche quelli scomodi e se mi nascondi che hai solo tre mesi di runway, io pianifico come se ne avessi dodici. Se non mi dici che nel team c’è qualcuno che sta per andarsene, io costruisco piani che si reggono su una persona che tra un mese non ci sarà più.

Ogni startup è diversa. I tempi cambiano, le priorità cambiano, le persone cambiano. Ma il percorso di fondo è sempre lo stesso: prima capisci, poi fai, poi fai fare. E la cosa che li accomuna tutti è che il vero lavoro non è quasi mai quello che il founder si aspetta.

Se stai pensando di prendere un CTO per la tua startup, chiediti se sei pronto a condividere tutto. Se sei pronto a sentirti dire che la priorità non è quella che pensavi.

Perché è da lì che parte tutto.

Ci vediamo alla prossima newsletter.

Senza filtri,
Chri

Io me la ricordo eccome. Avevo chiesto il permesso a mamma e papà (cavolo se ne è passato di tempo…) e non sapevo nemmeno cosa fosse “un indirizzo mail”.

Per la mia generazione, l’indirizzo @hotmail.com era il primo passaporto per internet. Lo mettevi ovunque: nelle chat, nei forum, nei profili MSN. Era tuo, non di tuo padre, non della scuola, non del provider internet.

Tuo soltanto.

E la cosa assurda è che quel prodotto, che per noi era semplicemente “la mail”, non doveva nemmeno esistere. Non lo sapevo? Siediti, che adesso te lo racconto.

Prima di Hotmail: la mail era una prigione

Per capire quanto Hotmail fosse rivoluzionario, bisogna capire com’era la posta elettronica nel 1996.

La tua email era legata al tuo Internet Service Provider. Se avevi AOL, il tuo indirizzo era @aol.com. Se avevi CompuServe, era @compuserve.com. Cambiavi provider? Perdevi la mail. Cambiavi lavoro? Perdevi la mail. Andavi in vacanza? Non potevi leggere la mail.

Per accedere alla posta serviva un software specifico, tipo Eudora o Pine, configurato su un singolo computer. Dovevi sapere cos’era un server POP3, inserire porte, configurare parametri che il 99% delle persone non capiva.

La mail era un servizio accessorio legato a un contratto, niente di più.

Due ingegneri, un firewall e un’idea

Sabeer Bhatia e Jack Smith si erano conosciuti lavorando in Apple, per poi finire insieme in un’azienda chiamata Firepower Systems.

Avevano un problema banale: volevano comunicare privatamente durante il lavoro per scambiarsi idee sulla startup che sognavano di fondare. Ma il firewall aziendale bloccava l’accesso alle email personali.

Bloccava la posta, non bloccava il web.

L’intuizione fu immediata: se l’email fosse stata accessibile da un browser, come una qualsiasi pagina web, il firewall non l’avrebbe fermata. Niente software da installare, niente configurazioni. Apri il browser, fai login, leggi la posta.

Da qualsiasi computer, in qualsiasi posto del mondo.

Oggi ci sembra ovvio, ma nel 1996 era fantascienza.

Venti rifiuti e 250 dollari in tasca

Bhatia era arrivato negli Stati Uniti dall’India a 19 anni con 250 dollari e una borsa di studio per il Caltech. Quel background gli aveva dato una cosa che in Silicon Valley vale più di qualsiasi MBA: la caparbietà di chi non ha alternative.

Per non farsi copiare l’idea, i due fondarono una società fittizia chiamata JavaSoft (che nome eh...) e iniziarono a fare il giro dei VC su Sand Hill Road.

Venti rifiuti. Uno dopo l’altro.

I VC non capivano il modello: “Come fai soldi se il prodotto è gratis?” alcuni dubitavano che avrebbero mai raggiunto 50.000 utenti.

Al ventunesimo tentativo, Tim Draper di Draper Fisher Jurvetson disse sì. Investì 300.000 dollari per il 15% della società, valutandola 2 milioni (pazzo? visionario? giudicalo tu).

Il nome lo scelsero con un trucco: HoTMaiL, con le maiuscole su H-T-M-L, per sottolineare che era un prodotto costruito sul web.

Lo lanciarono il 4 luglio del 1996, lo stesso giorno dell’indipendenza americana. Il simbolismo era decisamente intenzionale: indipendenza dagli ISP, dal computer fisico e dai provider.

“P.S.: I love you”

Hotmail cresceva, ma non abbastanza velocemente. In una riunione, Tim Draper chiese ai fondatori come pensavano di fare marketing.

Bhatia rispose: cartelloni sulla Highway 101 e pubblicità in TV.

Draper fu diretto: con quei soldi avrebbero potuto comprare “circa un nanosecondo di TV e un francobollo su un cartellone per un giorno.”

Ispirato da un case study di Harvard sulle vendite Tupperware, dove i clienti diventano la forza vendita, Draper propose qualcosa di diverso: inserire un messaggio automatico in fondo a ogni email spedita dagli utenti di Hotmail.

Il testo che suggerì: “P.S.: I love you. Get your free email at Hotmail.”

I fondatori dissero no, categoricamente. Per loro era spam, una violazione della privacy dell’utente.

Draper insistette e la discussione si accese. Alla fine arrivarono a un compromesso: il messaggio sarebbe stato inserito, ma senza il “P.S.: I love you”. Solo una riga: “Get your free email at Hotmail”, con un link cliccabile.

Draper, a distanza di anni, scherza ancora: “Se avessero tenuto l’I love you, il mondo sarebbe un posto più pacifico.”

La curva che nessuno aveva mai visto

Quella riga cambiò tutto.

Non era un programma di referral dove dovevi scegliere di consigliare il prodotto. Era integrata nel prodotto stesso: ogni email che mandavi era pubblicità gratuita, recapitata a qualcuno che ti conosceva e si fidava di te.

Cliccavi il link, ti registravi in trenta secondi e poi iniziavi a mandare mail. Tutte con la stessa riga in fondo.

I numeri:

Prima ora di lancio: 100 iscritti.

Primo mese: 20.000 utenti.

Settembre 1996 (tre mesi): 100.000 utenti.

Gennaio 1997 (sei mesi): 1 milione di utenti.

Cinque settimane dopo: 2 milioni.

Dicembre 1997 (diciotto mesi): 12 milioni di utenti.

Oltre l’80% delle iscrizioni arrivava da quella riga in fondo alle email. Il costo di acquisizione per utente era di circa 4 centesimi di dollaro.

Nel frattempo, il competitor Juno spendeva oltre 20 milioni di dollari in pubblicità tradizionale, cartelloni, TV, stampa, e raggiungeva 2 milioni di utenti. Juno spendeva 5-10 dollari per ogni utente acquisito. Hotmail, 4 centesimi.

Ogni volta che vedo una startup bruciare budget in ads sperando che i numeri salgano, mi torna in mente questo confronto. Non c’è partita.

100.000 utenti indiani da una singola email

La storia più assurda della crescita di Hotmail riguarda l’India.

Bhatia mandò una mail ad un amico in India, invitandolo a provare il servizio. Tre settimane dopo Hotmail aveva 10.000 utenti indiani senza aver speso un centesimo in marketing locale, ma anche senza sapere cosa stesse succedendo.

Il dettaglio che rende questa storia surreale: nel 1996, in tutta l’India c’erano probabilmente meno di 100.000 computer connessi a internet. Gli utenti accedevano da internet café, laboratori universitari, uffici condivisi. Ogni persona che si iscriveva diventava un punto di propagazione per tutti quelli intorno.

Hotmail divenne il leader di mercato in India e in Svezia senza averlo pianificato. Come disse Draper: “Hotmail è il più grande provider email in Svezia e India nonostante non abbiano mai fatto marketing di nessun tipo in quei paesi.”

Il prodotto si vendeva da solo, letteralmente.

Il “janitor” impazzito e il 25% delle inbox cancellate

Crescere così velocemente, nel 1997, senza il cloud computing di oggi, era un incubo operativo. E ogni tanto l’incubo diventava realtà.

Hotmail aveva un processo automatizzato, soprannominato internamente “the janitor” (il custode), che durante la notte svuotava le cartelle Cestino degli utenti per recuperare spazio sui dischi.

Una notte, un bug fece impazzire il janitor. Invece di svuotare solo il cestino, iniziò a generare cloni di se stesso che cancellarono la Posta in Arrivo degli utenti. Quando gli ingegneri riuscirono a fermarlo, il danno era fatto: il 25% dell’intera base utenti aveva la casella completamente vuota.

Bhatia chiese al COO quanto tempo servisse per ripristinare i backup.

Il problema è che non c’erano backup. I costi dei nastri magnetici erano diventati insostenibili con la crescita esplosiva degli utenti, e l’azienda aveva smesso di farli un mese prima.

Le email di milioni di persone erano perse per sempre.

Con la stampa che bussava alla porta e migliaia di utenti furiosi, Hotmail scelse la trasparenza totale. Spiegarono esattamente cosa era successo, si scusarono, e offrirono upgrade gratuiti a vita a tutti gli utenti colpiti.

Da CTO, questa parte mi fa venire i brividi. L’idea di non avere backup è il tipo di scelta che fai quando stai crescendo talmente in fretta che non riesci nemmeno a tenere in piedi l’infrastruttura, figurati pianificare il disaster recovery.

Il servizio sopravvisse, sorprendentemente direi, ma non c’erano alternative valide in giro. Perciò le caselle vuote si riempirono di nuove mail in pochissimi giorni.

In sostanza: a volte il miglior piano B è non avere concorrenti.

Ma riguardiamo i numeri un attimo

Ricapitoliamo il viaggio finanziario:

Investimento iniziale DFJ: 300.000 dollari, valutazione 2 milioni.

Otto mesi dopo: valutazione salita a 20 milioni.

Yahoo offre 40 milioni. No grazie.

Microsoft offre 160 milioni. No grazie.

Microsoft sale a 350 milioni. Ancora no.

Bhatia chiese 400 milioni a Microsoft e Bill Gates lo fece volare a Redmond. La trattativa non fu delle più rilassate, con i manager di Microsoft che urlavano e abbandonavano la stanza mentre i VC di Bhatia dicevano di accettare qualsiasi cifra sopra i 200 milioni.

Bhatia tenne duro. Sapeva che i suoi 12 milioni di utenti e l’effetto rete erano l’asset vero. Il codice lo poteva riscrivere chiunque, quella base utenti no.

Il 31 dicembre 1997, Microsoft annunciò l’acquisizione per circa 400 milioni di dollari. Gates lo definì “il miglior acquisto che abbia mai fatto.”

Da 300.000 dollari a 400 milioni in diciotto mesi. Un ritorno di oltre 1.300 volte per DFJ.

L’imbarazzo di Microsoft: FreeBSD sotto il cofano

E qui la storia diventa comica.

L’architettura originale di Hotmail girava su FreeBSD con Apache per il front-end e Sun Solaris per il back-end. Sistemi UNIX, open source, leggeri ed efficienti. I server front-end erano descritti da un admin come “schede madri da 200 dollari appoggiate su un pezzo di cartone.”

Microsoft comprò il più grande servizio web del mondo e scoprì che girava sul sistema operativo del nemico.

La cultura interna di Microsoft imponeva il “dogfooding”: ogni prodotto doveva usare le tecnologie Microsoft. Quindi l’ordine fu chiaro: migrare tutto su Windows.

Il primo tentativo, su Windows NT, fu un disastro. Gli ingegneri scoprirono che servivano circa 20 macchine Windows per sostituire ogni singolo server FreeBSD, ciascuna costando dieci volte tanto e gli admin UNIX minacciarono di licenziarsi sul posto.

La migrazione a Windows 2000 andò poco meglio. L’immagine di sistema pesava 900MB contro i pochi megabyte di FreeBSD, rendendo il deployment lentissimo. Le operazioni che su UNIX erano automatizzate con script erano “essenzialmente impossibili da scriptare” su Windows. Il bilanciamento del carico con strumenti Microsoft sarebbe costato 15 milioni di dollari, contro 6 milioni con la soluzione esistente.

Ed eccolo il colpo di scena finale: per far funzionare i processi automatizzati su Windows, gli ingegneri Microsoft dovettero installare un pacchetto chiamato “Services for UNIX” e per poter usare cron, lo scheduler di UNIX. Lo strumento del nemico, installato sul proprio sistema operativo, per far funzionare il proprio prodotto di punta.

Ogni volta che vedo un’azienda forzare una scelta tecnologica per ragioni politiche invece che tecniche, mi torna in mente questa storia. Il dogfooding ha senso quando il tuo prodotto è pronto. Quando non lo è, stai solo sabotando il tuo team.

Nel 2001 Microsoft dichiarò al Wall Street Journal che FreeBSD era stato completamente eliminato. Pochi giorni dopo, uno sviluppatore FreeBSD verificò e dimostrò il contrario. Microsoft dovette ritrattare.

I server front-end di Hotmail girarono su FreeBSD per almeno tre anni dopo l’acquisizione. La migrazione completa richiese quasi un decennio.

Da must-have a barzelletta

Per un’intera generazione, creare un account Hotmail era il primo atto di cittadinanza digitale. In India, in America Latina, nel mondo arabo, Hotmail era sinonimo di email.

Poi le cose cambiarono.

La registrazione senza frizioni, che aveva fatto il successo del prodotto, divenne la sua maledizione. Spammer, bot e criminali crearono milioni di account fake. I filtri antispam erano inadeguati. Un indirizzo @hotmail.com su un curriculum passò da segnale di modernità a segnale di allarme. Studi dimostrarono che il 70% dei recruiter percepiva i candidati con email Hotmail come meno professionali.

Il colpo di grazia arrivò il 1 aprile 2004.

Google lanciò Gmail con 1 Gigabyte di spazio gratuito, Hotmail ne offriva 2 Megabyte. Cinquecento volte meno. L’industria intera pensò fosse uno scherzo d’aprile.

Non lo era.

Microsoft reagì tardi: portò lo spazio a 250MB, poi tentò vari rebranding (Windows Live Hotmail, poi Outlook.com). Ma il danno era fatto. Nel 2012 annunciò la chiusura del brand, migrando 400 milioni di account su Outlook.com.

Fine di un’era.

Il DNA di Hotmail è ovunque

La firma virale di Hotmail non ha costruito solo un’azienda, ha creato un’intera categoria di strategia di crescita.

“Sent from my iPhone” di Apple è il discendente diretto. Una firma predefinita su 2.2 miliardi di iPhone venduti, miliardi di impressioni gratuite senza spendere un euro.

Non offre nessuna utilità tecnica, ma ogni email diventa una piccola pubblicità.

I watermark di TikTok sono la stessa logica applicata ai video. Ogni clip scaricata porta il logo TikTok su Instagram, YouTube e WhatsApp. Il contenuto stesso diventa il veicolo pubblicitario, sulle piattaforme dei competitor.

Superhuman, il client email premium da 30 dollari al mese, aggiunge “Sent via Superhuman” con un link di referral personale. Il 30% del traffico al loro sito arriva da quelle firme. Hanno raggiunto 100 milioni di dollari di fatturato annuo in gran parte grazie a questo loop.

Mailchimp col badge in fondo alle email gratuite, Calendly coi link che espongono il tool a ogni destinatario, Dropbox col programma referral che aumentò le iscrizioni del 60%.

Tutti figli di quella riga in fondo alle email di Hotmail.

La lezione che mi porto a casa

Hotmail ha dimostrato una cosa che vale ancora oggi: il canale di marketing più potente è quello che non sembra marketing.

Un messaggio che arrivava da una persona di cui ti fidavi e inserito in una conversazione privata, era più potente di un qualunque banner o spot. Il link all’interno ti portava a registrarti in trenta secondi e tu ti fidavi.

Due ingegneri bloccati da un firewall hanno inventato la webmail, un investitore testardo ha insistito per una riga di testo, e quella riga ha costruito il primo impero virale della storia di internet.

La domanda che mi faccio ogni volta che lavoro su un prodotto è questa: quale touchpoint sottovalutato potrebbe diventare il canale di crescita più forte?

Ogni fattura inviata, ogni notifica, ogni report esportato, ogni link condiviso. Se non ci pensi, stai lasciando sul tavolo il tuo viral loop.

Ci vediamo alla prossima newsletter.

Senza filtri,
Chri

Qualche settimana fa mi ha scritto una startup (lo so che sei curioso/a, ma si dice il peccato, non il peccatore). Il co-founder tecnico aveva costruito e validato tutto, i primi clienti paganti c’erano già. Poi, a un certo punto, il founder se n’è andato.

Quello che ha lasciato era un software che funzionava: gli utenti lo usavano e il business girava. Sotto il cofano, però, c’era un problema grosso. Il software non poteva evolvere. E non per colpa della tecnologia in sé, ma per come era stata scelta.

Mi sono ritrovato a pensare a quante volte mi capita di entrare in progetti dove il problema non è il codice, il team o altro, ma la scelta tecnologica fatta all’inizio senza farsi le domande giuste. Purtroppo è una roba che vedo in continuazione.

Quando lo stack diventa un muro

La prima cosa che faccio quando entro in un progetto è guardare sotto il cofano. E quello che ho trovato qui mi ha dato subito il quadro della situazione.

Utenti, transazioni, relazioni tra persone, dati che si collegano tra loro in continuazione. Il tipo di prodotto dove tutto dipende da tutto.

Il database che avevano sotto? MongoDB. Che è un ottimo strumento, ma per un tipo di lavoro diverso. Qui serviva qualcosa che gestisse le relazioni tra i dati in modo naturale e MongoDB non è pensato per quello.

Non voglio aprire il dibattito su MongoDB ovviamente, ma quando me ne sono accorto ho capito perché il team voleva cambiarlo. Ogni volta che dovevano costruire qualcosa che toccava le connessioni tra utenti, era una lotta. Workaround su workaround, soluzioni fragili, tempi di sviluppo che esplodevano. Il team non era scarso, però lo strumento che avevano sotto gli remava contro.

E qui il punto è che il costo di una scelta così non lo vedi subito. Lo vedi dopo mesi, quando ti accorgi che una feature che avrebbe dovuto prendere due settimane ne prende sei. Quando il team è frustrato e non capisce perché tutto è così faticoso. Quando un competitor che è partito dopo di te ti supera perché riesce a iterare più veloce. Il costo non è solo tecnico: sono mesi persi, opportunità che sfumano, e soldi bruciati in sviluppo che non doveva essere così complicato.

Mi è successo anche a me, anni fa, di trovarmi in una situazione simile su un progetto mio. Avevo scelto una tecnologia perché mi piaceva, perché volevo impararla, e dopo qualche mese mi sono ritrovato a combattere contro lo strumento invece che a costruire il prodotto. È una sensazione che riconosco al volo quando la vedo in altri.

La prima cosa che stiamo facendo insieme è costruire una strategia di migrazione verso PostgreSQL. Non perché sia “migliore” in assoluto, ma perché per quello che il loro prodotto deve fare è lo strumento giusto.

La trappola del “migliore”

Quando un founder deve scegliere la tecnologia per il suo prodotto, la domanda che si fa quasi sempre è: “Qual è la tecnologia migliore?”

Sembra ragionevole, eppure è la domanda sbagliata.

Non esiste la tecnologia migliore in assoluto, esiste quella più adatta al contesto in cui ti trovi. Sembrerà una differenza sottile, ma ti assicuro che non lo è. Questo cambia completamente il modo in cui affronti la scelta finale.

Quando cerchi “la migliore”, finisci per scegliere in base alla moda del momento, al post che hai letto su X, al consiglio dell’amico developer, o alla tecnologia che “tutti stanno usando”. Nessuna di queste è una buona ragione per prendere una decisione che condizionerà il tuo prodotto per anni.

Quando invece parti dal contesto, ti fermi a capire cosa ti serve davvero. Che tipo di prodotto stai costruendo? Come si comportano i tuoi dati? Come crescerà il prodotto nei prossimi dodici mesi? Quante persone ci lavoreranno sopra?

È come un artigiano che sceglie l’attrezzo in base a quello che deve costruire. Non prende il martello più costoso perché è il “migliore”: prende quello che gli serve per il lavoro che ha davanti.

Anche io all’inizio della carriera ho fatto questo errore (ma tipo 100 volte almeno). Sceglievo le tecnologie che mi piacevano, quelle che volevo imparare, quelle che erano “cool” in quel momento. Poi ti ritrovi con un progetto costruito su uno stack che conosci solo tu e che il prossimo developer dovrà smontare per capirci qualcosa. E lì capisci che la scelta non è mai solo tua: è una scelta che condiziona tutti quelli che verranno dopo.

Nel caso della startup che ti ho raccontato il founder aveva fatto una scelta senza chiedersi dove il prodotto sarebbe dovuto andare. E quindi, quando il prodotto è cresciuto nella direzione naturale, lo stack non ha retto.

Cosa guardo davvero quando devo scegliere

Quando entro in un progetto e devo valutare o scegliere uno stack, seguo una logica che nel tempo si è consolidata. Non è una formula magica e si adatta caso per caso, ma ci sono delle variabili che peso sempre.

Il contesto di prodotto e di business

Questa è sempre la prima cosa. Che tipo di prodotto stai costruendo? Per chi? Come interagiscono i dati al suo interno?

Se stai costruendo un marketplace dove gli utenti hanno relazioni tra loro, hai bisogno di una tecnologia che gestisca quelle relazioni in modo naturale. Se stai costruendo un sistema che riceve milioni di eventi al secondo e deve solo registrarli, le tue esigenze sono completamente diverse.

La tecnologia segue il problema. Mai il contrario.

Sembra ovvio, eppure lo vedo succedere in continuazione: startup che scelgono il database perché “è quello che va adesso” senza mai chiedersi se è quello giusto per i dati che devono gestire. È come comprare un furgone quando ti serviva una bicicletta. O viceversa.

Chi trovi sul mercato

Questo è un fattore che un botto di persone sottovalutano. Puoi scegliere la tecnologia più elegante del mondo, ma se poi non riesci a trovare persone che la conoscono, hai un problema serio.

Non mi sto riferendo solo alle assunzioni a tempo pieno. Parlo anche di freelancer, consulenti, community online dove chiedere aiuto quando sei bloccato alle tre di notte, magari prima di un lancio. Parlo di documentazione fatta bene, di tutorial aggiornati, di risorse per formare il team quando arriva qualcuno nuovo.

Scegliere una tecnologia di nicchia quando sei una startup con budget limitato e devi muoverti veloce è un rischio che nella maggior parte dei casi non vale la pena correre. Lo so, fa meno figo dire “usiamo Go con questo framework che conoscono in dodici nel mondo”. Ma quando il tuo unico developer se ne va e devi trovare qualcuno che ci metta le mani, capisci perché “noioso e diffuso” batte “figo e di nicchia” nove volte su dieci.

La longevità

Questa tecnologia sarà ancora supportata tra tre anni? Chi c’è dietro? È un progetto open source con una community attiva e un’azienda che lo sostiene, o è il side project di qualcuno che potrebbe abbandonarlo da un giorno all’altro?

Non devi per forza scegliere qualcosa che durerà vent’anni. Ma devi almeno evitare di ritrovarti tra due anni con uno stack che nessuno mantiene più e una migrazione forzata nel momento peggiore. Tipo quando stai per chiudere un round. O quando hai appena assunto tre persone. O quando il cliente più grande ti chiede una feature urgente.

La migrazione forzata è una delle robe più dolorose che esistano nel mondo tech. Se puoi evitarla con una scelta più ragionata all’inizio, fallo.

Il fattore economico e il tempo

Quanto budget hai realmente? Quanto tempo ti separa dal prossimo round, dal prossimo lancio, dal prossimo obiettivo di business?

Ti faccio un esempio concreto: se devi mettere in piedi l’infrastruttura del tuo prodotto e non hai né il budget né il tempo per trovare un DevOps che ti gestisca tutto su AWS, andare su una Platform as a Service come Railway o Render non è una scelta pigra. È una scelta intelligente.

Stai delegando una complessità che in questo momento non puoi permetterti di gestire internamente, e questo ti libera tempo e risorse per concentrarti su quello che conta davvero: il prodotto. Quando crescerai e avrai le risorse per farlo, potrai sempre valutare se portare l’infrastruttura in-house.

Il fattore che nessuno sta considerando

C’è una variabile relativamente nuova che secondo me pochissime persone stanno mettendo sul piatto. Ed è una di quelle che nei prossimi anni farà sempre più differenza.

Quanto materiale ha l’AI su quella tecnologia?

L’AI ormai è diventata un collaboratore reale nello sviluppo di un software; non si tratta più di un giocattolo, ma di uno strumento che uso ogni giorno. Bisogna ricordarsi, però, che l’AI funziona bene su tecnologie sulle quali è stata allenata con tanto materiale: documentazione, codice open source, tutorial, discussioni su StackOverflow ed esempi reali di implementazione.

Se scegli una tecnologia di nicchia, con poca documentazione e poca community, l’AI avrà poco materiale su cui basarsi per aiutarti. E questo si traduce in qualcosa di molto concreto: il tuo team sarà più lento nel risolvere problemi, farà più errori che avrebbe potuto evitare, e dovrà investire più tempo su cose che con una tecnologia più diffusa l’AI avrebbe gestito in pochi secondi.

Ci penso spesso, perché è un circolo che si autoalimenta. Più una tecnologia è diffusa, più materiale c’è, più l’AI è brava ad aiutarti, più il tuo team è produttivo, più la tecnologia diventa attraente. E viceversa: meno una tecnologia è diffusa, meno l’AI ti aiuta, più sei lento, meno conviene sceglierla.

Attenzione, non ti dico che non devi scegliere una tecnologia solo perché l’AI la conosce bene, il punto è che oggi ha senso mettere questo fattore nella valutazione finale. È uno di quei ragionamenti che tra qualche anno ti sembreranno anche ovvi, ma che adesso pochi stanno facendo.

La scelta sbagliata non è la fine del mondo

Questa è la parte che volevo aggiungere, perché rischia di passare il messaggio sbagliato.

Non tutte le scelte tecnologiche sbagliate sono fatali. Ho visto startup sopravvivere e crescere con stack discutibili. Ho visto prodotti di successo costruiti su fondamenta traballanti che sono state sistemate nel tempo, pezzo dopo pezzo, senza mai fermare il business.

La startup di cui ti ho parlato all’inizio ne è la dimostrazione: hanno validato il prodotto, hanno trovato clienti paganti, il business funziona. Lo stack non era quello giusto, ma non li ha uccisi. Li ha rallentati.

Quando arrivo in un progetto dove le scelte sono già state fatte, il mio lavoro non è giudicare chi le ha fatte. Sarebbe inutile e pure un po’ da stronzi. Il mio lavoro è capire se quelle scelte reggono per dove il business vuole andare. Se reggono le rafforzo e se non reggono costruisco una strategia per migrare senza fermare tutto.

E questa è la parte che mi piace di più del mio lavoro, tra l’altro. Non è scegliere la tecnologia perfetta il primo giorno. È navigare la complessità di scelte già fatte, vincoli reali, budget limitati e obiettivi ambiziosi. È trovare il percorso migliore con le carte che hai in mano.

Perché alla fine la tecnologia è uno strumento. E come ogni strumento, il suo valore non dipende da quanto è sofisticato o alla moda. Dipende da quanto ti permette di fare quello che devi fare, con le risorse che hai, nel tempo che hai.

Il tuo stack tecnologico è stato scelto partendo dal business o da una preferenza tecnica?

Rispondi a questa mail, sono curioso di sapere com’è andata nel tuo caso.

Ci vediamo alla prossima newsletter.

Senza filtri,
Chri

👋 Ciao, sono Chri. Fractional CTO e questa è Senza Filtri: la newsletter dove condivido il dietro le quinte del mio viaggio da imprenditore (esperienze, cosa ho imparato e tanti errori) alternato a qualche deep dive sui business che mi incuriosiscono.

Ho una confessione da fare.

Avevo una streak seria su Duolingo. Non vi dico di quanto perché mi vergogno, ma ogni mattina, prima ancora del caffè, aprivo l’app e provavo a fare la lezione di spagnolo. Non sono diventato bravo, anzi se mi mettessi a parlare spagnolo probabilmente farei ridere i polli. Però quell’app ha qualcosa di malefico: ti crea una dipendenza che nemmeno i social riescono a dare.

Quel maledetto gufo ti manda notifiche passive-aggressive se salti un giorno, le streak ti fanno sentire in colpa, le leghe ti fanno competere con gli sconosciuti. Sembra Candy Crush mascherato da una scuola di lingue.

E posso dirti la verità? Funziona. Non impari davvero lo spagnolo (e su questo ci arriviamo), ma 100 milioni di persone al mese aprono quell’app.

Non è una newsletter sulla gamification, la storia che voglio raccontarti è un’altra.

Duolingo nel 2024 ha licenziato parte dei contractor e li ha sostituiti con l’AI, ma la cosa più sorprendente non è questa, è che il titolo in borsa non è sceso.

Anzi.

Ed è qui che la cosa diventa interessante per chi, come me, costruisce prodotti.

L’uomo che ha fatto lavorare gratis il mondo intero (due volte)

Prima di parlare di AI, devo raccontarti chi c’è dietro, perché la storia di Luis von Ahn è una di quelle che ti fanno pensare.

Luis è guatemalteco (non sapevo si dicesse così). Cresciuto in un paese dove l’educazione di qualità è un privilegio, non un diritto. Questo dettaglio diventerà importante tra poco.

Nel 2007, da professore alla Carnegie Mellon, inventa reCAPTCHA. Sai quando devi cliccare su “non sono un robot” e ti fa selezionare le immagini con i semafori? (che sbaglio sempre tra l’altro) Ecco, quello.

C’era un trucco geniale che mentre tu dimostravi di non essere un bot, stavi anche digitalizzando libri per Google. Gratis. Senza saperlo.

200 milioni di persone al giorno lavoravano gratuitamente per digitalizzare l’archivio del New York Times e milioni di libri. Google compra reCAPTCHA nel 2009.

Luis aveva trovato un pattern: prendi un’attività che le persone fanno comunque e crea valore enorme sopra.

E poi lo rifece.

L’idea di Duolingo nasce dalla stessa logica. In origine, gli utenti avrebbero imparato le lingue e contemporaneamente tradotto il web. Learning come sottoprodotto del lavoro utile.

Quel modello specifico non ha funzionato a lungo. Ma l’intuizione di base, rendere l’educazione linguistica gratuita e accessibile, quella sì.

Nel 2011 nasce Duolingo. Nel 2021 fa l’IPO. Oggi vale circa 12 miliardi di dollari.

Tutto partendo da un senso di colpa: Luis si sentiva in colpa perché reCAPTCHA sfruttava il lavoro gratuito delle persone. Voleva creare qualcosa che desse indietro.

“Il mio paese non può permettersi Rosetta Stone a 500 dollari. Dovevo trovare un altro modo.”

Va che numeri

Ok, la parte che vi piace:

• 100+ milioni di utenti attivi al mese

• 37+ milioni di utenti attivi al giorno

• Circa 1 miliardo di dollari di fatturato annuo [dato 2025]

• Valutazione: circa 12 miliardi di dollari

• Team: circa 800 dipendenti

• Lingue disponibili: 40+

• Il 95% degli utenti usa il piano gratuito

Per dare un contesto: Rosetta Stone al suo picco valeva circa 1 miliardo. Duolingo vale 12 volte tanto, con un prodotto che è gratis per quasi tutti.

Ma il numero che mi ha fatto pensare è un altro: Duolingo ha un fatturato per dipendente di circa 900.000 dollari. E per un’azienda di educazione è roba seria.

Il momento che ha cambiato tutto

E arriviamo al punto.

A gennaio 2024, Duolingo taglia circa il 10% dei contractor. Non i dipendenti full-time, i contractor. Quelli che creavano contenuti, traducevano lezioni, scrivevano esercizi.

Il motivo? L’AI fa lo stesso lavoro, ma più veloce e a costo (quasi) zero.

Non l’hanno detto con queste parole esatte, ovviamente. Il comunicato parlava di “evoluzione dei processi” e “nuove priorità”. Ma la sostanza era chiara.

Qualche mese prima avevano lanciato Duolingo Max, il piano premium che usa GPT-4 per due funzionalità:

Explain My Answer: quando sbagli una risposta, l’AI ti spiega perché in modo conversazionale. Non il solito messaggio pre-scritto, ma una spiegazione personalizzata che capisce il tuo errore specifico.

Roleplay: conversazioni simulate con personaggi AI. Tipo ordinare al ristorante in francese o chiedere indicazioni in giapponese. Interazioni che prima richiedevano un insegnante umano o, nel caso di Duolingo, decine di content writer che scrivessero centinaia di scenari.

Poi è arrivata la Video Call, dove parli direttamente con un personaggio AI in tempo reale. Pratica di conversazione senza l’ansia sociale di parlare con un umano.

Il CEO Luis von Ahn l’ha detto chiaramente: l’AI sta gradualmente sostituendo il lavoro dei contractor nella creazione di contenuti. Per carità, non tutto, non domani, ma ormai la direzione è quella.

[Piccola interruzione] Costruiamo insieme Senza Filtri

Ho creato un breve sondaggio anonimo per capire come migliorare la newsletter ed esserti più utile. Se ti va di rispondere a qualche domanda clicca qui (meno del tempo di prendere un caffè). Grazie mille.

Cosa ha funzionato (e cosa no)

Cerchiamo di essere onesti intellettualmente (almeno noi dai…)

Cosa ha funzionato:

I costi di produzione dei contenuti sono scesi. Creare una nuova lezione o un nuovo esercizio che prima richiedeva ore di lavoro umano ora richiede minuti di revisione. L’AI genera, l’umano controlla e affina. Il processo è invertito.

La personalizzazione è migliorata. L’algoritmo di Duolingo (che si chiama Birdbrain.. geniale…) usa il machine learning per adattare la difficoltà a ogni utente. Con l’AI generativa, anche le spiegazioni e le conversazioni diventano personalizzate.

La velocità di espansione è aumentata. Aggiungere una nuova lingua o un nuovo tipo di esercizio è diventato significativamente più veloce.

Cosa è più complicato:

La qualità non è uniforme. Chi usa Duolingo Max nota che a volte le spiegazioni dell’AI sono generiche o poco precise per lingue meno comuni. Il giapponese non è l’inglese, e GPT-4 lo sa bene.

Il dibattito “ma funziona davvero?” resta aperto. Duolingo è sempre stato criticato per il fatto che la gamification funziona meglio nel tenerti incollato all’app che nell’insegnarti davvero una lingua. L’AI migliora il prodotto, ma non risolve questo problema di fondo. Infine, ma non da meno, c’è la questione etica. Diverse persone hanno perso il lavoro, contractor che creavano contenuti da anni sono stati sostituiti.

Non è una nota a piè di pagina, è una conseguenza reale.

La mia opinione (da CTO)

Ora parlo da chi vive questo tema ogni giorno con le startup che seguo.

L’AI adoption non è un’opzione e non è una moda: è una realtà che sta cambiando il modo in cui si costruiscono i prodotti e chi la ignora oggi, sarà in svantaggio domani.

Ma, e questo “ma” è importante, l’approccio deve essere cauto.

Ho visto startup buttarsi sull’AI come se fosse la soluzione a tutto. “Mettiamoci l’AI!” senza sapere cosa, dove e perché. Tipo le aziende che nel 2018 volevano “mettere la blockchain” ovunque.

Duolingo ha fatto una cosa diversa. Non ha semplicemente sostituito tutto con l’AI, ha guardato il processo, identificato dove l’AI poteva fare un lavoro uguale o migliore a costo inferiore e hanno iniziato da lì.

Content creation ripetitiva? L’AI la fa bene. Spiegazioni personalizzate? L’AI la fa meglio di un messaggio pre-scritto. Conversazioni simulate? L’AI è perfetta.

Strategia di prodotto? No. Design dell’esperienza utente? No. Decisioni su cosa costruire? Assolutamente no.

La lezione non è “sostituisci le persone con l’AI”. La lezione è “capisci dove l’AI ti dà un vantaggio reale e usala lì.”

Io con i miei clienti faccio esattamente questo. Partiamo dalle attività, non dalla tecnologia. Quali task sono ripetitivi? Quali richiedono poca creatività ma molto tempo? Quali processi hanno un output prevedibile?

Quelli sono i candidati. Il resto, strategia, relazioni, decisioni, resta umano.

Cosa possono fare le startup (in pratica)

Nella pratica se sei un founder o un CTO di una startup, come applichi quello che ha fatto Duolingo?

Primo: mappa i processi, non le feature. Non chiederti “dove posso mettere l’AI nel mio prodotto?” Chiediti “quali attività del mio team sono ripetitive, prevedibili e ad alto volume?” Duolingo non ha messo l’AI a caso. Ha sostituito content creation ripetitiva, migliaia di esercizi che seguono pattern simili.

Secondo: parti dal testing, non dal replacement. Non licenziare nessuno domani. Fai un test. Prendi un’attività specifica, falla fare all’AI per un mese, confronta qualità e costi. Se funziona, scala. Se no, hai imparato qualcosa senza danni (non fare come Klarna)

Terzo: l’umano diventa il quality controller. Il modello che funziona non è “AI al posto delle persone” ma “AI che produce, persona che controlla”. L’AI genera il primo 80%, l’umano affina il restante 20%. Il risultato è spesso migliore e sempre più veloce.

Quarto: non tutto è automatizzabile. E va bene così. Le attività che richiedono giudizio, empatia, creatività vera, comprensione del contesto. Quelle restano umane. Duolingo non ha sostituito i suoi product manager o i designer con l’AI. Ha sostituito chi scriveva la variante numero 347 dello stesso tipo di esercizio.

Ti racconto una cosa che ho visto con un mio cliente: avevano un team di tre persone che passava l’80% del tempo a scrivere documentazione tecnica. Roba super ripetitiva. Quindi abbiamo testato l’AI su quel processo e il risultato è stato che le tre persone ora dedicano il 60% del loro tempo a cose più importanti come parlare con gli utenti, migliorare il prodotto e pensare. La documentazione la rivede una persona sola. Non abbiamo licenziato nessuno, abbiamo liberato tempo.

Il parallelo con Linear (e con tutti gli altri)

Se ci pensi, Duolingo sta facendo con l’AI quello che Linear ha fatto con il prodotto: fare di più con meno.

Linear ha 52 milioni di fatturato con 57 persone. Duolingo sta andando nella stessa direzione: aumentare l’output riducendo le risorse necessarie.

Linear ha scelto di essere piccola, è un principio di Design, Duolingo invece non vuole essere piccola. Cerca di capire come riallocare le persone e i soldi risparmiati con l’AI vanno in nuove feature, nuovi mercati e nuovi prodotti.

Entrambi gli approcci sono validi. Ma la domanda per te è: se l’AI ti libera risorse, dove le metti?

Puoi fare come Duolingo: reinvestirle in crescita.

Puoi fare come me con i miei clienti: reinvestirle in qualità.

Ma una cosa è certa: fingere che l’AI non esista non è un’opzione. Non per le startup, non per le aziende e soprattutto, non per i professionisti.

La domanda scomoda

Se un’azienda da 12 miliardi di dollari può sostituire parte del lavoro umano con l’AI e ottenere risultati uguali o migliori, cosa significa per il resto del mercato?

Non ho una risposta definitiva. Ma ho un’opinione.

L’AI non sostituirà chi fa lavoro di qualità, ma chi fa lavori ripetitivi che sembrano di qualità e credimi, c’è una differenza enorme.

Il content writer che scrive la variante numero 347 di un esercizio di grammatica? Sostituibile. Il content strategist che decide quali esercizi creare e perché? No.

Il developer che scrive boilerplate code? Sempre più sostituibile. Il developer che progetta l’architettura e prende decisioni di trade-off? No.

Il traduttore che traduce frasi standard? Sostituibile. Il traduttore letterario che cattura sfumature culturali? No.

Il pattern è chiaro: l’AI sostituisce l’esecuzione ripetitiva, non il giudizio (almeno per ora eh…)

E la domanda che dovresti farti è questa: nel tuo lavoro, quanto tempo passi a eseguire e quanto a decidere?

Perché se la risposta è “80% esecuzione”, hai un problema. O meglio, hai un’opportunità: usare l’AI per ribaltare quel rapporto.

Duolingo l’ha fatto. Il gufo verde è ancora lì, ti manda ancora notifiche passive-aggressive, ti fa ancora sentire in colpa se salti un giorno.

Ma dietro le quinte, il modo in cui crea quei contenuti è cambiato per sempre.

La domanda per te è semplice: cosa stai aspettando per fare lo stesso?

E no, non parlo di licenziare nessuno. Parlo di essere onesto su dove il tuo tempo (e quello del tuo team) sta andando davvero. E se l’AI può liberarne una parte, usarla.

Perché il futuro non è “umani contro AI”. Il futuro è “umani con AI contro umani senza AI”.

E io so da che parte voglio stare.

Ci vediamo alla prossima newsletter.

Senza filtri,
Chri

P.S. Costruiamo insieme Senza Filtri

Ho creato un breve sondaggio anonimo per capire come migliorare la newsletter ed esserti più utile. Se ti va di rispondere a qualche domanda clicca qui (meno del tempo di prendere un caffè). Grazie mille.

L’altro giorno ero in call con un potenziale cliente. Startup interessante, un team piccolo e prodotto in forte crescita. A un certo punto, mi fa LA domanda: “Ok Christian, ma qual è la tua tariffa oraria?”

“Non lavoro a ore.”

Rimane in silenzio, lo vedo spiazzato. Palesemente non se l’aspettava.

A quel punto gli spiego come lavoro, cosa offro e come possiamo strutturare la collaborazione. Alla fine della call mi dice: “Ah okay, ha molto più senso così”.

Oggi mi viene naturale rispondere così, ma c’è voluto del tempo per arrivare a questo punto e il percorso non è stato solo un “chiedere di più”, ma cambiare il modo in cui lavoro, in cui mi posiziono e i clienti che scelgo.

Se sei un freelance e stai ancora vendendo ore, non ti giudico. Ci sono passato anch’io, in un certo senso.

Però qui voglio raccontarti cosa è cambiato per me, magari può aiutarti a fare lo stesso percorso con qualche sbattimento in meno.

Il problema non è quanto chiedi. È cosa stai vendendo.

La tariffa oraria è il punto di partenza naturale per qualsiasi freelance. Ed è giusto che sia così.

È semplice: guardi il mercato, guardi la tua esperienza, metti un numero. Il cliente capisce subito quanto costi. Stimi le ore, le moltiplichi per la tariffa, e hai il preventivo. Pulito, lineare, easy.

Il problema è che quando vendi ore, attiri persone che comprano ore.

E chi compra ore cerca manodopera. Cerca qualcuno che esegua, che stia lì X ore a fare Y cose. Non ragiona per obiettivi, non ragiona per risultati, ma per tempo dedicato.

“Quante ore ci metti?”

“Possiamo fare un paio d’ore in meno?”

“Ma se ci metti meno ore, mi fai un prezzo più basso?”

Questa dinamica è pericolosa, perché sposta l’attenzione dal valore che porti al tempo che impieghi. E il tempo è una commodity: c’è sempre qualcuno che costa meno di te e che può dedicare lo stesso numero di ore.

Facciamo un esempio estremo per rendere l’idea: immagina che in un’ora di consulenza io riesca a sbloccare un problema che stava frenando il lancio del prodotto di un cliente. Quel blocco gli stava costando settimane di ritardo e decine di migliaia di euro in opportunità perse.

Quell’ora vale il mio prezzo orario? O vale molto di più?

Il valore non sta nel tempo, sta nel risultato.

Non si tratta di guadagnare di più o di meno, è un approccio lavorativo completamente diverso: chi lavora per obiettivi pianifica tutto in modo diverso, comunica in modo diverso e, infine, lavora in modo diverso.

Per me è stato un cambio di mentalità rispetto al tipo di cliente che volevo cercare sul mercato.

Non ho alzato il prezzo. Ho cambiato tutto il resto.

Qui sta il punto che molti sbagliano: pensano che passare dal vendere ore al vendere valore sia semplicemente chiedere di più.

Invece è cambiare cosa vendi, come lo presenti e a chi lo vendi.

Ti racconto cosa ho fatto io quest’anno che ho deciso di riposizionarmi.

Ho cambiato il sito. Ho smesso di usare la parola “MVP” come bandiera. Per anni il mio posizionamento era legato alla fase iniziale delle startup: ti aiuto a costruire l’MVP, a validare l’idea e a lanciare. Poi mi sono reso conto che quel tipo di servizio, soprattutto oggi con l’intelligenza artificiale, sta diventando sempre meno legato alla mia esperienza, anche qualcun altro può farlo bene. Io posso dare molto più valore nella fase successiva: quando hai raccolto, quando devi scalare, quando il prodotto deve diventare un business.

Ho cambiato i contenuti. Su LinkedIn, nella newsletter, nei confronti con i clienti: parlo molto meno della parte iniziale e molto più di quella post-raccolta. Non perché la fase iniziale non sia importante, ma perché non è più dove il mio valore è al massimo.

Ho iniziato a dire no. Ci sono clienti che ancora oggi mi contattano per la primissima fase. Con tutta onestà, o li giro a qualcuno della mia rete che è più adatto, o gli dico di ricontattarmi nel momento giusto. Non è facile dire no ai soldi, soprattutto all’inizio. Ma se accetti tutto, non ti stai posizionando, stai solo riempendo il tuo calendario.

Il posizionamento non è una dichiarazione su LinkedIn. È una serie di scelte concrete su cosa fai, cosa non fai e per chi lavori.

Come presento il mio valore oggi

Oggi ogni proposta che mando ha una struttura chiara.

Il cliente vede: X euro al mese, per Y mesi. Un retainer mensile fisso.

Dentro ci sono tre cose:

1. I servizi: cosa faccio concretamente, quali attività sono incluse e con che modalità di ingaggio.

2. Gli obiettivi: quali problemi andiamo a risolvere insieme, quali risultati vogliamo raggiungere nel periodo di collaborazione.

3. I deliverable: cosa consegno, cosa il cliente può aspettarsi di avere alla fine.

In questo modo il cliente compra un percorso verso un risultato, non il mio tempo.

La conversazione cambia: non parliamo più di “quante ore”, ma di “cosa risolviamo”, e non si negozia il tempo, ma lo scope.

E c’è un altro vantaggio enorme che non avevo previsto: il retainer mensile permette al cliente di avere chiarezza totale. Sa esattamente quanto spende, per quanto tempo e cosa ottiene. Niente sorprese, niente fatture che lievitano, niente discussioni a fine mese su quante ore ho fatto.

La semplicità per il cliente è un valore in sé.

Il cliente giusto vale più del cliente che paga di più

Questa è una cosa che ho capito solo con l’esperienza e che avrei voluto capire molto prima.

Io seleziono i miei clienti tanto quanto loro selezionano me.

Non scelgo in base a quanto pagano, ma in base al valore di ritorno che mi danno. E quel valore non sono solo i soldi.

È il portfolio. Lavorare con un’azienda interessante ti permette di mostrare risultati concreti ai futuri clienti. Un case study forte vale più di mille parole sul tuo sito.

È il network. Se il cliente ha una rete importante e le cose vanno bene, parlerà di te. E non c’è marketing migliore di un cliente soddisfatto che ti referenzia spontaneamente. Il 60/70% del mio business oggi arriva da referral. Non dalla pubblicità o dal content marketing. Il passaparola delle persone che hanno lavorato bene con me e sono state bene è uno strumento potentissimo.

È la crescita professionale. Ci sono progetti che ti insegnano cose nuove, ti espongono a sfide che non avevi affrontato, ti fanno crescere come professionista. Questo ha un valore economico enorme, anche se non compare in fattura.

E poi ci sono clienti che magari ti pagano anche bene, ma ti mangiano tempo, energia e spazio mentale sproporzionato rispetto al ritorno. Clienti “one shot” che vanno bene, per carità, ma che non ti lasciano nient’altro.

Devi imparare a ragionare come se stessi per prepararti a fare una maratona, non uno sprint. Il ritorno è sul lungo periodo, più che su quello breve.

Guadagnare subito è facile. Costruire un business solido nel tempo richiede investire nelle relazioni, non solo nei ricavi.

Il primo passo concreto (per chi vuole iniziare)

Se oggi vendi a ore e vuoi iniziare a spostarti verso il valore, ecco quello che ti consiglio di fare. Non è teoria, è quello che avrei detto al me stesso di qualche anno fa.

Definisci i tuoi servizi. Prima ancora di parlare con il prossimo cliente, siediti e scrivi nero su bianco: quali problemi risolvo? Che risultati porto? Non pensare in termini di “faccio X ore di sviluppo” o “faccio Y ore di consulenza”. Pensa a cosa cambia per il cliente dopo che hai lavorato con lui.

Dagli un valore economico. Non basato sulle ore, basato sull’impatto. Se il tuo intervento permette al cliente di risparmiare tre mesi di sviluppo, quanto vale quel tempo per lui? Se lo aiuti a evitare un errore che gli costerebbe decine di migliaia di euro, quanto vale quella consulenza?

Presentali così al prossimo cliente. Non devi cambiare tutto dall’oggi al domani. Quando arriva il prossimo potenziale cliente, prova a dire: “Guarda, sto spostando il mio modello di business a un modello a progetto. Per me è importante definire bene gli obiettivi che andiamo a risolvere, i problemi che ti vado a risolvere e il ritorno che hai.”

In quel momento stai parlando di valore, non di tempo.

E qui arriva l’errore più grande che vedo fare a tanti freelance che provano a fare questo switch: alzano il prezzo senza aver cambiato nient’altro.

Chiedono di più per lo stesso servizio, presentato nello stesso modo, allo stesso tipo di clienti. Non funziona così, ciccio.

Prima di tutto identifica i problemi che vai a risolvere, sii specifico, perché il risultato va saputo comunicare, non basta parlare dell’attività.

Se non sai spiegare perché il tuo lavoro vale quello che chiedi, non è un problema di prezzo. È un problema di posizionamento.

Non è coraggio. È chiarezza.

Se c’è una cosa che questo percorso mi ha insegnato è che alzare il proprio valore non è una questione di coraggio nel chiedere di più.

È una questione di chiarezza.

Chiarezza su cosa offri. Chiarezza su per chi lavori. Chiarezza su quali problemi risolvi e che risultati porti.

Quando hai questa chiarezza, il prezzo diventa una conseguenza naturale. Non devi più giustificarlo. Non devi più sentirti a disagio quando lo dici. Non devi più negoziare al ribasso.

Perché non stai vendendo il tuo tempo, stai vendendo la tua competenza, la tua esperienza e il cambiamento che generi nel business del cliente.

E quello ha un valore che non si misura in ore.

Tu stai vendendo il tuo tempo o il tuo valore?

Rispondi a questa mail, sono curioso di sapere a che punto sei del percorso.

Ci vediamo alla prossima newsletter.

Senza filtri,
Chri

Qualche settimana fa un mio cliente mi scrive un messaggio che potrei riassumere cosi:

“Abbiamo speso 40.000 dollari per un top developer americano. Quattro mesi di lavoro su un MVP. Centinaia di interviste fatte. Il prodotto dovrebbe essere perfetto. Eppure stiamo girando a vuoto.”

Il problema non era il developer, lui era bravo, forse anche troppo. La piattaforma invece era diventata troppo complessa per una fase early stage; troppe automazioni, troppi percorsi di sviluppo, troppa distanza tra chi parla con gli utenti e chi scrive il codice.

Una cosa che vedo succedere spesso è questa: i developer forti in fase super early tendono a portarti fuori strada perché costruiscono l’architettura perfetta per un prodotto che tu non hai ancora validato. Così gli ho suggerito una cosa che fino a poco tempo fa non avrei mai detto a un cliente.

“Ricostruisci tutto con Lovable, da zero. Fallo tu, ma senza developer”.

Michele, product manager, ha ricostruito in quattro giorni quello che era stato sviluppato in quattro mesi.

Quattro giorni. Da solo. Senza scrivere una riga di codice.

Non sarà l’infrastruttura che li porterà a un milione di utenti, ma per la fase in cui sono è perfetto: velocità, controllo, e soprattutto chi parla con gli utenti è la stessa persona che modifica il prodotto. Zero intermediari.

Mentre guardavo il loro nuovo setup funzionare, mi sono fermato a pensare.

Io sono un Fractional CTO: il mio mestiere ruota attorno alla tecnologia, al codice, alle decisioni tecniche. E ho appena consigliato a un cliente di eliminare il developer e fare da solo.

Se tutti possono programmare, quanto vale saperlo fare?

Benvenuti nell’era del vibe coding

Forse hai già sentito questo termine, forse no. Te lo spiego in trenta secondi.

“Vibe coding” è un’espressione coniata da Andrej Karpathy, cofondatore di OpenAI, a febbraio 2025. Significa costruire software “seguendo il vibe”, a sensazione: descrivi quello che vuoi in linguaggio naturale, un’AI lo costruisce per te. Niente sintassi, niente debug manuale, niente anni di studio per capire la differenza tra un framework e l’altro.

Collins Dictionary l’ha eletta parola dell’anno 2025 e non è un caso.

I numeri danno la dimensione del fenomeno. Lovable, uno degli strumenti più popolari in questo spazio, è passato da zero a 200 milioni di dollari di ricavi annuali in 12 mesi con soli 100 dipendenti.

Bolt.new, Cursor, v0, Replit: il mercato degli strumenti per costruire software senza saper programmare è esploso. Le stime parlano di un settore da quasi 3 miliardi di dollari oggi, 325 miliardi entro il 2040.

Ma il punto non sono i numeri. Il punto è cosa significano.

Fino a ieri, solo l’1% della popolazione mondiale sapeva programmare. Il software, che governa praticamente ogni aspetto della nostra vita, era costruito da una casta ristretta di persone con competenze specifiche e anni di formazione.

Oggi quella barriera si sta sgretolando. Un founder può costruire il suo MVP in un weekend. Un marketing manager può crearsi il tool interno che gli serviva senza aprire un ticket al team tech. Uno studente di economia può tirare su un’app con database, autenticazione e pagamenti in un pomeriggio.

Il 99% della popolazione che non sapeva programmare sta entrando nel gioco.

E per chi come me ha costruito la propria carriera su competenze tecniche, questa non è una notizia che si può ignorare.

Cosa perde valore

Devo essere onesto adesso, perché questa parte sarà scomoda.

Se costruire software diventa accessibile a tutti, il valore di “saper costruire software” scende. Si tratta di matematica, non è opinione. Quando una competenza si diffonde, il suo prezzo di mercato cala.

Non sto dicendo che i developer spariranno domani. Sto dicendo che un certo tipo di developer è a rischio.

Il developer che “posa mattoni”. Quello che riceve le specifiche, le implementa e consegna. Quello che è fortissimo nell’esecuzione, ma non si chiede (quasi) mai se quello che sta costruendo ha senso.

Il mio cliente aveva esattamente questo problema. Un developer eccellente dal punto di vista tecnico. Ma nessuno nel team stava rispondendo alla domanda fondamentale: stiamo costruendo la cosa giusta?

Quattro mesi di architettura impeccabile su un prodotto che non aveva ancora trovato il suo mercato. Il come era perfetto. Il cosa e il perché erano completamente fuori fuoco.

E non è un caso isolato, lo vedo continuamente nel mio lavoro. Startup che bruciano mesi e budget su feature che nessuno ha chiesto. Team tecnici che costruiscono soluzioni eleganti a problemi che non esistono. Developer che ottimizzano performance su prodotti che non hanno ancora un utente pagante.

Quando l’esecuzione tecnica era il collo di bottiglia, aveva senso investire tutto lì. Ma se un founder può ricostruire il tuo lavoro di quattro mesi in quattro giorni con un AI builder, il collo di bottiglia si è spostato.

E si è spostato dal “chi sa costruire” a “chi sa cosa costruire” secondo me.

Cosa guadagna valore

Se il codice diventa una commodity, cosa resta?

Resta tutto quello che l’AI non sa fare. E la lista è più lunga di quanto pensi.

Capire il problema vero.

Come ho scritto nella newsletter su WinMX: il vero problema non è mai quello ovvio.

Il cliente che vuole “un sito più veloce” in realtà vuole meno ansia nel processo di checkout.

La startup che cerca “più features” in realtà ha bisogno di capire chi sia il suo utente.

Il founder che chiede “più investimenti” in realtà deve sistemare il product-market-fit.

Lovable può costruirti un’app in un pomeriggio. Ma non può dirti se quell’app risolve un problema reale. Non puo sedersi davanti a un utente e capire che il vero blocco non è tecnologico, ma emotivo.

Non può leggere tra le righe di un feedback e intuire dove sta la vera opportunità.

Sapere cosa NON costruire.

Questa è la skill più sottovalutata in assoluto. Ogni feature che non aggiungi è una feature che non può rompersi, che non va mantenuta, che non complica l’esperienza. Ogni progetto che non inizi è tempo risparmiato per quello che conta davvero.

Il mio cliente ha dovuto buttare via quattro mesi di lavoro perché nessuno aveva avuto il coraggio di dire “fermiamoci, stiamo costruendo troppo”. Avevano automatizzato cose che non serviva automatizzare. Avevano generalizzato quando dovevano specializzare. Avevano costruito per scalare quando dovevano costruire per validare.

La decisione più importante che hanno preso? Smettere di automatizzare.

Mettere una facciata che parla di AI, ma dietro fare il lavoro a mano. Validare prima, automatizzare dopo e concentrarsi su un’unica industry invece di inseguire tutti.

Sembra un passo indietro. È il passo avanti più intelligente che potessero fare.

Tradurre tra due mondi.

Ne ho parlato nella newsletter su come comunico ai non-techy del business: la comunicazione è LA competenza. Puoi avere la soluzione tecnica migliore del mondo, ma se non sai spiegare perché conta al CEO, al commerciale, all’investitore, il tuo impatto resta confinato alla tua tastiera.

Con il vibe coding, questa competenza diventa ancora più critica. Perché ora hai più persone non tecniche che costruiscono cose tecniche, e qualcuno deve fare da ponte. Qualcuno deve dire “questa soluzione funziona oggi ma non scalera tra sei mesi”.

Qualcuno deve tradurre “abbiamo un problema di performance” in “stiamo perdendo il 20% dei clienti al checkout”.

Il gusto di prodotto.

Saper guardare qualcosa e sentire se funziona o no. Non con una metrica, non con un A/B test, ma con quell’intuizione che viene da anni di esperienza nel costruire cose e osservare come le persone le usano.

L’AI può generare dieci versioni di un’interfaccia, ma non sa quale delle dieci farà sentire l’utente a casa.

La riflessione che dovresti fare

Per costruire Lovable, che promette di rendere inutile saper programmare, servono i migliori ingegneri al mondo.

Cento persone che generano 2 milioni di dollari in ricavi ciascuna. Non stiamo parlando di persone qualsiasi, ma tra i migliori cervelli nel mondo dell’AI e dell’ingegneria del software sul pianeta.

Per rendere “inutile” programmare serve concentrare più talento di programmazione in un unico posto di quanto la maggior parte delle aziende tech abbia mai fatto.

Il valore non scompare: si sposta.

Si sposta da “saper scrivere codice” a “saper pensare a cosa il codice deve fare”. Da “eseguire” a “decidere”. Da “costruire” a “orchestrare”.

Il programmatore del futuro non è un muratore che posa mattoni, è un direttore d’orchestra. Sa benissimo quali strumenti usare, quando farli entrare e come farli suonare assieme. Ma, soprattutto, sa riconoscere quando la musica non funziona anche se ogni singolo strumento sta suonando le note giuste.

Il cerchio si chiude

Torniamo al mio cliente e al suo MVP ricostruito in quattro giorni.

Non ha eliminato il bisogno di competenza tecnica, ha eliminato il collo di bottiglia.

Prima: un developer da 40.000 dollari che costruiva l’architettura perfetta per un prodotto non validato.

Dopo: il founder che parla con gli utenti, torna alla scrivania, e modifica il prodotto in tempo reale. Nessun intermediario. Nessun ticket. Nessuna call di allineamento.

Non è che il developer servisse di meno, ma serviva dopo. Prima ci voleva qualcuno che capisse cosa costruire e cosa no, applicando quella competenza che nessun AI builder può replicare.

Guardando la mia carriera, mi rendo conto che il mio valore non è mai stato nel codice che sapevo scrivere, ma è stato nelle domande che sapevo fare. “Ma il vero problema qui qual è?” “Siamo sicuri che questa feature serva?” “Cosa succede se non costruiamo niente e testiamo prima a mano?”

Il codice sta diventando una commodity. La visione no.

E forse, paradossalmente, proprio nel momento in cui tutti possono programmare, chi sa davvero cosa vale la pena costruire diventa più prezioso che mai.

Ci vediamo alla prossima newsletter.

Senza filtri,
Chri

Devo essere onesto: la prima volta che mi hanno mostrato ChatGPT non ci credevo neanche io.

E non perché fossi uno di quelli scettici stile “ah sì, l’intelligenza artificiale, una roba da film”, anzi. Nel 2015-16 lavoravo in una startup di Milano che si chiamava iGenius (oggi Domyn), che faceva proprio quello: intelligenza artificiale. Quindi c’ero dentro, la vedevo tutti i giorni.

E per questo ero scettico.

Sapevo quanto fosse complicato far funzionare quella roba bene. Sapevo quanta distanza c’era tra la demo figa e il prodotto vero. Sapevo che tra “sembra intelligente” e “è davvero utile” c’era un canyon.

Poi, a fine 2022, uno dei miei migliori amici mi dice: “Fra, prova questa cosa nuova. ChatGPT.”

Lo apro. Gli do un pezzo di codice, gli descrivo cosa mi serve.

In 30 secondi mi restituisce qualcosa di funzionante.

Non perfetto, eh. C’erano un paio di cose da sistemare. Ma la struttura era lì, la logica era giusta. E io che avevo visto la materia da vicino, che sapevo quanto fosse stato difficile arrivare anche solo a risultati mediocri pochi anni prima, sono rimasto incantato.

Però allo stesso tempo pensavo: “Vabbè, carino come giochino.”

Avere un background in quel mondo mi ha reso più difficile accettare il salto che era stato fatto. Ero così abituato ai limiti della tecnologia che non riuscivo a credere che quei limiti fossero stati superati davvero.

L’ho usato un paio di altre volte quella settimana, per cose piccole: riscrivermi una mail, farmi suggerire un nome per una variabile, roba così. Poi l’ho chiuso e sono tornato a lavorare come sempre.

Il vero cambiamento non è stato immediato. È stato lento, progressivo, e soprattutto non me ne sono accorto finché non mi sono girato indietro.

Quando ho capito che non era un giocattolo

Il momento “click” è arrivato qualche mese dopo, su un progetto reale.

Dovevo fare una due diligence tecnica per un cliente. Analizzare il codebase, capire lo stato dell’architettura, identificare i debiti tecnici, scrivere un report con raccomandazioni.

Di solito questo processo mi prendeva una settimana piena: leggere il codice, prendere appunti, strutturare il documento e infine revisionare.

Quella volta ho provato qualcosa di diverso. Ho iniziato a usare l’AI come sparring partner: gli passavo pezzi di codice e gli chiedevo di analizzarli, gli descrivevo l’architettura e gli chiedevo di trovare i punti deboli, gli facevo generare la prima bozza del report partendo dai miei appunti.

Ho finito in tre giorni. Non in una settimana eh, in. tre. giorni.

Non è che il report fosse peggiore, tra l’altro. Anzi, era uguale e forse in alcune parti anche più strutturato, perché l’AI mi aveva costretto ad essere più preciso nel descrivere i miei problemi.

In quel momento ho capito che non stavo usando un giocattolo. Stavo usando un collaboratore. Uno strano, che non dorme, non si lamenta e ogni tanto dice caz*ate con una sicurezza disarmante, ma un collaboratore.

Pure Karpathy, co-founder di OpenAI, a ottobre definiva i coding agent “slop”. Due mesi dopo ha scritto di non essersi mai sentito così indietro come programmatore. Se anche lui ha fatto quel percorso, vuol dire che è normale partire scettici.

La differenza la fa cosa fai dopo.

Il ribaltamento

Nella mia newsletter di fine anno ho scritto che l’AI è diventata il mio collaboratore silenzioso. Ma non avevo raccontato cosa significa concretamente.

Te lo dico adesso.

Un anno fa il mio lavoro era diviso così: 80% fare, 20% pensare. Scrivevo specifiche, facevo review, preparavo documentazione, costruivo prototipi. Il tempo per ragionare sulla strategia era quello che avanzava, se avanzava.

Oggi si è ribaltato. Passo l’80% del tempo a pensare e il 20% a fare.

Non perché lavoro meno, ma perché il “fare” è diventato più veloce.

Faccio un esempio concreto. Prima, quando un founder mi chiedeva “Ha senso questa architettura?”, io dovevo: analizzare il codice, disegnare un’alternativa, scrivere un documento con pro e contro, preparare una presentazione. Ci volevano giorni.

Oggi scrivo specifiche dettagliate, le passo all’AI, ottengo una prima bozza in un’ora, la revisiono come farei con un junior, correggo le cose che non tornano e consegno. Il tempo che risparmio lo investo in quello che conta davvero: capire se quel founder sta costruendo la cosa giusta, non solo se la sta costruendo bene.

Questo cambiamento non è solo mio. DHH, il creatore di Ruby on Rails, quest’estate diceva a Lex Fridman che non avrebbe mai lasciato scrivere codice all’AI. Oggi ammette che quella resistenza non era ideologica, i modelli semplicemente non erano ancora pronti. Il CTO di Vercel durante le vacanze ha costruito due progetti open source e ha raccontato che Claude si comporta come un senior engineer: gli dici cosa fare e lo fa.

Il punto non è se l’AI cambierà il nostro lavoro perché l’ha già cambiato.

La vera domanda è se te ne sei accorto.

Il dilemma che nessuno racconta

Questa è la parte che mi ha fatto riflettere di più, ma non vedo mai raccontarla da nessuno. Faccio il Fractional CTO e una parte importante del mio lavoro è aiutare i founder a costruire team tecnici: decidere chi assumere, quando e per fare cosa.

A un certo punto, qualche mese fa, stavo per consigliare a un cliente di assumere uno sviluppatore junior per gestire una serie di task operativi: integrazioni, fix minori, documentazione tecnica.

Poi mi sono fermato.

Mi sono chiesto: “Ma prima di spendere 35-40 mila euro l’anno per questa persona, ha senso capire quanto di questo lavoro possiamo efficientare con gli strumenti che abbiamo?”

Ho fatto un test. Per due settimane ho provato a gestire quei task con l’AI, affiancata da me come developer senior.

Risultato: il 60-70% di quel lavoro si faceva in metà del tempo. Non tutto, ma abbastanza da ripensare completamente la priorità di quell’assunzione.

Attenzione: non sto dicendo che gli umani non servono. Sarebbe una minchiata.

Sto dicendo che prima di assumere, oggi, c’è un passaggio in più che non esisteva due anni fa: capire dove gli strumenti possono efficientare e dove serve davvero il capitale umano.

Perché se assumi una persona per fare cose che un tool fa meglio e più velocemente, stai bruciando soldi. Ma se assumi una persona per fare cose che richiedono giudizio, relazione, contesto, creatività, stai facendo l’investimento giusto.

Il problema è che la linea tra le due cose si sta spostando. Velocemente. E se non la tieni d’occhio, rischi di trovarti con un team costruito per un mondo che non esiste più.

Ne ho parlato anche quando ho scritto delle nostre cicatrici digitali: costruiamo partendo dalle nostre esperienze passate, e quelle esperienze possono diventare i nostri limiti. Anche nel modo in cui pensiamo ai team.

Il lato oscuro della forza

Nella newsletter di fine anno ho scritto una frase che mi è rimasta in testa: “Quello che mi preoccupa per il 2026 è non sapere come evolverà l’intelligenza artificiale. Non quanto velocemente cambierà le cose, ma quanto tempo avrò per adattarmi.”

Ci penso spesso.

Non so se il modello Fractional CTO esisterà nella stessa forma tra tre anni. Non so se le competenze che oggi mi rendono utile saranno le stesse che serviranno domani. Non so se sto imparando abbastanza velocemente.

Quello che so è che chi si ferma è fottuto.

Quando ho scritto di WinRAR, la lezione era che a volte la cosa più intelligente è non cambiare. Restare fermi, fare bene una cosa sola, lasciare che il tempo costruisca fiducia. Quando ho scritto di Craigslist, il messaggio era lo stesso: non tutta l’innovazione è necessaria.

Ma qui è diverso.

WinRAR poteva permettersi di non cambiare perché il suo prodotto era già “commoditizzato”. Comprimi un file, decomprimi un file. Fine. Il lavoro di un CTO non è una commodity, almeno non ancora, ma gli strumenti che usa stanno cambiando sotto i piedi. E se non ti muovi con loro, il terreno ti frana sotto.

Non è panico. È consapevolezza.

Come ho scritto quando ho raccontato come resto aggiornato: ho imparato che “essere aggiornati” e “essere preparati” sono due cose diverse. Essere aggiornati significa sapere cosa succede. Essere preparati significa saper agire quando serve.

Con l’AI, non basta sapere che esiste. Devi sapere come ragiona, dove fallisce, come dargli il contesto giusto. E devi farlo ogni giorno, perché quello che funzionava il mese scorso potrebbe non funzionare più oggi.

Cosa sto facendo concretamente

Niente proclami, niente “i 5 step per usare l’AI”. Solo quello che faccio io, che funziona per me.

Scrivo specifiche più dettagliate di prima. Prima di far partire qualsiasi cosa, scrivo esattamente cosa voglio, come lo voglio, quali sono i vincoli. Più il contesto è preciso, migliore è l’output. È come dare un brief a un freelancer: se gli dici “fammi un sito”, ti torna qualcosa di random. Se gli dici esattamente cosa serve, perché e per chi, il risultato cambia completamente.

Faccio review come se stessi seguendo un junior. L’AI produce codice, documentazione, analisi. Ma non mi fido ciecamente. Revisiono tutto, cerco gli errori, verifico la logica. Il pensiero critico sull’output è la competenza più importante che ho sviluppato.

Uso l’AI come sparring partner per le decisioni. Prima di proporre un’architettura a un cliente, la discuto con l’AI. Non perché abbia ragione, ma perché mi costringe a spiegare il mio ragionamento. E quando devi spiegare qualcosa, trovi i buchi (tipo rubber duck programming)

Ho costruito i miei stessi tool con l’AI. Il sito, la dashboard analytics, le automazioni. Non per risparmiare soldi, ma perché avere strumenti costruiti sulle mie esigenze mi rende più efficace.

E soprattutto, ho smesso di avere paura di non sapere tutto. Come ho scritto nella newsletter sullo studio: non memorizzo più nozioni, ma affino la capacità di trovarle quando servono. Con l’AI questo è ancora più vero.

Il mio mestiere sta cambiando

Non so dove saremo tra due anni. Non so se scriverò ancora codice o se il mio lavoro sarà al 100% strategia, visione e traduzione tra tech e business. Non so se i team saranno più piccoli o semplicemente diversi.

Quello che so è che il mio mestiere sta cambiando. E io ho scelto di cambiare con lui.

Non per hype e non perché “lo fanno tutti”. Ma perché quando uno strumento ti permette di fare in tre giorni quello che prima ti prendeva una settimana, non puoi far finta di niente.

La domanda che lascio a te è semplice: nel tuo lavoro, quanto tempo passi a fare cose che uno strumento potrebbe fare per te? E quel tempo che libereresti, su cosa lo investiresti?

Rispondi a questa mail, sono curioso di sapere come stai vivendo questo cambiamento.

Ci vediamo alla prossima newsletter.

Senza filtri,
Chri