> ## 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-08-31T16:31:19.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 una scoperta che sto facendo due volte nello stesso mese, in due prodotti diversi, guardando due problemi che sembrano non c'entrare niente l'uno con l'altro.

## 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 più profonde, streak basati sul tempo di pratica invece che sul completamento binario, integrazione con Apple Health, un onboarding che chiede obiettivi ed esigenze, e Anapana Wrapped, che sta dando una mano alla distribuzione organica. Presa da sola, nessuna di queste cose sposta l'ago. Insieme ci danno una cosa che prima non avevamo: contesto sui comportamenti reali 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 è abbondanza; 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 chiara, al posto di una Home che mostra tutto quello che potresti fare. Meno opzioni visibili, più direzione. È un cambio di postura 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)

Prendi la trial di 7 giorni, vedi come ti senti con la pratica, e se hai qualsiasi feedback mandamelo: ci aiuta tantissimo.

## 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 e che però, se lo lasci lì, erode piano velocità e fiducia.

L'ho già visto. In molte aziende ho visto persone intelligenti 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à.**

È la frase più importante di questo post, e ci arrivo osservando, non leggendo. 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 da slide, 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 consapevole.*

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.

*\[Nota per l'editor: inserire qui il nuovo visual concettuale, matrice 2×2 Autonomia (bassa/alta) × Clarity (bassa/alta). Alt text suggerito: "Matrice 2x2 con autonomia bassa e alta sulle righe e clarity bassa e alta sulle colonne; il quadrante alta autonomia e alta clarity è etichettato High Agency". La tabella sotto è il contenuto del visual e può restare come fallback testuale.\]*

|                     | **Clarity bassa**                             | **Clarity alta**                                   |
| ------------------- | --------------------------------------------- | -------------------------------------------------- |
| **Autonomia alta**  | Ambiguità: tante opzioni, decisioni rimandate | **High Agency**                                    |
| **Autonomia bassa** | Blocco: si aspetta il permesso                | Esecuzione guidata: si fa, ma decide qualcun altro |

*L'agency vive nel quadrante in alto a destra. L'autonomia da sola ti porta a sinistra, nell'ambiguità.*

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 deliberato 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 è la prima di una serie, non un caso isolato.

![](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, non da un'idea trovata su un foglio. 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, di nuovo con ChatGPT. Non come spec da seguire ciecamente, ma come modo per mettere sotto pressione le assunzioni in anticipo. Vincolo: MVP ridotto all'osso, tutto il resto va in backlog.
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 ti dicono la verità. 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.

Il processo è abbastanza solido da meritare un post dedicato, con prompt, tool e template Notion. Arriverà.

## 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 aggiunta in seguito: 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 dopo 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*](https://www.marcosantonocito.com/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). Le note complete le trovi nella sezione Libri del sito.

*Impossibile? Forse... o forse no.*

Marco