> ## Content Index > Fetch the complete content index at: https://www.marcosantonocito.com/llms.txt > Use this file to discover other available public pages before exploring further. # Build in Public #3 - URL: https://www.marcosantonocito.com/build-in-public-3/ - Published: 2026-01-01T17:31:00.000Z - Updated: 2026-09-02T09:47:11.000Z - Description: Dicembre 2025 - Author: Marco Santonocito - Tags: Build in Public, Leadership, AI Product Building, High Agency Nel [primo post di questa serie](https://www.marcosantonocito.com/build-in-public-1/) ho raccontato perché sono tornato a costruire. Nel [secondo](https://www.marcosantonocito.com/build-in-public-2/), come sto imparando a fermarmi. Questo dicembre la domanda cambia di nuovo: non più *quanto velocemente riesco a costruire*, ma come rendere il building **ripetibile e scalabile**. Un prodotto sta crescendo, un altro sta per uscire, e intorno ad Anapana si sta formando un micro team. Per la prima volta da quando ho lasciato il lavoro, la velocità non è il mio problema principale. Questo post è una fotografia di dove sono le cose a fine dicembre e di ciò che man mano sto scoprendo. ## Anapana: da catalogo a guida Anapana non è più nella fase del *"questo funziona?"*. Funziona, cresce, e questo cambia il tipo di decisioni da prendere. Questo mese non stiamo rincorrendo feature nuove; stiamo lavorando sulle fondamenta: analytics, streak basati sul tempo di pratica invece che sul completamento, integrazione con Apple Health, un miglior onboarding, e Anapana Wrapped, che sta dando una mano alla distribuzione organica. Prese da sole, nessuna di queste cose sposta l'ago. Insieme ci danno una cosa che prima non avevamo: contesto sui comportamenti degli utenti. E il contesto sta facendo emergere un problema che non stavamo cercando. La maggior parte degli utenti inizia con il programma **30 Giorni di Meditazione**. Lo completano, l'engagement è alto, tutto bene. Poi il programma finisce e si ritrovano davanti a più di **200 meditazioni**. Sulla carta è ciò che fa convertire l'utente, nella pratica è paralisi. Ce lo scrivono loro, con parole molto semplici: *"Non so cosa fare dopo".* Il contenuto non è il problema. Il problema è la scelta. Abbiamo costruito un catalogo, e gli utenti hanno bisogno di una guida. Per questo a gennaio arriva la **Meditazione del Giorno**: una Home centrata sull'oggi, con una sola proposta, al posto di una Home che mostra tutto quello che potresti fare. Meno opzioni visibili, più direzione. È un cambiamento di UX più che una feature: da *"ecco tutto quello che abbiamo"* a *"ecco cosa ti consigliamo di fare adesso"*. Se sei curioso di provare l'app (per ora solo in italiano 🇮🇹), la trovi qui: - [Anapana Studio per iPhone](https://apps.apple.com/it/app/anapana-studio/id6739505611?ref=marcosantonocito.com) - [Anapana Studio per Android](https://play.google.com/store/apps/details?id=it.anapana.app&hl=it&ref=marcosantonocito.com) ## Il problema degli utenti è anche il problema del team Mentre lavoriamo su questo, intorno ad Anapana si sta formando un micro team, e sento una tensione familiare. Non ancora caos, ma i primi segnali: il tipo di attrito che non rompe niente subito ma che, se lo lasci lì, erode piano velocità e fiducia. L'ho già visto. In molte aziende ho visto persone preparate e motivate bloccarsi non per mancanza di competenze, e nemmeno di autonomia, ma perché la direzione dai founder o dai manager non era abbastanza chiara. Le decisioni rallentavano, l'allineamento si spostava nelle riunioni, e l'agency si trasformava in permesso senza che nessuno lo avesse deciso. Il parallelismo mi è chiaro solo adesso che metto le due cose una accanto all'altra. Gli utenti hanno 200 meditazioni e non sanno quale scegliere. Il team ha autonomia e non sempre sa in che direzione usarla. In entrambi i casi manca la stessa cosa: **chiarezza**. > **Autonomia senza chiarezza non genera necessariamente agency. Può generare più ambiguità.** Quando manca la direzione, le persone non rallentano perché hanno poca libertà; rallentano perché l'ambiguità le costringe a fermarsi e chiedere cosa fare dopo. Esattamente come i nostri utenti alla fine dei 30 giorni. ### Perché stiamo formalizzando Vision, Mission e North Star Per questo questo mese mettiamo nero su bianco vision, mission e North Star di Anapana. Non come esercizio strategico, ma come strumento operativo: serve a permettere alle persone di prendere più decisioni da sole, senza chiedermi conferma ogni volta. Voglio che l'allineamento sia esplicito, non presunto; qualcosa di abbastanza stabile da poterlo usare per decidere. - **Vision:** *Rendere la mindfulness una skill quotidiana, pratica e accessibile a tutti. Non un lusso. Non un rituale da monaco. Un'abitudine per navigare il caos moderno.* - **Mission:** *Offrire strumenti guidati, personalizzati e accessibili per migliorare il benessere psicofisico, giorno dopo giorno.* - **North Star Metric:** *Utenti attivi giornalieri che completano almeno una azione.* Non riguarda il controllo. Riguarda liberare l'agency: se sai qual è la metrica che conta, molte discussioni non servono più, perché la risposta è già dentro la metrica. ![](https://storage.ghost.io/c/e0/d5/e0d59659-cf02-46e9-9ca9-5c5ae0a043c8/content/images/2026/08/image-26.png) Vision, mission e North Star di Anapana come le abbiamo formalizzate questo mese. ### La matrice Autonomia × Clarity Se metto insieme quello che vedo negli utenti e nel team, ne esce un framework semplice: due assi, autonomia e chiarezza, e quattro situazioni possibili. ![](https://storage.ghost.io/c/e0/d5/e0d59659-cf02-46e9-9ca9-5c5ae0a043c8/content/images/2026/09/matrice-autonomia-clarity.png) Gli utenti di Anapana dopo i 30 giorni sono nel quadrante in alto a sinistra: massima autonomia (200 tracce, scegli tu) e pochissima chiarezza. La Meditazione del Giorno non toglie autonomia, il catalogo resta lì; aggiunge chiarezza e li sposta a destra. Con il team sto facendo la stessa cosa, con strumenti diversi: vision, mission e una metrica invece di una Home. ## Coco: non un'app, un processo ripetibile Coco è quasi pronta al lancio. Ma la cosa più utile che mi sto portando a casa non è l'app: è il **processo** con cui la sto facendo. Sto usando Coco come campo di prova per consolidare un workflow end-to-end, dall'idea alla distribuzione, e dimostrare a me stesso che riesco a costruire app di qualità in poco tempo senza sacrificare chiarezza né qualità del codice. Se il processo regge, Coco sarà la prima di una serie di applicazioni. ![](https://storage.ghost.io/c/e0/d5/e0d59659-cf02-46e9-9ca9-5c5ae0a043c8/content/images/2026/08/image-27.png) Il workflow, spogliato dei tool, è questo: > **Problema → Ricerca → Definizione → Design → Build → Feedback → Monetizzazione** I tool cambiano ogni sei mesi; il sistema no. Oggi uso ChatGPT e PeterAI per la ricerca, Notion per raccogliere, Figma per il design e Cursor per il codice. Tra un anno saranno probabilmente altri, e il processo resterà lo stesso. La parte che conta davvero sono i vincoli che mi do in ogni fase, perché quasi tutti stanno *prima* del codice. 1. **Problema.** Parte sempre da qualcosa osservato nella vita reale. Da lì lo traduco in una o più ipotesi da verificare. 2. **Ricerca prima del codice.** Per Coco significa mappare i competitor su mobile e web, fare analisi approfondite con ChatGPT e PeterAI, e raccogliere tutto in un database Notion strutturato. Vincolo: non si scrive una riga di codice finché questa fase non è chiusa. 3. **Definizione.** Gli insight della ricerca alimentano una prima bozza di MVP, con ChatGPT. Non come spec da seguire ciecamente, ma come modo per mettere sotto pressione le assunzioni in anticipo. 4. **Design.** In Figma definisco le schermate principali e un design system leggero. L'obiettivo è la consistenza, non la perfezione. 5. **Build.** In Cursor, con una sequenza fissa: prima i componenti del design system uno per uno, poi le pagine assemblate con quei componenti, infine le funzionalità core (backend e mobile). 6. **Feedback.** TestFlight presto, con persone che possano testare da subito l'applicazione. Vincolo: la beta esce prima che l'app mi sembri "finita". 7. **Monetizzazione.** Paywall il prima possibile, per capire subito se qualcuno è disposto a pagare. Se guardi la lista, il codice arriva al quinto passaggio su sette. È il punto: **AI-native building non vuol dire "prompt → app"**. Vuol dire ridurre l'ambiguità prima dell'execution, così che quando apri Cursor sai già cosa stai costruendo e perché. È la stessa lezione di Anapana vista dall'altra parte: più la capacità di eseguire cresce, più contano le decisioni prese prima. ## Snapshot di fine dicembre Ecco un'istantanea trasparente di dove sono le cose: - **Anapana:** 24.981 utenti registrati. - **Coco:** €0\. Non ancora lanciato. - **BabyTales:** €0\. Ancora bloccato da un problema irrisolto con l'azienda di stampa. - **HeyBloom:** ancora in modalità privata. **One Million Goal (fatturato a oggi): €220.069,80** **Questa newsletter** ha 471 iscritti totali (+77 questo mese). ❗ ***Nota:** *il contatore qui sopra è quello pubblicato a dicembre 2025 e lo lascio com'era. All'epoca includeva l'exit di Ammesso; in seguito ho cambiato il modo in cui calcolo One Million Goal, quindi i numeri delle edizioni successive non sono direttamente confrontabili con questo.* ## Cosa mi porto a casa Questa serie sta prendendo una progressione che non avevo pianificato. Nel #1 sono tornato a costruire. Nel #2 ho imparato a fermarmi. Nel #3 inizio a costruire un sistema e a dare chiarezza a chi ci lavora dentro, utenti compresi. La scoperta del mese è questa: **più aumenta la capacità di execution, più diventano importanti direction, context e judgment.** L'AI, un buon processo e un team piccolo e autonomo ti permettono di costruire molto e in fretta; ma se la direzione non è chiara, tutta quella capacità produce ambiguità, in una Home con 200 opzioni come in un team che aspetta conferme. La velocità non è il collo di bottiglia. Lo è la chiarezza. In molti modi questa riflessione riguarda anche me. Dopo anni da CPTO, essere di nuovo completamente hands-on mi ricorda quanto costa il disallineamento, e quanto può fare la differenza una direzione scritta bene una volta sola. Se anche tu lavori con un team piccolo, o costruisci da solo con l'AI, fatti questa domanda: le persone (o tu stesso) sanno cosa fare senza chiedere? Se la risposta è no, il problema probabilmente non è l'autonomia. --- **Letto a dicembre:** *La fine è il mio inizio* (Tiziano Terzani), *The Science of Meditation* (Daniel Goleman), *Il Coach da un Trilione di Dollari* (Schmidt, Rosenberg, Eagle), *Let My People Go Surfing* (Yvon Chouinard), *Tools of Titans* (Tim Ferriss) e, fuori categoria, il manga *Blue Giant* (Shinichi Ishizuka). --- Buon Natale, Marco