Per molto tempo abbiamo pensato al CMS come al luogo in cui creare una pagina, modificare un testo, caricare un'immagine e pubblicare un contenuto. Poi sono arrivati gli headless CMS, che hanno separato la gestione dei contenuti dal modo in cui questi vengono presentati sul frontend.
Oggi stiamo entrando in una fase ulteriore. Siti, ecommerce e piattaforme digitali sono sempre più composti da servizi diversi, integrano dati provenienti da più fonti e devono essere in grado di alimentare non soltanto pagine web, ma applicazioni, aree riservate, configuratori e nuove esperienze basate sull'intelligenza artificiale.
In questo scenario diventa interessante osservare l'evoluzione di Payload, progetto open source nato come headless CMS e oggi definito dai suoi stessi sviluppatori un full-stack framework per Next.js.
Non è soltanto una questione di definizioni. Dietro questo cambiamento c'è un modo differente di intendere il ruolo del CMS all'interno di un progetto digitale.
Da gestore di contenuti a componente dell'architettura digitale
L'idea alla base di un CMS tradizionale è relativamente semplice: esiste un sistema che gestisce i contenuti e genera le pagine attraverso cui questi vengono pubblicati.
Con l'headless questo legame viene spezzato. Il CMS gestisce contenuti e dati, mentre uno o più frontend li recuperano attraverso API e decidono come presentarli.
Payload parte da questa impostazione, ma con la versione 3.0 ha fatto un passo ulteriore: è diventato nativo Next.js e può essere installato direttamente all'interno di un'applicazione Next.js. Backend, Admin Panel e frontend possono quindi vivere nella stessa codebase, senza rinunciare alla separazione logica tra i diversi livelli dell'applicazione.
Scrivendo una configurazione in TypeScript, Payload mette a disposizione automaticamente un'interfaccia di amministrazione, database e migrazioni, API REST e GraphQL, autenticazione, sistemi di access control, gestione dei file e live preview.
Questo cambia il punto di vista.
Il CMS non viene più necessariamente aggiunto a valle di un progetto per permettere a qualcuno di modificare le pagine. Può diventare fin dall'inizio una delle fondamenta applicative della piattaforma.
È una distinzione importante soprattutto quando ciò che stiamo costruendo non è semplicemente un sito, ma un ecosistema digitale destinato a evolvere nel tempo.
Il contenuto non coincide più con la pagina
Un'altra conseguenza riguarda il modo in cui pensiamo ai contenuti.
Titolo, descrizione, immagini, informazioni di prodotto, documenti, caratteristiche tecniche, FAQ o informazioni relative a un servizio non devono necessariamente appartenere a una singola pagina web.
Possono essere modellati come dati strutturati e utilizzati ogni volta che servono.
Lo stesso contenuto può alimentare una pagina del sito, un'applicazione, un ecommerce, un'area riservata, un configuratore o un altro servizio digitale.
È uno dei principi alla base delle architetture headless e composable, ma assume ancora più rilevanza quando un progetto deve gestire molti mercati, lingue, touchpoint o integrazioni.
Payload permette di definire liberamente il proprio modello dati e supporta nativamente funzionalità editoriali come versioning, draft, autosave, pubblicazione programmata, localizzazione e live preview.
Questa combinazione è significativa perché mette insieme due esigenze che talvolta vengono considerate contrapposte: flessibilità per chi sviluppa e strumenti utilizzabili da chi gestisce quotidianamente i contenuti.
Non si tratta quindi di rinunciare all'esperienza editoriale in nome di un'architettura più tecnica. Si tratta piuttosto di costruirla intorno alle caratteristiche reali del progetto.
Un backend che può adattarsi al progetto
Payload non impone neppure un'unica scelta per il database.
L'architettura utilizza adapter e supporta ufficialmente MongoDB, PostgreSQL e SQLite, lasciando quindi al progetto la possibilità di scegliere tra modelli documentali e relazionali sulla base dei requisiti applicativi.
Lo stesso principio di flessibilità riguarda l'accesso alle informazioni.
I permessi possono essere gestiti in maniera granulare in funzione dell'utente, del ruolo, dell'operazione, del documento e perfino del singolo campo. Le stesse regole governano sia le API sia ciò che viene mostrato nell'Admin Panel.
Diventa così possibile gestire all'interno della stessa architettura contenuti pubblici e riservati, differenti ruoli organizzativi, utenti appartenenti a organizzazioni diverse o informazioni accessibili soltanto in determinati contesti.
Sono caratteristiche che spostano ulteriormente Payload fuori dal perimetro del semplice publishing e lo avvicinano alla costruzione di portali, extranet, applicazioni e piattaforme digitali complesse.
E quando il CMS deve parlare con l'AI?
È qui che il cambiamento diventa ancora più interessante.
L'intelligenza artificiale sta modificando anche il modo in cui i contenuti vengono utilizzati.
Finora abbiamo progettato CMS principalmente pensando a due interlocutori: chi inserisce il contenuto e chi lo consulta attraverso un'interfaccia.
Ora ne compare un terzo: l'AI.
Assistenti, agenti e applicazioni basate sui Large Language Model devono poter accedere alle informazioni aziendali, comprenderne la struttura e utilizzarle in modo controllato.
Non significa semplicemente aggiungere un pulsante “Genera con AI” nell'editor.
Significa rendere contenuti e dati interrogabili e utilizzabili da sistemi intelligenti, mantenendo però regole di accesso, governance e controllo.
Payload ha introdotto un plugin ufficiale per MCP, Model Context Protocol, lo standard che permette alle applicazioni AI di collegarsi in modo strutturato a fonti dati e strumenti esterni.
Attraverso il plugin è possibile decidere quali operazioni rendere disponibili via MCP sulle diverse collection: ricerca, creazione, modifica o eliminazione dei contenuti. È inoltre possibile definire tool, prompt e resource personalizzate, mentre continuano ad applicarsi le regole di accesso configurate nel CMS.
Il passaggio concettuale è importante.
Un agente potrebbe non limitarsi a ricevere un testo incollato all'interno di una conversazione. Potrebbe interrogare direttamente le informazioni autorizzate presenti nel CMS, recuperare dati strutturati o eseguire determinate operazioni sulla piattaforma.
Il CMS diventa così uno dei possibili punti di connessione tra conoscenza aziendale, applicazioni e agenti AI.
È una direzione particolarmente rilevante pensando a come stanno evolvendo siti e piattaforme digitali: da ambienti che aspettano che l'utente navighi tra menu e pagine ad ambienti capaci di interpretare richieste, recuperare informazioni e costruire risposte o esperienze più pertinenti.
L'AI non sostituisce quindi il CMS. Al contrario, rende ancora più importante avere informazioni ben strutturate, governate e accessibili attraverso interfacce affidabili.
Figma e Payload: un altro confine che si sta riducendo
C'è poi un passaggio recente che aiuta a leggere questa evoluzione da una prospettiva ancora più ampia.
Nel giugno 2025 il team di Payload è entrato in Figma. L'annuncio non è interessante soltanto per le due aziende coinvolte, ma per ciò che racconta sull'evoluzione del processo con cui vengono costruiti prodotti ed esperienze digitali.
Figma è anche uno degli ambienti che utilizziamo quotidianamente nella progettazione delle esperienze digitali. Payload interviene invece sul versante dello sviluppo, dei dati e della gestione dei contenuti.
Storicamente tra questi mondi esiste una discontinuità.
Il designer costruisce un'interfaccia. Lo sviluppatore la traduce in codice. Il CMS viene configurato per renderla gestibile. Infine il team editoriale deve inserire e aggiornare i contenuti all'interno della struttura costruita.
Lo stesso James Mikrut, fondatore di Payload, ha individuato proprio nel divario tra design, codice e content management uno dei problemi che la collaborazione con Figma può contribuire ad affrontare. Payload ha inoltre confermato che il progetto continuerà a essere open source e self-hostable.
Non sappiamo ancora quali saranno tutte le conseguenze concrete di questa integrazione, ed è presto per immaginare workflow che oggi non esistono, ma la direzione è significativa.
Design system, componenti frontend, modelli di contenuto e strumenti editoriali stanno diventando parti sempre meno isolate dello stesso processo.
Anche in questo caso il tema non è soltanto Payload. È il progressivo superamento dei confini tra gli strumenti con cui progettiamo, sviluppiamo e gestiamo un'esperienza digitale.
Open source significa anche ownership
Payload aggiunge un'altra caratteristica importante a questo scenario: il core è open source con licenza MIT. Il progetto può essere self-hosted e il codice può essere distribuito sull'infrastruttura scelta dall'organizzazione.
Anche questo aspetto merita di essere letto oltre la contrapposizione tra software open source e piattaforme SaaS.
Non esiste infatti una scelta universalmente migliore.
Il punto è capire quanto controllo vogliamo avere sull'architettura, sul dato, sulle integrazioni e sull'evoluzione futura di una piattaforma.
Per alcuni progetti la semplicità di un servizio completamente gestito rappresenta un vantaggio determinante. Per altri diventano prioritari la possibilità di intervenire sul codice, scegliere database e infrastruttura, integrare sistemi proprietari o ridurre la dipendenza da uno specifico vendor.
Payload appartiene chiaramente a questo secondo approccio.
È una scelta che richiede competenze tecniche e capacità di mantenere l'infrastruttura nel tempo, ma che offre in cambio un livello elevato di controllo.
Non serve un nuovo CMS. Serve capire cosa deve diventare la piattaforma
È forse questo l'aspetto più interessante di Payload.
La discussione non dovrebbe partire dalla domanda: “Qual è il CMS migliore?”
Dovrebbe partire da un'altra: “Che cosa dovrà essere in grado di fare questa piattaforma nei prossimi anni?”
Se dobbiamo realizzare un sito relativamente semplice, esistono molte soluzioni perfettamente adeguate e probabilmente più immediate.
Quando però aumentano integrazioni, mercati, lingue, servizi, ruoli, applicazioni e fonti dati, il problema cambia.
E cambia ulteriormente quando contenuti e informazioni devono poter essere utilizzati non soltanto dalle interfacce che conosciamo oggi, ma anche da nuovi touchpoint e sistemi AI.
In questi scenari il CMS smette progressivamente di essere un elemento separato dedicato alla pubblicazione.
Diventa content infrastructure: uno strato attraverso cui organizzare, governare e distribuire informazioni all'interno dell'ecosistema digitale.
È in questa prospettiva che Payload ci sembra particolarmente interessante.
Non perché renda improvvisamente superato il concetto di CMS, ma perché mostra bene come quel concetto stia evolvendo.
- Dal contenuto alla piattaforma.
- Dalla pagina al dato strutturato.
- Dal frontend unico a molteplici esperienze.
- Dall'interazione esclusivamente umana a quella tra persone, applicazioni e agenti AI.
Il futuro del CMS potrebbe quindi avere sempre meno a che fare con il semplice “gestire un sito”.
E sempre di più con il costruire l'infrastruttura informativa su cui quel sito (e tutto ciò che verrà dopo) potrà funzionare.