Da proto a produzione: Seantral su dominio e backend suoi
· 8 min · seantral, migrazione, agentic-coding, supabase, produzione
La prima app del lab a completare il ciclo: nata sul backend condiviso, oggi vive su dominio e backend suoi. Il workflow agentico che l’ha portata lì, fase per fase, ora è parte del metodo.
Seantral è nata qui dentro come prototipo: la mappa del mare italiano, ora per ora, appoggiata alla stessa base che regge tutto il resto del lab. Account condivisi, backend condiviso, mail firmate RiftSeed. Per un prototipo va benissimo, ed è il motivo per cui i prototipi qui nascono in giorni e non in mesi. Poi un prototipo inizia ad avere utenti veri, un dominio suo, richieste sue. E a quel punto la base condivisa smette di essere un regalo e diventa un debito: ogni cosa che tocchi per l’uno rischia di toccare l’altro.
A fine agosto il passaggio si è chiuso: Seantral oggi gira su un backend interamente suo, con i suoi account, le sue mail, il suo accesso Google, perfino le tile della mappa servite dal suo dominio. L’app resta in alfa, e lo dice a schermo: i punteggi si stanno ancora misurando contro il mare vero. Ma l’ambiente adesso è produzione esterna, staccata dal laboratorio, e continua a camminare da sola. È la prima volta che il ciclo intero del lab, da seme a produzione, si chiude davvero.
Il workflow, fase per fase
La migrazione è stata un workflow eseguito da agenti AI, con una persona sui cancelli. Prima fase, misurare l’accoppiamento: quante tabelle sono dell’app, quante righe dell’app vivono dentro tabelle condivise, e dove stanno le saldature vere (identità, infrastruttura, console). Seconda, costruire il progetto dedicato: schema estratto e riapplicato, gli account veri migrati con l’API ufficiale (id e password conservati: nessuno ha dovuto rifare niente), dati copiati con gli id preservati, storage trasferito con le sue policy.
Terza fase, l’identità esterna: dominio mail dedicato, template riscritti col marchio giusto e provati vivi (una mail esiste solo quando è arrivata), accesso Google con un progetto suo. Quarta, il cancello: parità dei dati verificata tabella per tabella nei due sensi, e un collaudo comparativo: la stessa suite di utenti simulati, centoventitré verifiche, eseguita contro il vecchio e contro il nuovo la stessa sera. Solo i rossi esclusivi del nuovo contano come regressioni. Quella sera erano zero.
Il taglio è un cambio di chiavi
La scelta che ha reso tutto reversibile era stata fatta mesi prima, senza saperlo: il client legge indirizzo e chiave del backend dall’ambiente di build. Così il taglio vero è consistito nel cambiare due secret nella pipeline e fare un deploy. Se qualcosa fosse andato storto, tornare indietro sarebbe stato lo stesso gesto al contrario. Niente down, niente finestra di manutenzione: gli utenti non si sono accorti di nulla, che è la definizione di un taglio riuscito.
La parte che ha insegnato di più è venuta dopo il primo deploy: un’origine che serve due domini rende invisibile ogni indirizzo scritto a mano nelle funzioni server e nell’HTML. Il bundle era pulito, ma la sitemap, le pagine per i motori, il proxy delle condivisioni e il beacon di avvio parlavano ancora col backend vecchio. Si trovano in un modo solo: interrogando il prodotto servito, non il codice. Ora ogni superficie sceglie il backend dal dominio che la sta servendo, con un resolver unico.
Spegnere il vecchio, nell’ordine giusto
L’ultima fase è quella che di solito si rimanda per sempre: togliere l’app dal posto dove è nata. L’ordine è rigido e va rispettato: prima un archivio locale verificato coi conteggi (e qui la lezione più umile del progetto: il backup automatico su cui si contava non era mai partito, per un secret mai impostato); poi le porte, cioè ogni vecchio indirizzo che risponde con un redirect permanente conservando il percorso, widget incorporati compresi; poi le parti in movimento, cron e funzioni; i dati per ultimi. Gli account condivisi non si toccano: sono utenti anche del resto.
Cosa resta al metodo
Il valore vero della settimana è che il trasloco ora è un playbook. Le fasi, le trappole già pagate, le dieci lezioni scritte in forma riusabile, tutto è registrato nello spazio del progetto e nella documentazione del lab. La prossima app che dovrà graduare non riscoprirà niente: aprirà il documento ed eseguirà. È questo il patto del lab con l’AI: gli agenti fanno il lavoro, l’umano decide sui cancelli, e ogni cosa imparata diventa struttura per la volta dopo.
Seantral intanto è viva su seantral.com, in alfa dichiarata, coi suoi utenti veri e i suoi duecentoventisette punti di costa aggiornati ogni ora. Se vi va di vedere com’è un prototipo diventato grande, è lì.