Perché superare Airtable
Creators Pro coordina la produzione di contenuti tra creator e team operativi: richieste, consegna dei media, editing, approvazione e preparazione alla pubblicazione. Airtable era stato utile per implementare i primi flussi e validarli con pochi utenti interni.
Con l’evoluzione delle richieste, le sue interfacce erano diventate un vincolo. Spesso trovare un modo per aggirarne i limiti richiedeva più lavoro della funzionalità stessa; anche ricostruire gli errori nel sistema che avevamo realizzato era difficile. Serviva maggiore controllo su dati, logica applicativa e interfacce, con una struttura adatta alla crescita del prodotto.
Dalla conoscenza del prodotto a React
Ho partecipato fin dall’inizio aiutando i colleghi a chiarire le logiche di prodotto: come lavoravano gli utenti, quali passaggi erano previsti e quali regole dell’app iOS e del flusso Airtable dovevano essere conservate.
Per contribuire anche al frontend ho scelto di imparare React, adattandomi allo stack già usato dal sito. Sono entrato progressivamente nello sviluppo web, inizialmente nelle viste di editing, sui filtri e sul raggruppamento delle clip. Ho lavorato anche alle API e all’evoluzione del modello dati del modulo.
Una transizione progressiva per i team
Il prodotto era ancora a uso interno. Abbiamo scelto di costruire il nuovo stack senza importare i dati storici di Airtable. Per un primo periodo entrambi i flussi sono rimasti attivi; i team sono passati alla nuova piattaforma progressivamente, attraverso onboarding.
Il modulo si è evoluto da Projects ed Edits verso Approvals e Vault, con adeguamenti alle Collections e l’introduzione di Requests. La crescita delle funzionalità richiedeva di mantenere riconoscibile il collegamento tra richiesta iniziale, media e lavorazioni successive.
Riorganizzare dati e lavorazioni
Nella riorganizzazione di luglio 2026 ho progettato e implementato in autonomia modello dati, API e interfacce di Edits, Approvals e Vault, insieme alle migrazioni PostgreSQL necessarie.
Ho introdotto un modello Asset condiviso per collegare i media sorgente e derivati alle richieste di produzione, editing e review. Le lavorazioni hanno acquisito entità e stati propri, mantenendo il riferimento alla richiesta e ai contenuti coinvolti.
Questa fase richiedeva di gestire anche dati già presenti nel nuovo sistema. Ho curato migrazioni e backfill per adeguare relazioni e stati al nuovo dominio. Era un’evoluzione della piattaforma PostgreSQL già in uso, successiva al passaggio da Airtable.
Le fasi della stessa richiesta
L’obiettivo dell’unificazione di Requests, Edits e Approvals era far percepire le attività come fasi della stessa richiesta. Gli utenti dovevano poter consultare i vari passaggi comodamente, conservando il contesto del contenuto. Tra gli obiettivi del prodotto c’era anche collegare i contenuti alle Social Metrics per valutarne le performance.
Il lead product designer ci ha fornito indicazioni chiare su UI, UX e obiettivo da raggiungere. Nel lavoro di squadra mi sono occupato del collegamento delle schermate di dettaglio e delle informazioni API necessarie a navigare tra le fasi.
Le API espongono la richiesta di origine, l’editing associato e lo stato delle approvazioni. Le interfacce possono così mostrare i passaggi previsti, quelli disponibili e quelli già completati, rispettando i permessi dell’utente.
Progettare il Planning con il team
Per il Planning il team aveva ricevuto un obiettivo da raggiungere. Forte della conoscenza del prodotto, ho studiato un’organizzazione dei dati, l’ho proposta ai colleghi e l’abbiamo affinata nel confronto. Ho poi comunicato al project manager le decisioni condivise.
Il modello prevede un template base per creator, personalizzazioni per account, ricorrenze settimanali ed eccezioni per date specifiche, con tipi e quantità di contenuti. L’implementazione iniziale è stata distribuita nel team: il mio contributo in questa fase è stato definire e discutere la proposta su dati e API.
Successivamente ho lavorato anche al collegamento dei contenuti del Vault con la pianificazione e al loro riutilizzo negli slot. Il percorso ha quindi collegato la struttura dei dati alle operazioni sui contenuti già disponibili.
Il risultato
Il lavoro ha accompagnato il passaggio progressivo dei team a una piattaforma con dati, API e interfacce gestiti dal team di sviluppo. Il modulo ha collegato le fasi di produzione e gestione dei contenuti, continuando a evolvere mentre veniva utilizzato.
Per me ha significato estendere il contributo dall’app iOS al prodotto web: prima mettendo a disposizione la conoscenza del dominio, poi intervenendo direttamente nello stack React e backend, fino alla progettazione e implementazione autonoma di una riorganizzazione trasversale.
Approfondimento tecnico
Lo schema mostra il percorso logico del contenuto. Le fasi di editing e approvazione dipendono dal workflow previsto per la richiesta.
- Richiesta e media
- Editing, se richiesto
- Approvazione, se richiesta
- Vault
- Planning
La richiesta resta il riferimento delle lavorazioni e dei media. Il Planning organizza il lavoro sui contenuti; il collegamento alle Social Metrics era un ulteriore obiettivo del prodotto.
Due transizioni distinte
Il passaggio da Airtable è avvenuto senza importarne i dati storici. Le migrazioni e i backfill di luglio riguardavano invece i dati già presenti in PostgreSQL e il loro adeguamento alle nuove entità di produzione, editing, review e media.
Media e lavorazioni
Il modello Asset condiviso collega sorgenti e derivati alla richiesta, all’editing, alla review e al contenuto da pubblicare. Gli eventi di approvazione conservano i riferimenti ai media coinvolti, mantenendo il contesto delle lavorazioni.
Compatibilità dei dati esistenti
Le migrazioni aggiornano nomi, relazioni e stati del dominio. Nei casi di contenuti già promossi collegati alle clip, il backfill mantiene le unità esistenti e ne riporta il riferimento alla richiesta padre; controlli espliciti fermano la migrazione quando i media appartengono a richieste incompatibili.
Navigazione guidata dallo stato
Il contratto workflowNavigation riunisce richiesta di origine, necessità di editing e approvazione, editing associato e conteggi delle review. Il frontend costruisce la navigazione dei dettagli da queste informazioni e dai permessi: le fasi non previste sono omesse e quelle non ancora disponibili non sono navigabili.
Regole del Planning
Un account usa il proprio template quando configurato; altrimenti eredita quello base della creator. Il modello distingue i giorni ricorrenti dalle eccezioni per data. I vincoli PostgreSQL gestiscono l’unicità dei template attivi e delle configurazioni giornaliere; le API espongono la configurazione effettiva per account.