Newsletter sotto controllo: perché vale la pena farla da te (e come iniziare)

Il cimitero delle piattaforme per newsletter

Ricordi Tinyletter? Se scrivevi nel 2020, probabilmente sì. Era semplice, pulito, e faceva solo una cosa: mandare le tue email. Niente funnel, niente grafici, niente ottimizzazioni.

Poi è sparito.

Quando Mailchimp lo ha chiuso a febbraio 2024, è emerso un problema ormai noto nel mondo SaaS: se non paghi per il servizio o non sei il cliente principale, il tuo tool può sparire da un giorno all'altro.

Questa storia si ripete. E molti creator indipendenti stanno reagendo nello stesso modo: portando la newsletter su infrastrutture proprie.

Il problema dei servizi esterni

Delegare a un servizio terzo ha un senso pratico. Non devi configurare SPF, DKIM, DMARC, né gestire bounce e reputazione del mittente. Qualcun altro si occupa della deliverability.

Però c’è un prezzo nascosto.

Queste piattaforme sono pensate per marketer, non per chi scrive. I template, i pixel di tracciamento e le metriche di engagement servono a misurare conversioni, non a capire se qualcuno ha letto davvero. E quando il tuo caso d’uso non rientra più nel loro target, diventi un problema secondario.

Il punto più critico è un altro: non controlli il tuo pubblico. Se la piattaforma cambia rotta, perdi tutto.

L’approccio self-hosted

Gestire la propria newsletter non significa diventare un sistemista. Significa scegliere infrastrutture stabili e mantenere il controllo.

Il modello attuale si basa su pochi elementi:

Versionamento del contenuto: ogni numero è un file markdown dentro un repository Git. Niente database chiusi, solo file e configurazioni dichiarative.

Invio via API: non serve una dashboard marketing. Basta un servizio con API pulita. Postmark, Resend, SendGrid o Mailgun gestiscono autenticazione, bounce e conformità. Tu passi la lista e il testo, il resto lo fanno loro.

Flussi da terminale: puoi creare un piccolo script che vive nel tuo repo. Legge il markdown, prepara l’email, gestisce gli iscritti e chiama il servizio di invio. Niente interfacce web, solo codice e terminale.

Estetica essenziale: una mail in testo semplice o con un HTML minimale spesso funziona meglio di template complessi. Il contenuto resta al centro.

Come è fatta in pratica

Una struttura tipica potrebbe essere questa:

newsletter/
├── issues/              # Un file .md per numero
│   ├── 1.md
│   ├── 2.md
│   └── 3.md
├── subscribers.csv      # Elenco iscritti
├── send/                # Script di invio
│   ├── send.py
│   └── config.yaml
├── web/                 # Endpoint per iscrizioni
│   └── subscribe.py
└── .github/workflows/   # Automazioni
    └── backup.yaml

Tutto è portabile. Cambi servizio di invio? Modifichi una riga. Vuoi aggiungere RSS o condivisione automatica? Lo fai nel tuo codice.

La questione della deliverability

Mandare email senza finire nello spam richiede SPF, DKIM e DMARC. Sembra complicato, ma i servizi di invio gestiscono già questa parte. Mantengono la reputazione del mittente e filtrano i bounce. Tu deleg<|eos|>