[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

Ero solo un ragazzino quando ho iniziato a giocare online (vabbè, a dire la verità io e l’online siamo nati quasi assieme).

Adoravo la sensazione di accendere il PC, aprire TeamSpeak e sentire le voci dei miei amici che mi aspettavano.

“Ooooh, ma ti muovi?! Sei pronto??” ”A te stiamo aspettando, sbrigati!!” Se hai vissuto quell’epoca, sai di cosa parlo. Condividere quei momenti, ridere delle cazzate mentre qualcuno moriva in modo stupido o insultarsi dopo un errore clamoroso faceva parte di un rituale.

TeamSpeak comunque non era per tutti: dovevi trovare un server, configurarlo a parte e poi sperare pure che l’audio non gracchiasse troppo. Ma bastava per quel periodo (anche perché la connessione era quel che era). Poi, a un certo punto, qualcuno ha mandato un link nel gruppo.

”Raga proviamo questo?”

Non ricordo chi fosse e nemmeno il giorno esatto, ma ricordo la sensazione.

Discord non era solo “parlare mentre giochi”, era qualcosa di diverso. C’erano i canali, c’erano i ruoli, c’era una struttura. Non era solo più una chiamata vocale con gli amici, era un posto dove accadevano cose.

Due tool, due filosofie completamente diverse.

E sai qual è la cosa assurda? Discord non doveva nemmeno esistere.

Il problema che nessuno risolveva (bene)

Nel 2015, se volevi parlare con gli amici mentre giocavi, le opzioni erano queste:

Skype dominava la comunicazione casual, ma non era pensato per il gaming. Pesante, mangiava un botto di risorse e crashava durante le partite. A quei tempi non me ne fregava ovviamente ma ho scoperto che esponeva il tuo indirizzo IP. I ragazzini più stronzi potevano farti un attacco DDoS e buttarti offline nel bel mezzo di un raid su WoW.

TeamSpeak era tecnicamente eccellente. Latenza bassissima, audio pulito. Ma richiedeva di affittare o mantenere un server. Setup complesso, port forwarding, configurazioni che il gamer casual non avrebbe mai fatto.

Entrambi funzionavano “abbastanza bene”.

Ma “abbastanza bene” non è mai abbastanza quando qualcuno arriva con qualcosa che funziona davvero.

Il videogioco non è andato

Jason Citron nel 2012 aveva già fatto i soldi.

Tre anni prima aveva venduto OpenFeint, una piattaforma social per giochi mobile, a FREE per 104 milioni di dollari.

Aveva solo 26 anni (beato lui), avrebbe pure potuto ritirarsi, ma invece fece quello che fanno i veri builder: ricominciò da capo.

Fondò Hammer & Chisel con un’ambizione precisa: creare il primo MOBA serio per tablet.

Lo chiamò Fates Forever, un League of Legends ma per iPad.

Era fatto bene, i critici lo lodarono, Apple gli diede anche l’Editor’s Choice.

Ma, c’è un ma: nessuno lo giocava.

Il mercato era troppo limitato (solo ai possessori di iPad), la competizione feroce e la retention pessima lo schiacciarono, oltretutto Vainglory era appena uscito. Citron e il suo team avevano costruito qualcosa di tecnicamente eccellente per carità, ma non interessava a nessuno.

Non so, ti suona familiare?

La feature che nessuno aveva chiesto

Dentro Fates Forever il team aveva costruito una chat vocale per permettere ai giocatori di coordinarsi durante le partite.

Era una feature secondaria. Infrastruttura. Roba che doveva funzionare e basta.

Solo che funzionava davvero tanto bene, talmente tanto bene che la gente iniziò a usarla parlare invece che per giocare.

Citron se ne accorse. Gli utenti erano più interessati a connettersi tra loro, a formare amicizie, a stare insieme, che a eseguire la meccanica del gioco.

Il gioco stava fallendo.

Ma quella chat no.

Il pivot che non ti aspetti

Ci sono due modi di raccontare un pivot.

Il primo è quello glorificato: “Fail fast, pivot, succeed.” Sembra facile, quasi figo.

Il secondo è quello vero. Ed è quello che Citron racconta:

“Pivoting feels like fucking up, honestly. La gente ne parla in modo glorificato, come se fallire velocemente e poi pivotare fosse normale. La realtà è che è emotivamente devastante. Hai appena speso mesi a versare il tuo cuore in qualcosa e non sta funzionando. E poi devi realizzarlo e ripensare tutto.”

Citron quindi prese la decisione più difficile.

Decise di uccidere Fates Forever riducendo il team da 18 persone a un manipolo di ingegneri. E puntò tutto sulla chat vocale che nessuno gli aveva chiesto di costruire.

Uno dei suoi ingegneri si dimise il giorno dopo, via post-it.

Metà del team pensava fosse la decisione più stupida di sempre. “TeamSpeak funziona benissimo, questo non funzionerà mai.”

Nel maggio 2015 lanciò Discord.

Venti utenti e il dubbio di mollare tutto

Discord uscì… e non successe niente. Per settimane e settimane praticamente non lo usò nessuno. Venti persone al giorno massimo, amici obbligati a testarlo. Il team allora provò il marketing tradizionale. Niente. Cercò influencer. Ancora poco e niente.

Citron considerò di arrendersi. Ma poi decidero di fare qualcosa di completamente diverso. Un amico condivise un post su un subreddit di Final Fantasy XIV. Non era un pitch, né una pubblicità, ma una domanda genuina:

“Ehi, stiamo costruendo uno strumento di comunicazione. Credi che possa risolvere un problema per te?”

Il tono non era da vendita, ma da curiosità.

Il post generò cinquanta utenti il primo giorno, cento il secondo. Poi il numero iniziò a crescere. Il team replicò: World of Warcraft, Diablo, StarCraft. Ovunque tutti i gamer si riunissero, loro andavano lì. E non per vendere, ma per ascoltare.

Otto mesi dopo: 3 milioni di utenti.

Un anno dopo: 25 milioni.

Perché funzionava (la versione semplice)

Discord non era tecnicamente superiore a tutto.

TeamSpeak aveva latenza più bassa. Skype aveva più utenti.

Ma Discord aveva trovato il compromesso perfetto:

Server centralizzati invece di peer-to-peer. Cerco di non usare troppo serpentese, promesso. In pratica il tuo IP resta nascosto. Niente più burloni che ti buttano offline perché li hai battuti (forse io ero uno di quelli…)

Latenza ottimizzata per il parlato. 50-100 millisecondi sono impercettibili per la voce umana. Non serviva la perfezione tecnica di TeamSpeak, serviva “abbastanza buono” a scala.

Onboarding in un click. Ricevi un link, clicchi, metti un username, sei dentro. Per un gamer tra una partita e l’altra, con 40 secondi di countdown, questa semplicità non era un nice-to-have. Era tutto.

Il vantaggio tecnico non era la tecnologia in sé. Era aver capito esattamente cosa serviva al target e aver costruito solo quello.

Va che numeri adesso

Oggi Discord ha:

• 200+ milioni di utenti attivi mensili

• 15 miliardi di valutazione

• 725 milioni di dollari di fatturato annuo

• 4 miliardi di minuti di conversazione vocale ogni giorno

Tutto partito da una feature secondaria di un gioco che nessuno voleva giocare.

Un’offerta che (non) puoi rifiutare

Nel 2021 Microsoft bussò alla porta e presentò un’offerta: 12 miliardi di dollari per acquisire Discord.

Per dare un contesto: Microsoft aveva comprato Skype per 8.5 miliardi. Stava offrendo il 40% in più per un’azienda che fatturava una frazione.

Discord disse no.

“Abbiamo deliberatamente perseguito un modello di business che non dipende dalla monetizzazione dei dati dei nostri utenti,” spiegò il co-fondatore Stan Vishnevskiy.

Volevano l’IPO. Credevano che Discord potesse diventare più grande da indipendente di quanto sarebbe mai diventato dentro Microsoft.

È facile dire “segui la tua visione” quando non hai 12 miliardi sul tavolo.

È molto più difficile farlo quando ce li hai davvero.

Non è la prima volta che lo vediamo

E qui la storia diventa ancora più interessante.

Perché Discord non è l’unico caso.

Slack nacque da Glitch, un gioco multiplayer online che fallì dopo 4 anni di sviluppo e 17.5 milioni investiti. Il sistema di chat interna che il team usava per coordinarsi divenne il prodotto. Salesforce lo comprò per 27.7 miliardi.

Instagram nacque da Burbn, un’app di check-in che nessuno usava. Kevin Systrom notò che gli utenti erano interessati solo alla feature di condivisione foto. Tolse tutto il resto. Facebook la comprò per 1 miliardo, con 13 dipendenti.

Twitter nacque da Odeo, una piattaforma di podcasting resa obsoleta quando Apple annunciò che iTunes avrebbe supportato i podcast nativamente. Durante un hackathon interno, Jack Dorsey propose l’idea degli “status update”. Il resto è storia.

Quattro aziende. Quattro prodotti falliti. Quattro pivot su feature secondarie.

Decine di miliardi di valore creato.

Il pattern è chiaro: il vero prodotto era nascosto dentro quello sbagliato.

L’arte di riconoscere cosa stai davvero costruendo

La lezione di Discord non è “fallisci veloce e poi pivota”.

È qualcosa di più sottile e più difficile.

È avere l’umiltà di vedere che gli utenti stanno usando il tuo prodotto in modo diverso da come l’avevi pensato.

Citron voleva costruire un gioco, gli utenti volevano parlare tra loro.

Systrom voleva costruire un’app di check-in. Gli utenti volevano condividere foto.

Butterfield voleva costruire un mondo virtuale. Il suo team voleva una chat migliore.

In tutti i casi, il founder aveva una visione. E in tutti i casi, la realtà gli ha mostrato qualcosa di diverso.

La differenza tra chi crea miliardi e chi fallisce non è l’idea iniziale. È la capacità di vedere cosa sta realmente succedendo e il coraggio di seguirlo.

Non è facile.

Significa ammettere che avevi torto. Significa uccidere il progetto in cui hai versato anni della tua vita. Significa guardare in faccia il tuo team e dire: “Cambiamo tutto.”

Ma a volte, dentro il prodotto sbagliato, c’è quello giusto che aspetta di essere riconosciuto.

La domanda che ti lascio

Se stai costruendo qualcosa, fermati un secondo.

Guarda come le persone lo usano davvero. Non come vorresti che lo usassero. Come lo usano.

C’è una feature che genera più engagement del previsto? C’è un comportamento che non avevi anticipato? C’è qualcosa che i tuoi utenti fanno che ti sorprende?

Forse quella è la risposta.

La prossima volta che guardi i dati del tuo prodotto, chiediti:

“Quale feature del mio prodotto è segretamente il vero prodotto?”

Dopotutto… potrebbe valere 15 miliardi.

Ci vediamo alla prossima newsletter.

Senza filtri,
Chri

Da quando ho iniziato a costruire prodotti ho iniziato anche a studiare e ad osservare come li facevano gli altri.

Aprivo app di aziende con budget enormi, team di centinaia di sviluppatori e risorse praticamente infinite. Spesso, quello che vedevo, era uno schivo. Pensavo: “ma com’è possibile che siano così tremendi con tutti quei soldi investiti?”

Poi mi capita di vedere prodotti di startup che con due lire e team di cinque persone mettono in piedi un prodotto di qualità. E non è un caso isolato.

Ho iniziato a osservare con più attenzione e a cercare di capire cosa distingue un prodotto fatto bene da uno fatto male. Soprattutto perché ad alcuni escono bene e ad altri male (nonostante i budget differenti).

Sai cosa? La risposta non è così ovvia.

Non è un questione di soldi e nemmeno una questione di competenze tecniche.

È qualcos’altro.

Il problema non è mai uno solo

Quando un prodotto fa schifo, la tentazione è cercare un colpevole: il budget, il team, la tecnologia e il tempo.

Ma la realtà è più complessa… Ci sono diversi fattori che uccidono la qualità e spesso agiscono insieme.

La qualità non è mai una priorità

Hai mai sentito qualcuno entrare in riunione e dire “facciamo un prodotto di merda”?

Direi di no (o almeno spero).

Ma nessuno dice nemmeno “la qualità viene prima di tutto, anche se costa di più, anche se ci vuole più tempo”. La qualità resta sottintesa, data per scontata. E quando arriva la pressione, è la prima cosa che salta. Perché non era mai stata davvero una priorità.

La distanza tra chi decide e chi costruisce

Più un’organizzazione cresce, più si creano passaggi intermedi. Il designer propone qualcosa, il PM lo filtra, il manager lo annacqua per farlo passare e infine lo sviluppatore implementa ciò che resta.

Ogni passaggio crea distanza tra l’idea originale e il risultato finale, ergo il risultato finale non è più di nessuno, è il compromesso tra i compromessi.

Tutti responsabili, nessuno responsabile.

Tutti sono responsabili dell’esperienza utente, nessuno lo è davvero. Le decisioni diventano scollegate. Ogni pezzo del prodotto funziona per conto suo, ma l’insieme non ha senso. Manca qualcuno che guardi il tutto e dica “questa cosa non funziona”.

Metriche sbagliate guidano i risultati sbagliati.

Se il successo si misura in numero di feature rilasciate, otterrai tante feature fatte male. Se misuri la velocity, otterrai velocità senza direzione. Se misuri i ticket chiusi, otterrai ticket chiusi di fretta. I KPI guidano i comportamenti. E se i KPI non includono la qualità, la qualità sparisce.

La paura di dire no.

Ogni stakeholder ha la sua richiesta: il commerciale vuole quella feature in modo da chiudere il cliente, il marketing poi vuole quel banner e il CEO ha visto una cosa dal competitor che vuole implementare.

Nessuno ha il coraggio o l’autorità di dire di no, quindi il prodotto diventa un accumulo che somiglia più ad un albero di Natale dove ognuno ha appeso una sua pallina. E alla fine non si capisce più cosa dovrebbe essere o cosa dovrebbe fare.

L’urgenza sovrasta la cura.

L’urgenza di rilasciare sovrasta la cura per quello che rilasci. Prima lo facciamo funzionare, poi lo miglioriamo. Ma il “poi” non arriva mai, perché c’è sempre qualcos’altro di urgente.

Le scorciatoie si accumulano.

Ogni scorciatoia sembra innocua nel momento in cui la prendi, “tanto lo sistemiamo dopo”, “per ora va bene così”, “è un workaround temporaneo”.

Tutte frasi che portano a scorciatoie, scorciatoie che si sommano, che diventano debito tecnico, e che rende ogni miglioramento più costoso, più rischioso. E arrivi al punto in cui migliorare diventa più difficile che rifare. Ma indovina? rifare non si può, quindi si rattoppa, e il rattoppo genera altro debito.

Questi fattori non si escludono a vicenda. Si sommano. Si amplificano. E il risultato è quel comportamento che è alla luce del sole: aziende con risorse enormi che producono esperienze mediocri.

Le startup hanno un vantaggio, ma non è scontato

Team piccolissimi, decisioni veloci. Chi decide è spesso chi costruisce, non ci sono dieci layer tra visione ed esecuzione.

Ma questo non significa che le startup facciano qualità di default.

Significa solo che hanno meno ostacoli strutturali. Meno burocrazia da attraversare. Meno compromessi obbligati.

Ma la qualità resta una scelta: un investimento consapevole, e anche una startup con tre persone può fare un prodotto di merda se non ci investe, se non la mette come priorità, se cede alla tentazione di “fare veloce” invece che “fare bene”.

Il vantaggio delle startup non è che fanno qualità per natura. È che possono scegliere di farla senza dover prima smontare una struttura che la impedisce.

E questa scelta, secondo me, non è mai un errore.

Cosa significa qualità per me

Quando prendo in mano un prodotto per la prima volta, la mia testa fa automaticamente una checklist (tipo lo scanner).

La prima cosa che guardo è la prima impressione visiva e di interazione. È curato? C’è attenzione ai dettagli? Le cose sono dove me le aspetto? I margini sono consistenti? I colori hanno senso? Sembra che qualcuno ci abbia pensato o sembra buttato lì?

Poi c’è la performance percepita. Non i millisecondi reali, non sto con il cronometro. Parlo di come si sente l’esperienza. Mi sembra veloce o mi sembra di aspettare? Le transizioni sono fluide o a scatti? Quando faccio un’azione, la risposta è immediata o c’è quel micro-ritardo che ti fa dubitare se il click sia andato a buon fine?

Guardo la coerenza. Sembra fatto da un team con una visione condivisa o da quindici team che non si sono mai parlati? I pattern si ripetono o ogni schermata sembra un’app diversa? I bottoni funzionano allo stesso modo ovunque?

Guardo la gestione degli errori (o degli imprevisti). Cosa succede quando qualcosa va storto? C’è un messaggio d’errore che mi spiega cosa è successo e cosa posso fare? O l’app crasha e basta? Gli stati vuoti sono gestiti? Se non ci sono dati, cosa vedo?

E per ultimo ma non per importanza, il copy. Mi parlano come una persona o come un robot dell’ufficio legale? I messaggi sono chiari? Capisco cosa devo fare? O devo interpretare gergo tecnico e frasi contorte?

Queste cose le noti nei primi trenta secondi. E ti dicono già quasi tutto su quanto chi ha costruito quel prodotto ci teneva davvero.

Chi lo fa bene secondo me

Ci sono prodotti che quando li uso penso: qui qualcuno ci ha messo cura. Ti faccio un paio di esempi:

• Pinterest è ossessionato dalla performance percepita, il caricamento infinito non lo senti mai e le immagini appaiono di continuo e progressivamente. Non c’è mai un momento in cui guardi qualcosa e ti chiedi se l’app si è bloccata. Tutto scorre, è una di quelle cose che non noti finché non trovi un’app che non lo fa.

• Claude e ChatGPT hanno reso naturale qualcosa di tecnicamente complesso. Lo streaming della risposta che ti tiene ingaggiato. La sensazione di conversazione. Dietro c’è una complessità enorme, ma tu non la vedi. Vedi solo qualcosa che funziona.

• PostHog è product analytics fatto da gente di prodotto. L’interfaccia non ti fa sentire stupido. La documentazione rispetta la tua intelligenza. È open source ma con una UX da SaaS premium. Ogni volta che lo uso penso: questi capiscono cosa serve a chi lo usa.

• Revolut ha fatto sembrare le banche tradizionali dei dinosauri. Ogni interazione è fluida. Le notifiche sono utili (non spam). Il cambio valuta in tempo reale sembra magia. Hanno preso un’industria ingessata e hanno dimostrato che si poteva fare diversamente.

Nessuna di queste aziende aveva budget illimitati all’inizio eppure hanno scelto la qualità come differenziatore. E hanno continuato a sceglierla anche quando potevano permettersi di non farlo.

Metà budget, doppia soddisfazione

Ho avuto un’esperienza diretta su questo tema poco tempo fa.

Un cliente mi ha chiesto di rifare un SaaS che aveva fatto sviluppare da altri. Il budget che avevano speso la prima volta era più del doppio di quello che avevo io a disposizione. Team più grande, più tempo, più risorse.

Il risultato? Un prodotto che non funzionava. Lento. Incoerente. Pieno di bug. E la home page, giuro che non sto esagerando, aveva un’immagine di sfondo. Un SaaS B2B. Con un’immagine di sfondo sulla home. Come fosse un sito vetrina del 2008.

L’abbiamo rifatto con metà del budget. Il cliente era molto più contento.

Non perché siamo più bravi. Non perché abbiamo qualche tecnologia segreta. Ma perché le priorità erano diverse. L’ownership era chiara. Chi decideva era vicino a chi costruiva. Non c’erano dieci passaggi tra “questa cosa dovrebbe funzionare così” e “ok, facciamola funzionare così”.

La differenza non erano i soldi. Era come quei soldi venivano spesi.

Come costruisco qualità (e come la proteggo)

Negli anni ho sviluppato un approccio che ha due parti. La prima è come costruisco qualità. La seconda è come evito di perderla quando le cose crescono.

Come costruisco.

Parto sempre dall’esperienza utente, non dalle feature. La domanda non è “cosa deve fare questo prodotto” ma “cosa deve provare chi lo usa”. È una differenza sottile eh, ma cambia tutto.

Non negozio mai sulle basi. Performance, gestione errori, coerenza visiva. Queste cose non sono optional, non sono “nice to have”, non sono “le facciamo nella prossima release”. Sono il minimo. Se non ci sono, il prodotto non è finito.

Faccio scelte esplicite su cosa non fare. Ogni feature che non aggiungi è una feature che non può rompersi, che non richiede manutenzione, che non complica l’esperienza. Dire no è parte del lavoro.

Testo con persone vere il prima possibile. Non per validare che funziona tecnicamente, ma per vedere dove si inceppano, cosa non capiscono, dove perdono tempo.

Come la proteggo.

Questa è la parte più difficile. Perché la qualità tende a degradare naturalmente quando le cose crescono. Più persone, più comunicazione, più compromessi.

La chiave è l’ownership chiara. Ogni pezzo del prodotto deve avere un responsabile. Non un team. Una persona. Qualcuno che si sveglia la mattina pensando “questa cosa è mia, e deve funzionare bene”.

Team piccoli con responsabilità end-to-end funzionano meglio di team grandi con responsabilità frammentate. Meglio tre persone che fanno tutto che dieci persone dove ognuno fa un pezzetto e nessuno vede l’insieme.

Chi decide deve sporcarsi le mani. Il momento in cui chi prende le decisioni smette di usare il prodotto, di vedere il codice, di parlare con gli utenti, è il momento in cui la qualità inizia a scendere.

Meno layer significa meno diluzione e ogni passaggio tra la visione e l’esecuzione è un’opportunità per perdere qualcosa. Riduci i passaggi.

Serve il coraggio di dire di no: dire di no a feature che non servono, a stakeholder che vogliono aggiungere cose, a scorciatoie che creano debito. Siamo d’accordo, dire di no è scomodo, ma spesso è anche l’unico modo per proteggere ciò che conta.

La qualità non si mantiene per caso. Si mantiene con strutture che la proteggono attivamente.

Oggi abbiamo un nuovo alleato

L’intelligenza artificiale sta liberando tempo. Attività che prima richiedevano ore ora ne richiedono minuti. Codice che prima scrivevi riga per riga ora lo generi e lo raffini. Documentazione, test, debug, tutto sta accelerando.

La domanda è: quel tempo dove lo mettiamo?

Possiamo usarlo per fare di più. Più feature, più prodotti, più clienti, più tutto.

Oppure possiamo usarlo per fare meglio: più cura, più attenzione, più qualità.

Investire sulla qualità non è mai stato così accessibile perché abbiamo gli strumenti che ci permettono di dedicare più tempo alle cose che contano: l’esperienza e i dettagli (quelli importanti).

La scelta è nostra.

E la prossima volta che apri un’app che fa schifo, chiediti: stanno facendo schifo perché non sanno fare meglio, o perché hanno scelto di non investire sulla qualità?

Perché alla fine, è sempre una scelta.

Ci vediamo alla prossima newsletter.

Senza filtri,
Chri

Diciamoci la verità, ogni volta che apri Jira non sei contento. L’ultima volta che l’ho utilizzato mi son trovato a dover passare diverso tempo nel configurarlo e nel renderlo “fit” per il caso d’uso.

Apro Jira, creo il progetto e via al delirio.

Quale template vuoi? Scrum o Kanban? Vuoi le epiche? Come vuoi chiamare gli stati? Vuoi i subtask? I componenti? Le versioni? I campi personalizzati?

Sono passati 40 minuti e non ho ancora creato un singolo task.

Mi torna in mente la prima volta che ho aperto Linear, qualche anno fa. Era per un’altra startup, ero quasi un early adopter. Ricordo che cercavo di fare una cosa specifica su Jira, non mi ricordo nemmeno più quale e ci stavo perdendo la testa. Poi qualcuno mi dice “prova Linear”.

Lo apro. Creo il workspace. In 5 minuti sto già lavorando.

Nessuna domanda esistenziale. Nessuna configurazione infinita. Nessun “prima devi settare gli scheme”. Solo un tool che funziona come ti aspetti che funzioni.

In quel momento ho capito una cosa che mi porto dietro ancora oggi: la differenza tra un prodotto costruito per chi lo compra e un prodotto costruito per chi lo usa.

Il cimitero dei task manager

Se c’è un settore dove le startup vanno a morire, è il project management.

Ci sono già Jira, Asana, Monday, Trello, ClickUp, Notion, e altri 3217361 tool che escono ogni settimana su Product Hunt. Il mercato sembra saturo da almeno dieci anni.

Qual è la strategia di tutti questo tool? Aggiungere feature: mille integrazioni, più automazioni, più dashboard e più report.

Linear ha fatto l’opposto: ha tolto.

Niente campi di personalizzazione infiniti, niente workflow builder complessi e mille opzioni di configurazione. Niente “puoi fare tutto quello che vuoi”.

Ti propone un modo di lavorare, quello giusto e pensato su di te.

E mentre tutti cercavano di essere “la piattaforma all-in-one per tutti”, Linear ha scelto di essere lo strumento perfetto per qualcuno.

Ecco che arriva il risultato: un unicorno da 1.25 miliardi di dollari in un mercato che tutti davano per finito.

Va che numeri va…

52 milioni di dollari di fatturato ricorrente ogni anno. Nel 2024 erano in cinquantasette persone. Linear, in un mondo dove le startup bruciano circa il 30-40% in advertising e growth hacking, ha speso solo 35.000 dollari in sei anni.

In. Sei. Anni.

E con questa strategia, mentre tutti bruciavano soldi per crescere, loro cominciavano a generare cassa (profittevoli dal 2021)

Altra cosa incredibile è che churn rate sotto il 5% annuale, una volta che un team entra in Linear, non ne esce più.

E il fatturato per ciascun dipendente? Quasi un milione di dollari a testa, la media SaaS è di 200-300k.

Che dire… complimentoni.

La differenza: costruire per chi usa, non per chi compra

Jira non è costruito per gli sviluppatori, ma per chi lo compra.

Pensaci. Chi decide di adottare Jira in un’azienda? Il management. Il procurement. I team lead che devono “tracciare il lavoro” e “generare report per gli stakeholder”.

È perfetto per loro: dashboard infinite, metriche su ogni cosa, una customizzazione totale perfetta per adattarsi a qualsiasi processo aziendale. In pratica il sogno di chi deve giustificare il budget e fare powerpoint.

Però poi chi lo deve usare ogni giorno, lo vede come un incubo: sviluppatori, design, product manager… insomma, quelli che effettivamente fanno il lavoro pratico.

Una volta lessi un commento su HackerNews che mi fece ridere (ma anche riflettere): “Le aziende scelgono Jira per soddisfare manager e consulenti, non sviluppatori. Il tool diventa il simbolo del ‘fare Agile’ invece di essere agile”.

Linear ha ribaltato questa logica.

Dal loro manifesto, il Linear Method:

“Software project management tools should build with the end users — the creators — in mind. Keeping individuals productive is more important than generating perfect reports.”

Tradotto: fottetevene dei report perfetti e fate lavorare bene le persone.

Karri Saarinen, il CEO, lo dice chiaramente: “La mia filosofia di design è sempre stata che devi progettare qualcosa per qualcuno. È quasi impossibile progettare qualcosa di davvero buono per tutti.”

Linear ha scelto il suo “qualcuno”: i builder. Gli IC. Quelli che scrivono codice, progettano interfacce, costruiscono prodotti.

E ha detto a tutti gli altri: “Non siamo per voi. E va bene così.”

Il paradosso del “No” (e perché la gente ama Linear)

Jori Lallo, co-founder di Linear, disse:

“Flexible software lets everyone invent their own workflows, which eventually creates chaos as teams scale.”

Jira ti dà infinite possibilità di configurazione: campi custom, stati custom, workflow custom, permessi custom… tutto custom. Quella che sembra una feature, però, diventa una trappola.

Però, se ogni team configura Jira a modo suo, dal momento che ogni progetto e ogni persona ha le sue regole e interpretazioni, come gestisci la collaborazione se nessuno sta parlando la stessa lingua?

Quando prendi un mobile da IKEA trovi almeno le istruzioni, non c’è scritto “costruisciti il mobile da solo e auguri”. Anche perché quante volte rimarresti con le viti in mano? (a me capita spesso, ma vabbè) IKEA invece ti dà il libretto, le istruzioni sono precise e se segui i passaggi il risultato è garantito.

Così Linear ha fatto la scelta opposta a Jira: ha deciso che doveva esserci un metodo, un solo modo di fare le cose, uno “giusto”. Forte magari, però hanno ragione loro almeno per ora.

Linear dice sistematicamente no alle feature request. Non perché non possano implementarle. Perché sanno che ogni feature aggiunta è complessità aggiunta. E la complessità uccide la produttività.

E sai qual è il risultato?

I team che usano Linear ne parlano con entusiasmo, quasi come se fosse un culto. “Devi provarlo,” “non posso più tornare indietro,” “è l’unico tool che mi fa venire voglia di gestire i task.”

Vogliamo parlare invece dei team che usano Jira? Quando gli chiedi cosa ne pensano hanno solo una risposta: “fa schifo”.

C’è una metrica che, secondo me, è un vantaggio competitivo ed è sottovalutata, ovvero il piacere quotidiano di usare uno strumento.

Le sensazioni sono importati perché creano fedeltà: per quanto possa, per esempio, una Fiat Punto fare le stesse cose di una Mercedes, la sensazione sarà completamente diversa e inciderà sulla scelta futura di quale macchina usare, o anche sulla voglia che si ha di guidare.

Il feeling crea fedeltà, crea crescita organica senza spendere un euro in marketing.

Il metodo Linear: non vendono un tool, vendono un metodo

Facci caso, loro non vendono un task manager ma vendono un modo di costruire prodotti.

Il tool è solo il veicolo. La vera proposta di valore è il loro metodo, un insieme di principi che hanno codificato e reso pubblici.

Alcuni esempi:

“Write issues, not user stories.” Scrivi task in linguaggio semplice. Niente format rigidi tipo “As a user, I want to...” che nessuno legge davvero, descrivi cosa va fatto, in modo chiaro.

“Build with users.” Non salvare ogni feature request per sempre. Le cose importanti torneranno a galla. Quelle a bassa priorità non verranno mai fatte comunque. Un backlog più snello significa pianificazione più veloce.

“Say no to busy work.” Gli strumenti devono lavorare per te, non il contrario. Se passi più tempo a gestire il tool che a fare il lavoro vero, c’è un problema.

“Generate momentum.” L’obiettivo non è finire lo sprint. È mantenere un ritmo sano e costante. Meglio consegnare poco ma continuamente che strafare e poi crollare.

Linear ha capito che il problema del project management non è tracciare i task. È costruire prodotti.

E per costruire prodotti serve focus, non feature.

La domanda che dovresti farti

È inevitabile, strumenti come questi fanno riflettere chi come me crea prodotti.

Quante volte aggiungiamo feature perché “il competitor ce l’ha”? Quante volte complichiamo l’interfaccia perché “il cliente enterprise lo richiede”? Quante volte costruiamo per chi firma il contratto invece che per chi usa il software ogni giorno?

Linear ha dimostrato che esiste un mercato enorme di persone disposte a pagare di più per avere meno.

Ma quel “meno” deve significare più velocità, più focus, più rispetto per il tempo dell’utente.

La domanda che mi porto a casa è: stai costruendo per chi compra o per chi usa?

Perché nel breve termine, costruire per chi compra ti fa chiudere i contratti. Ma nel lungo termine, costruire per chi usa ti fa tenere i clienti.

Linear non aveva bisogno di un team sales, il prodotto si vendeva da solo e gli utenti diventavano per primi gli ambasciatori.

Però ora chiediti: quante feature del tuo prodotto esistono per impressionare chi firma il contratto, invece di aiutare chi lavora ogni giorno?

La risposta a questa domanda potrebbe valere 52 milioni di dollari.

Ci vediamo alla prossima newsletter.

Senza filtri,
Chri

L’altro giorno stavo rinnovando il mio sito e volevo aggiungere una seconda lingua e i case study. Per farlo, il buon Webflow, un tool da 182 euro annui, mi chiedeva altri 18 dollari al mese.

In totale 200 euro in più all’anno per qualcosa che, tecnicamente, è solo una cartella di file duplicati con un testo diverso.

Stavo per cedere, alla fine mi serviva, poi arriva una mail:

Allora mi sono chiesto: ma quanto ci metto a farmi il sito da zero con l’AI?

4 ore dopo avevo un sito custom in Astro, hostato gratis su Vercel, con tutte le lingue che volevo e i case study in markdown.

E lì è partita la spirale.

La lista della spesa che non volevo più pagare

Una volta capito che potevo costruirmi il sito, ho iniziato a guardare gli altri abbonamenti con occhi diversi.

Webflow: 362 euro l’anno.

Shield (analytics LinkedIn): 166 euro l’anno per vedere quattro grafici che potevo farmi da solo.

Zapier: 260 euro l’anno per automazioni che n8n fa self-hosted a 10 dollari al mese.

Totale: oltre 788 euro l’anno. Non sono cifre che ti cambiano la vita, sia chiaro, ma sono soldi che pagavo per funzionalità che usavo al 20%.

Il problema non era il prezzo. Era che stavo pagando per software pensati per tutti, quando a me serviva qualcosa di specifico.

4 ore e un sito nuovo

Ho aperto Claude Code, ho descritto quello che volevo e ho iniziato a costruire.

Il sito in Astro è stato il progetto più lineare. Template base, markdown file come CMS e deploy su Vercel. Zero costi di hosting, performance migliori di Webflow, controllo totale sul codice.

Ma la vera soddisfazione è stata Shield.

Shield ti mostra le analytics dei tuoi contenuti LinkedIn: impression, engagement, crescita followers. Tutto utile, ma è lento e poco funzionale.

Lo usavo una volta a settimana per confrontare il periodo passato con quello corrente e per fare ragionamenti sulla settimana successiva. Il problema principale, però, era che non mi permetteva di confrontare velocemente i dati e che l’interfaccia non rispondeva come desideravo.

Quindi mi sono costruito il mio sistema:

1. Un’estensione browser che fa scraping dei miei dati analitici direttamente da LinkedIn

2. Un server locale che salva questi dati

3. Una dashboard che mostra esattamente quello che mi serve

Gira tutto in locale. Niente cloud, niente abbonamenti, niente limiti. E la dashboard fa esattamente quello che voglio io, non quello che ha deciso qualcun altro.

L’ho chiamato Scudo. Ovviamente, direi.

Il fenomeno che sta crescendo

Non sono l’unico a fare questa cosa.

Su Reddit un utente ha documentato come è passato da 1.200 dollari al mese di abbonamenti SaaS a 50 dollari in costi server. Ha sostituito il suo tool di email marketing con AWS SES, ha costruito il suo workspace AI invece di pagare ChatGPT Plus e Claude Pro, ha creato un unico strumento per la creazione contenuti invece di pagare Canva, generatori di immagini ed editor video separati.

Un ragazzo ha raccontato su LinkedIn come ha ricostruito uno dei tool SaaS core della sua azienda in 11 ore durante un weekend. Risparmio annuale: 72.000 dollari. E l’applicazione personalizzata non era solo più economica, ma era anche migliore perché costruita esattamente sulle loro esigenze.

I numeri di mercato confermano il trend. La spesa media SaaS per dipendente è salita a 4.830 dollari nel 2025, in aumento del 22% rispetto all’anno precedente. Ma il 42% delle organizzazioni ha ridotto la spesa SaaS per pressioni di budget. E McKinsey rileva che solo il 25% delle licenze SaaS acquistate viene effettivamente utilizzato in modo consistente.

Stiamo pagando per software che usiamo poco, con feature che non ci servono, a prezzi che aumentano ogni anno.

Quando ha senso costruire (e quando no)

Non tutto va costruito da zero. Io continuo a pagare Notion e Cal.com senza pensarci due volte.

Come decido cosa pagare? Ho un processo che uso anche con i clienti quando devono scegliere se comprare un SaaS o costruire internamente. Si divide in tre parti: prima i criteri bloccanti, poi i numeri, infine i fattori qualitativi che i numeri non catturano.

Parte 1: I criteri bloccanti

Alcune domande hanno risposta binaria. Se la risposta è sì, compra e non pensarci più.

Il tool gestisce pagamenti, dati sanitari o informazioni sensibili? Compra. La sicurezza e la compliance richiedono competenze e aggiornamenti continui che non puoi garantire da solo.

Hai bisogno di integrazioni con altri sistemi che usi quotidianamente? Compra. Ricostruire le API di Notion che si collegano a Slack, Calendar e altri 50 tool richiederebbe mesi.

Il tool è correlato al tuo core business e un’ora di downtime ti costa più dell’abbonamento annuale? Compra.

Se nessuno di questi criteri si applica, vai avanti.

Parte 2: Il calcolo del break-even

Prendi tre numeri:

1. Ore stimate per costruire un MVP funzionante

2. Ore stimate di manutenzione annuale (bug fix, aggiornamenti, piccole modifiche)

3. Il tuo costo orario reale (non quello che fatturi, quello che il tuo tempo vale per te)

La formula: (ore_build + ore_manutenzione_anno1) × costo_orario = costo_costruzione.

Se il costo di costruzione è inferiore a 2 anni di abbonamento, costruire ha senso economico.

Facciamo un esempio concreto con Shield: 4 ore di build + 2 ore stimate di manutenzione primo anno = 6 ore. Se valutiamo il mio tempo 120 euro/ora (è un esempio, fai il bravo/a) fanno 720 euro. Shield costa 166 euro/anno. Break-even in 4.3 anni. Numeri alla mano, non conviene.

Ma i numeri non raccontano tutto.

Parte 3: I fattori qualitativi

Il calcolo del break-even assume che il SaaS e la soluzione custom abbiano lo stesso valore. Spesso non è così.

Shield non mi permetteva di confrontare settimana su settimana.

Ogni volta che aprivo la dashboard perdevo 10 minuti a esportare dati e metterli in un foglio Excel. Sono 40 minuti al mese, 8 ore all’anno. A 120 euro/ora, 960 euro di tempo buttato. Aggiungi questo al calcolo e il break-even scende sotto l’anno.

Poi c’è la frustrazione. Ogni volta che un tool non fa quello che ti serve, perdi concentrazione. Ti arrabbi. Cerchi workaround. Questo costo non compare in nessun foglio Excel, ma esiste.

E infine c’è quello che io chiamo il “costo dell’attesa”: quanto tempo passi a sperare che il SaaS aggiunga quella feature che ti serve? Con Webflow ho aspettato due anni che il multi-lingua diventasse accessibile. Due anni di workaround e compromessi.

La sintesi

Quando valuto se costruire o comprare, seguo questa sequenza:

1. Criteri bloccanti? Se sì, compra.

2. Break-even sotto i 2 anni? Se no, probabilmente compra.

3. Ci sono fattori qualitativi che cambiano l’equazione? Feature mancanti che ti costano tempo ogni settimana? Frustrazione ricorrente? Se sì, riconsidera i numeri.

Cal.com passa tutti e tre i test dalla parte del “compra”: non ho bisogni specifici, il break-even sarebbe lunghissimo, non mi frustra mai.

Shield falliva su tutti e tre: nessun criterio bloccante, break-even accettabile considerando il tempo perso, frustrazione alta.

Costruire si è rivelata la scelta giusta.

Il vero cambiamento

Parliamoci chiaro, l’AI non ha reso obsoleti i SaaS, ma ha stimolato ancora di più il “make vs buy”.

Prima, costruirsi un tool interno richiedeva settimane di sviluppo, competenze specifiche, manutenzione continua. Il costo era quasi sempre superiore all’abbonamento.

Oggi, con con i vari agent, un developer può costruire in ore quello che prima richiedeva giorni. E anche chi non è developer può arrivare a risultati funzionanti per casi d’uso semplici.

Ma attenzione: questo funziona per tool interni e casi d’uso specifici. Il codice generato dall’ AI può essere buggato, insicuro e difficile da scalare. Va bene per una dashboard personale. Non va bene per un sistema di pagamenti ad esempio.

Klarna ha provato a sostituire Salesforce e Workday con soluzioni AI interne. I risultati iniziali sembravano fantastici: 40 milioni di dollari di risparmio annuale, tempi di risoluzione ticket ridotti da 11 a 2 minuti. Poi sono emersi i problemi e il CEO si è dichiarato “tremendamente imbarazzato”, al punto da fare marcia indietro.

L’AI è matura per sostituire tool semplici e specifici. Non è matura per sostituire sistemi enterprise complessi.

Quello che mi porto a casa

Dopo questa esperienza, ho cambiato il modo in cui guardo gli abbonamenti.

Prima rinnovavo tutto in automatico. Ora mi chiedo: questo tool fa qualcosa che non potrei farmi da solo in meno tempo di quanto costa l’abbonamento?

Questa esperienza ha cambiato il mio modo di guardare gli abbonamenti. Se prima rinnovavo tutto in automatico, ora mi domando: questo tool da qualcosa che non potrei farmi da solo e, proporzionalmente, in meno tempo di quanto costa l’abbonamento?

Per Shield, la risposta era no. 4 ore di lavoro per risparmiare 166 euro l’anno e avere un tool migliore. Il break-even è in meno di 1 anno e da lì in poi è tutto guadagno.

Per Notion, la risposta è sì. Costruirmi un’alternativa richiederebbe settimane, e il risultato sarebbe peggiore.

Il punto non è eliminare tutti i SaaS. È smettere di pagare per software che non usi come dovresti, solo perché “si è sempre fatto così”.

Quando un solo developer può costruire in un weekend quello che prima richiedeva un team, l’equazione economica cambia. E chi non se ne accorge continua a pagare per feature che non usa, in tool pensati per tutti tranne che per lui.

Il mio sito nuovo è online. La dashboard analytics funziona. E ho 788 euro in più all’anno da spendere in cose che contano davvero.

Ci vediamo alla prossima newsletter.

Senza filtri,
Chri

Nel momento dell’anno dei vari Spotify Wrapped ho deciso di raccontare tutto il mio 2025.

In questo articolo ti voglio mostrare tutto il mio 2025 facendolo come mi riesce meglio: con i numeri. Ti dirò cosa è andato bene, cosa è andato male e cosa mi aspetto dal 2026 (tipo letterina di babbo natale, ma senza regali).

Ti anticipo già che nessuna call mi ha cambiato la vita, nessun cliente mi ha fatto saltare dalla sedia e nessun post virale ha svoltato tutto.

Eppure, guardando i numeri che ho davanti, realizzo che questo è stato l’anno più importante della mia vita. Sia dal punto di vista professionale che privato.

Il 2025 è stato il mio primo anno completo da solo come SRL, diciamo il mio primo bilancio vero dopo quasi quattro anni di lavoro indipendente. Ah e nel frattempo è nata pure la mia prima figlia.

“Gli occhi chico, non mentono mai” — diceva Tony Montana. Ecco, io invece dico sempre: “I numeri chico, non mentono mai”.

E a me questi numeri piacciono.

I numeri del mio business

Va che curiosone/a che sei. Vabbè non mi dilungo anche perché so che è quello che vuoi sapere.

Clienti: 12 clienti attivi nel 2025. Di questi, 5 nuovi e 7 rinnovi. Un tasso di retention che mi fa capire che qualcosa sta funzionando nel modo in cui lavoro.

Discovery call: 48 in totale durante l’anno. Di queste, 3 si sono trasformate in clienti completamente inbound. 25 non sono andate avanti. 13 non erano in target.

Da dove arrivano: Il mio business oggi gira per un 70% da referral e un 30% da inbound. I referral non li traccio perché arrivano in modo organico, ma sono la spina dorsale di tutto. L’inbound arriva principalmente da LinkedIn.

Ore lavorate: 1520 ore fatturate in tutto l’anno. Mi sono preso diversi momenti di pausa, soprattutto dopo la nascita di mia figlia.

Margine: 22% netto, dopo tasse, costi dei collaboratori e il mio stipendio. Il margine è già al netto di quello che mi pago ogni mese.

ROI del marketing: Investo 4 ore a settimana sui contenuti, con il supporto di Veronica e Marco che mi danno una mano nella gestione. I costi di marketing li avrei coperti con un solo nuovo cliente inbound. Quest’anno ne ho chiusi 3. Il conto torna.

Ah, pensavi ti dicessi quanto ho fatturato?

I contenuti: il secondo lavoro che mi piace di più

In questi giorni chissà quante volte avrai letto che essere presenti è fondamentale e magari chi lo scrive allega anche risultati flexati manco fosse Fabrizio Corona. Io però voglio approcciare alla cosa in maniera diversa, altrimenti rischierei di sminuire ciò che per me, nel mio caso specifico, è in tutti i sensi un secondo lavoro.

Quattro ore a settimana. Ogni settimana. Per un anno intero. Senza mai una pausa.

Totale: 208 ore. 26 giorni lavorativi.

Questo è quanto ho lavorato sui contenuti quest’anno. Questo è il tipo di investimento, non di costo, che c’è dietro ai numeri che leggi qui sotto. E non l’ho fatto da solo: Veronica e Marco (angeli custodi ormai) mi hanno supportato nella gestione e senza di loro sarebbe stato difficile mantenere questa costanza.

A questo aggiungo le interviste e i workshop che ho fatto durante l’anno. Uno in particolare: con Factanza Academy, dove ho raccontato come uso l’intelligenza artificiale per creare contenuti. Uscire dalla mia bolla e parlare a pubblici differenti è stato parte dell’investimento.

Ora arriva la ciccia.

LinkedIn:

• Follower: da 9.327 a 11.728 (superata la soglia dei 10k → ho fatto anche un video per questo)

• Post pubblicati: 190

• Impression totali: 2.8 milioni (+100% rispetto al 2024)

• Engagement: 0.9%

• Commenti: 4.100

• Reaction: 18.400

• Repost: 285

• Visitatori del mio profilo: 10988

Per dare un contesto a questi numeri: se avessi voluto comprare 2.8 milioni di impression su LinkedIn con advertising, a un CPM medio di 35 euro, avrei speso circa 100.000 euro. Le ho ottenute con 208 ore di lavoro e zero budget pubblicitario. Non per dire che la pubblicità non serva, ma per far capire il valore reale di quello che molti liquidano come “fare un post”.

Newsletter:

Progetto più figo di quest’anno secondo me. Ho ritrovato una voglia di condividere che avevo perso grazie alla newsletter. Su questo ci farò un articolo e se non non l’hai ancora fatto… iscriviti.

• Articoli pubblicati: 18

• Iscritti: 262

La cosa che ho imparato è che i contenuti che funzionano non sono quelli dove insegno qualcosa. Sono quelli dove racconto come io faccio le cose. Nessuna lezione, nessun “dovresti fare così”. Solo la mia esperienza, raccontata per quello che è.

I contenuti che hanno funzionato di meno sono stati quelli più tecnici, dove davo valore oggettivo, ma non parlavo delle difficoltà che incontra chi mi legge. Erano troppo distanti dal problema reale.

Un’altra cosa che ho notato: se ti lamenti sui social, l’attenzione arriva. Ma attenzione e valore sono due cose diverse. Io preferisco avere meno attenzione e più valore.

Non tutto è andato rose e fiori

Quest’anno ho perso due clienti.

Non per mancanza di lavoro, non per problemi di budget. Li ho persi perché ho sbagliato io.

L’idea era semplice: delegare di più per prendere più clienti. Avevo collaboratori esperti, persone con cui avevo già lavorato e di cui mi fidavo. In un caso ho delegato la parte tecnica, nell’altro la parte di prodotto e design.

Il piano sembrava solido: io seguo la relazione col cliente, loro eseguono. Ogni tanto controllo che tutto stia andando nella direzione giusta.

Il problema è che “ogni tanto” non basta.

Mi sono accorto troppo tardi che le aspettative si erano disallineate. Il cliente si aspettava una cosa, il progetto stava andando da un’altra parte. Quando me ne sono reso conto, ho provato a correggere il tiro, ma era troppo tardi.

La fiducia, una volta persa, è difficile da riconquistare.

La lezione che mi sono portato a casa è che puoi delegare l’execution, ma non la relazione e il controllo strategico, perché la mia presenza per il cliente non è un optional ed è importante. Alla fine è il prodotto stesso.

Non si trattava di controllare i miei collaboratori, mi fido ciecamente di loro. Si trattava di mantenere l’allineamento sui requisiti, di essere presente quando le aspettative iniziano a divergere e di accorgemene prima che sia troppo tardi.

Quindi, dopo questa esperienza ho ripensato il mio modo di lavorare: cerco di essere più presente nelle fasi di interfaccia col cliente, e uso l’intelligenza artificiale per essere più operativo e coinvolto nelle diverse fasi di progetto, andando a recuperare il tempo di cui ho bisogno. Non per fare di più, ma per farlo meglio.

Le relazioni e il personal brand

Quest’anno ho fatto 30 networking call.

Nessuna di queste ha portato un cliente diretto. Zero.

Ma non è quello il punto.

Il ROI sul networking non si misura in deal chiusi. Si misura in riconoscibilità, in fiducia costruita, in opportunità che arriveranno tra sei mesi o un anno.

Quello che sta succedendo è che le persone iniziano ad associare “Fractional CTO” al mio nome. Quando qualcuno ha bisogno di questa figura, pensa a me. Non perché ho fatto pubblicità, ma perché mi hanno visto, mi hanno parlato, sanno chi sono.

Le networking call alimentano il referral anche quando non portano business immediato. Ogni conversazione è un seme. Alcuni germogliano subito, altri ci mettono tempo.

Continuo a farle, non ho tanto spazio nel calendario, ma le voglio fare. Perché mi piace essere d’aiuto alle persone che mi scrivono e perché non sempre è necessario fare qualcosa per ricevere altro in cambio.

Come è cambiato tutto con lei 💖

Da quando è nata mia figlia, le mie scelte di business sono cambiate.

Non in modo drammatico, alla fine non ho rivoluzionato niente. Ho dovuto, però, incastrare la mia vita in modo diverso.

Prima se c’era una cosa da fare nel weekend la facevo, adesso mi impongo di non lavorare. prima staccavo quando finivo il lavoro, adesso stacco perché… devo staccare.

La disciplina che ho costruito negli anni mi sta permettendo di ritagliarmi spazio per lei. Il mio lavoro e la mia vita sono diventati una cosa sola da gestire insieme, non due mondi separati che si rubano tempo a vicenda.

Prima la mia vita girava intorno al lavoro. Adesso c’è equilibrio.

E questa è probabilmente la cosa di cui sono più orgoglioso di tutto il 2025.

Il collaboratore svizzero

C’è un’altra cosa che ha cambiato il mio 2025: l’intelligenza artificiale.

Non come hype, non perché è diventata una buzzword, ma perché è uno strumento di lavoro quotidiano.

L’AI è diventata il mio collaboratore silenzioso. Mi accompagna nello sviluppo, nella strategia, nel brainstorming, nella creazione di contenuti.

(Non sostituisce niente, ma amplifica tutto).

Il boost non è stato solo sulla produttività, ma sulla qualità. Riesco a fare cose che prima non avrei avuto tempo di fare bene.

Lavorare senza intelligenza artificiale oggi sarebbe fare un passo indietro. Non è più un optional, è parte del mio modo di operare.

Se vuoi sapere come uso l’AI nel mio lavoro quotidiano, scrivimi. Sto pensando di creare contenuti dedicati a questo tema.

Ma intanto lunga vita a Claude.

Il mercato e cosa mi spaventa

Nel 2025 ho visto il mercato del Fractional CTO crescere.

Tante persone mi hanno scritto per capire come entrare in questo mondo. Le startup cominciano a capire cosa fa un Fractional e perché ha senso. Anche gli investitori hanno cambiato prospettiva: avere figure Fractional in una startup non è più visto come un segnale negativo, ma come una scelta intelligente.

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.

Quello che mi entusiasma è che l’AI potrebbe rendere il modello Fractional ancora più percorribile. Se un singolo professionista può fare di più e meglio grazie a questi strumenti, il valore che porta aumenta (e non di poco)

Il 2026: meno, ma meglio

L’anno prossimo ho deciso di fare dei cambiamenti.

Cosa smetterò di fare:

Non accetterò più founder che vogliono costruire un MVP da zero senza aver validato niente. Prima devono testare l’idea con gli strumenti che esistono già. Poi, dopo aver raccolto un finanziamento anche minimo, possiamo lavorare insieme.

Ho cambiato target: mi concentro su startup che hanno già dei finanziamenti e possono investire seriamente sul prodotto, la tecnologia e il team.

Smetterò di delegare le cose sbagliate. La lezione dei due clienti persi è chiara.

Cosa farò diversamente:

Selezione più mirata dei clienti, così da ridurre i costi e aumentare i margini. Il fatturato potrebbe scendere, ma la proporzione dovrà rimanere la stessa.

L’obiettivo? porre il focus sulla qualità e non sulla quantità. Voglio lavorare meglio, non di più.

Il nuovo progetto:

Nel 2026 lancio il mio canale YouTube.

Questa è la prima volta che ne parlo pubblicamente.

Mi sono reso conto che creare contenuti è il mio secondo lavoro, ma è quello che mi piace di più fare. Condividere le mie esperienze è quello che mi dà la maggiore soddisfazione. Voglio avvicinarmi ancora di più alle persone e farlo tramite video è il passo successivo.

(Se vuoi iscriverti per non perderti il primo video questo è il link)

L’obiettivo per il 2026:

Ripetermi. Quest’anno è stato ottimo e l’obiettivo è fare altrettanto bene migliorando sulla qualità.

Il filo conduttore

Se dovessi riassumere il 2025 in una parola, sarebbe questa: costanza.

Non c’è stato un momento di svolta. Non c’è stato un colpo di fortuna. C’è stata disciplina e la capacità di continuare a fare le cose che funzionavano anche quando non vedevo risultati immediati.

Dopo quasi quattro anni di lavoro indipendente, posso dire che il sacrificio ha avuto senso.

Ho un’azienda che funziona. Ho una figlia bellissima. Ho un equilibrio che prima non avevo.

Scusa se è poco.

Ci vediamo alla prossima newsletter.

Senza filtri,
Chri