Capitolo 1 – L’esigenza iniziale: velocizzare i POC
OpenGate nasce da un’esigenza concreta e operativa: accelerare la creazione di proof of concept (POC) per esperienze in realtà mista e aumentata. In un contesto di rapida sperimentazione, come quello di Metagate, ogni giorno era una corsa contro il tempo. Le idee erano tante, i dispositivi XR come Meta Quest 3 sempre più performanti, ma mancava uno strumento leggero, dinamico e centralizzato per orchestrare l’accesso ai contenuti e la gestione dei dati. L’obiettivo era chiaro: sviluppare più esperienze in meno tempo, con maggiore controllo e possibilità di iterazione.
In quel periodo, lo strumento più flessibile e immediato a disposizione era Google Sheets. Un foglio condiviso, aggiornabile in tempo reale e facilmente leggibile anche da Unity, era sufficiente per gestire i primi test con asset multimediali (immagini, 3D, suoni) e link dinamici. Bastava inserire un URL, aggiornare un parametro o cambiare una coordinata, e l’esperienza nel visore si adattava al volo. Una soluzione no-code che permetteva al team creativo e a chi sviluppava di lavorare insieme senza sovrastrutture.
Parallelamente, venivano sviluppate piccole API in Google Apps Script, direttamente legate ai fogli. Questi script permettevano di automatizzare la gestione delle righe, estrarre dati specifici, generare token d’accesso o addirittura modificare in tempo reale la configurazione di un’esperienza MR. Ogni API era un piccolo tool pensato per uno scopo specifico: un acceleratore per testare più velocemente una scena, un personaggio, una meccanica interattiva. Nacque così una micro-infrastruttura agile, leggera, ma incredibilmente potente.
Questo approccio, seppur nato come soluzione temporanea, si dimostrò subito efficace. Il team riusciva a gestire molteplici progetti XR contemporaneamente, con un setup centralizzato che permetteva di intervenire da remoto su esperienze già caricate nei visori. Bastava aprire un foglio e cambiare un valore per trasformare l’ambiente digitale in tempo reale. Per una startup come Metagate, sempre in movimento tra eventi, mostre e demo, questa elasticità era fondamentale.
Tuttavia, i limiti erano evidenti. L’approccio basato su Google Sheets non garantiva una vera scalabilità. Non esisteva un sistema strutturato per il controllo degli accessi, l’integrazione di avatar, la gestione di scene complesse o l’interoperabilità con le piattaforme NFT. Inoltre, il codice legato ai fogli era scritto in modo frammentario, spesso con soluzioni “vibe coding”, cioè rapide, creative, ma poco manutenibili nel lungo periodo.
Fu proprio in quel momento che nacque l’idea di trasformare quel sistema provvisorio in qualcosa di più solido, modulare e scalabile.
Capitolo 2 – I primi test con gli alpha tester
Con la micro-infrastruttura basata su Google Sheets e API funzionante, arrivò il momento di testare tutto sul campo. Fu così che coinvolgemmo i primi alpha tester: artisti, sviluppatori, curatori e utenti avanzati già vicini alla community di Metagate. L’obiettivo era capire se questo sistema leggero e dinamico potesse davvero semplificare la creazione e la fruizione di esperienze in realtà mista.
I feedback furono subito incoraggianti. Gli alpha tester apprezzarono la possibilità di modificare contenuti al volo, senza dover ricompilare il progetto Unity. Bastava aggiornare un link in un foglio, e l’esperienza nel visore si adattava in tempo reale. Questo aprì nuove possibilità sia per i workshop dal vivo che per i test pre-evento.
Alcuni utenti, senza alcuna esperienza di programmazione, riuscivano già a spawna-re asset 3D, immagini e video semplicemente incollando un link in una cella. L’aspetto no-code della soluzione si rivelò decisivo per favorire la collaborazione tra figure molto diverse.
In questa fase iniziale non c’era ancora una UI vera e propria: l’interfaccia era il foglio stesso. Ma fu sufficiente per far capire il potenziale dell’approccio. La sensazione era quella di aver trovato un modo nuovo, diretto e condiviso di comporre esperienze XR. L'allestimento dell'esperienza in mixed reality avveniva manualmente e fisicamente nel mondo reale! Un nuovo modo di intendere un "builder" a metà tra fisico e digitale in pieno stile mixed reality!
Questo entusiasmo diede la spinta decisiva per pensare a qualcosa di più strutturato. Il sistema funzionava, ma per evolversi doveva uscire dal foglio e diventare una vera piattaforma. OpenGate, ancora senza nome, stava per nascere davvero.
Capitolo 3 – GPT-o3, vibe coding e le vacanze di Natale
Fu durante le vacanze di Natale che accadde qualcosa di inaspettato. Marco Pizzini, con un background economico e senza formazione informatica, iniziò per gioco a sperimentare con GPT-o3. L’idea era semplice: capire se l’AI potesse supportare la scrittura di codice per estendere e potenziare il sistema che stavamo già utilizzando.
Quello che nacque fu un periodo di “vibe coding” puro: uno scambio continuo tra intuizioni, prompt generativi e codice messo subito in pratica. Ogni nuova funzionalità, dall’integrazione di nuovi tipi di asset alla gestione degli ID degli utenti, veniva costruita con l’aiuto dell’AI. L’assenza di regole rigide, unita alla flessibilità del sistema esistente basato su Sheets e API leggere, rese questo momento estremamente fertile.
In poco tempo iniziarono a emergere delle vere componenti di prodotto: un primo login, una gestione base degli avatar, un’idea primitiva di cloud. Tutto era ancora artigianale, ma funzionava. E, soprattutto, era stato costruito in modo trasversale da una figura non tecnica, supportata da un’intelligenza artificiale.
Fu in quel momento che capimmo: se con GPT potevamo arrivare fin lì, allora OpenGate poteva davvero essere per tutti.
Divenne una sfida: vediamo dove è possibile arrivare solo con GPT almeno per la parte di web-app!
Capitolo 4 – La webapp inizia a prendere forma
Dopo le prime sperimentazioni e i test riusciti, fu naturale voler trasformare quell’insieme di fogli e script in qualcosa di più solido. Così nacque il primo prototipo della webapp OpenGate, sviluppata con Flutter e Supabase. L’obiettivo era chiaro: creare un hub centrale per gestire asset, utenti e funzionalità interoperabili tra esperienze in realtà mista.
Le prime funzionalità a essere migrate furono quelle più utilizzate: il cloud per caricare asset multimediali, l’interfaccia per collegare wallet Web3 come Metamask e WalletConnect, e il collegamento con Ready Player Me per creare e salvare avatar 3D. A questo si aggiunse un sistema base per gestire assistant AI con OpenAI, legati agli avatar.
La forza di questo approccio stava nella continuità con l'app per visori XR, che nel frattempo continuava a leggere i Google Sheets. Ora però era possibile puntare agli stessi dati e contenuti direttamente dalla webapp, unificando l’ecosistema.
L’architettura, anche se ancora embrionale, iniziava a essere modulare. Ogni blocco – cloud, NFT, AI, avatar – era pensato come componente indipendente ma collegabile. Si cominciava così a intravedere la vera missione di OpenGate: diventare un ponte modulare tra mondi digitali.
Capitolo 5 – Addio Google Sheets
Il passaggio dai Google Sheets alla webapp fu più rapido del previsto. Nonostante fossero stati fondamentali nei primi mesi, i limiti iniziavano a farsi sentire: accessi poco sicuri, struttura fragile, difficoltà a gestire contenuti complessi o scene multiple. Con l’arrivo del backend Supabase e un frontend Flutter funzionante, la webapp prese il sopravvento.
La migrazione fu decisa. Prima vennero replicati gli stessi campi dei fogli all’interno del database, poi l’app su visore iniziò a leggere direttamente da Supabase. In parallelo, ogni nuovo utente veniva registrato sulla webapp, e non più via Google. Il risultato fu un sistema più scalabile, sicuro e coerente.
In breve tempo, i Google Sheets vennero completamente rimossi dall’app. Quello che era nato come strumento provvisorio era stato superato da un’infrastruttura vera, integrata e pronta per evolvere. Era il segnale che OpenGate stava diventando qualcosa di più di un esperimento: un progetto con visione, utenti e un potenziale reale di crescita.
Capitolo 6 – Il brainstorming sull’interoperabilità
Una volta consolidata la webapp, si aprì una domanda cruciale: e ora cosa possiamo farne davvero? Fu in quel momento che avvenne un brainstorming fondamentale. Seduti attorno a un tavolo – reale o virtuale – iniziammo a riflettere sul vero potenziale di OpenGate: diventare un ponte tra piattaforme, uno strumento per l’interoperabilità tra mondi diversi.
Non si trattava più solo di caricare asset o spawnarli in realtà mista. L’idea era molto più ambiziosa: rendere gli utenti liberi di portare con sé i propri contenuti, avatar e dati da un metaverso all’altro, da un’esperienza all’altra, mantenendo una coerenza narrativa e identitaria. NFT, avatar Ready Player Me, AI assistant, assets cloud… tutto doveva essere riutilizzabile ovunque.
In quel momento, OpenGate iniziò a definirsi come una vera infrastruttura di collegamento. Non solo un builder di Mixed Reality, ma uno strato trasversale, uno snodo. Un’interfaccia di interoperabilità, compatibile con le logiche di XR, gaming, Web3 e cultura digitale.
Fu un cambio di paradigma. Da semplice supporto operativo per Metagate, OpenGate cominciava a delinearsi come prodotto autonomo, con una missione chiara: costruire continuità tra ecosistemi digitali che oggi vivono ancora in compartimenti stagni ma che lasciano aperte le porte a soluzioni di questo tipo che, fino ad ora, nessuno ha mai pienamente sfruttato.
Capitolo 7 – Ristrutturazione scalabile e nuova UI per l’app su visore
Una volta chiarita la visione di OpenGate come infrastruttura modulare e interoperabile, ci rendemmo conto che l’anello debole era proprio l’app su visore. Ancora legata alla vecchia logica dei Google Sheets, l’app era diventata un accumulo di patch, test rapidi e codice scritto "al volo". Funzionava, ma era fragile, difficile da mantenere e soprattutto poco scalabile.
Così partì un altro brainstorming, questa volta incentrato su come ripulire e rifondare la UI dell’app XR. L’interfaccia, pensata inizialmente per test veloci, si era caricata nel tempo di sovrastrutture inutili, passaggi non ottimizzati e logiche ereditate da un periodo in cui ogni elemento veniva hard-codato o letto direttamente da fogli Google.
Volevamo invece una UI pensata per gli utenti finali, non solo per gli sviluppatori: fluida, modulare, coerente, facilmente navigabile in mixed reality. L’obiettivo era creare una struttura riutilizzabile per più progetti, con componenti che potessero adattarsi a diversi tipi di esperienza, da mostre a giochi collaborativi.
In parallelo, iniziammo a separare logicamente i moduli dell’app: asset, AI, multiplayer, NFT, cloud. Ogni blocco doveva vivere in autonomia, ma comunicare con gli altri. Era l’inizio della trasformazione vera di OpenGate in sistema XR flessibile.
Capitolo 8 – La selezione a BeFuture e l’aiuto di KNOBS
In quel momento di ristrutturazione e ripensamento generale, arrivò una notizia che segnò un punto di svolta: OpenGate venne selezionato tra i progetti vincitori di BeFuture. Il bando, dedicato a innovazione e sperimentazione, ci offrì due cose fondamentali: credibilità e risorse. Finalmente avevamo la possibilità concreta di mettere ordine nel codice e rendere la piattaforma più sicura, stabile e pronta per la produzione.
Grazie ai fondi ottenuti – che sarebbero stati disponibili nei mesi successivi – fu possibile programmare in modo preciso i prossimi passi, questa volta con una visione chiara e un piano d’azione condiviso. In particolare, iniziammo a confrontarci con il team di KNOBS per pianificare un percorso di refactoring tecnico, miglioramento della compliance e messa in sicurezza della webapp.
L’obiettivo era ambizioso: ripulire tutto il backend, modularizzare il codice, integrare controlli di sicurezza, rafforzare il login, ottimizzare le API e garantire la tenuta del sistema nel tempo. Ma nulla di tutto ciò era ancora operativo: tutto era in fase di definizione e progettazione.
Intanto, si continuava a lavorare in parallelo sulla parte più visibile: l’app su visore, che avrebbe ospitato le prime release pubbliche previste per l’estate. Il vero lavoro tecnico grazie a BeFuture sarebbe iniziato di lì a poco.
Capitolo 9 – Due binari: nuova UI in sviluppo, vecchia UI adattata per il Meta Store
Durante i mesi primaverili, OpenGate si sviluppava su due binari paralleli. Da un lato, Daniele stava lavorando alla nuova UI/UX dell’app su visore: una riprogettazione completa, pulita, modulare, pensata per offrire un’interazione fluida e intuitiva agli utenti finali. Il design veniva costruito da zero, con un’attenzione particolare alla chiarezza dei flussi, alla scalabilità e alla coerenza visuale.
Nel frattempo, però, si decise di non aspettare la nuova interfaccia per iniziare a confrontarsi con il mondo reale. Così, in parallelo, il Paolo e Giada si concentrarono su un’altra priorità: ripulire e adattare la vecchia UI, quella piena di sovrastrutture nate nel periodo dei Google Sheets, per renderla minimamente pubblicabile sul Meta Store.
L’obiettivo era pragmatico: uscire il prima possibile, anche con una versione limitata, per testare la procedura di submission, affrontare eventuali blocchi tecnici o burocratici, e iniziare a capire le policy di pubblicazione di Meta, spesso opache e complesse. Era una fase di scontro controllato con la realtà, utile per anticipare problemi futuri e preparare il terreno per le versioni successive. Ridurre il rischio.
OpenGate stava così compiendo il suo primo salto fuori dal laboratorio: non ancora perfetto, ma reale.
"Se non ti vergogni del primo prodotto l'hai lanciato troppo tardi!" Cit.
Capitolo 10 – Prima release gratuita a giugno e test all’ATLAS MEET
A giugno arrivò il momento della prima release pubblica di OpenGate. Nonostante la UI fosse ancora quella “di fortuna”, sistemata giusto quel minimo per superare la submission del Meta Store, decidemmo di pubblicare la prima versione gratuitamente. L’obiettivo non era ancora conquistare utenti, ma testare la tenuta tecnica e il comportamento della piattaforma in un contesto reale.
L’occasione perfetta fu l’ATLAS MEET, evento organizzato da MEET Digital Culture Center a Milano, dove fummo invitati per il secondo anno consecutivo da Maria Grazia Mattei. Per l’evento lanciammo una Call for Artists, permettendo di caricare contenuti sul visore in tempi rapidissimi e visualizzarli in realtà mista.
Fu un test importante sotto ogni punto di vista: la gestione del cloud funzionò bene, il sistema reggeva, e gli riuscivamo davvero a “spawnare” asset senza scrivere codice. Ma fu anche l’occasione per raccogliere feedback diretti sul campo: cosa funzionava, cosa no, cosa era poco chiaro, dove l’esperienza poteva migliorare.
Questa prima uscita pubblica rappresentò un momento simbolico: OpenGate non era più un progetto interno o un prototipo, ma una piattaforma XR pronta a incontrare le persone.
Capitolo 11 – Seconda release a luglio e test al Broletto di Novara
A luglio arrivò la seconda release di OpenGate, questa volta con un passo avanti importante: la prima versione della nuova UI, frutto del lavoro svolto nei mesi precedenti. Non era ancora definitiva, ma bastava per offrire un’esperienza più fluida, coerente e moderna rispetto alla versione precedente, pensata solo per superare la pubblicazione sullo store.
Per testarla, fu cruciale l’invito al Broletto di Novara, grazie alla collaborazione con Andrea Barbara Romita e il supporto di Marta Ballara. In un contesto artistico e culturale, presentammo OpenGate come strumento no-code per gestire contenuti digitali in realtà mista, con una demo interattiva accessibile a diversi tipi di pubblico.
L’esperienza fu estremamente utile: il nuovo flusso di interazione semplificava davvero l’uso dell’app, rendendola più accessibile anche a chi non aveva mai utilizzato un visore XR. Le funzioni cloud, avatar e AI iniziavano a convivere in un’interfaccia unificata.
Capitolo 12 – Terza release ad agosto: multiplayer, scene e mondo persistente
La terza release di OpenGate, pubblicata ad agosto, segna un vero punto di svolta. È la prima versione davvero strutturata e completa dell’app su visore, con alcune delle funzionalità più attese: sistema multi-scena, multiplayer sincronizzato e persistenza degli oggetti nel mondo reale.
Gli utenti ora possono navigare tra scene differenti, ciascuna con la propria ambientazione, regole, contenuti e layout. Ogni scena è costruita per essere modificabile in tempo reale e soprattutto riutilizzabile, con configurazioni salvate nel cloud. Ma la grande novità è che, per la prima volta, ciò che viene posizionato nello spazio misto – asset, oggetti, elementi – resta salvato e sincronizzato anche al riavvio, rendendo l’esperienza persistente e condivisa.
Il multiplayer consente a più utenti di trovarsi nella stessa scena e vedere gli oggetti nella stessa posizione, aprendo la strada a collaborazioni, giochi e mostre interattive multi-utente. È il primo passo concreto verso un spazio XR collettivo.
La release è live da pochi giorni, e siamo ora in una fase di osservazione attiva: vogliamo capire come le persone useranno questi strumenti, che tipo di contenuti creeranno, e dove ci porterà questa nuova forma di presenza digitale aumentata.
Capitolo 13 – Messa in sicurezza e scalabilità del backend con KNOBS
Con la terza release finalmente online, era arrivato il momento di affrontare un nodo cruciale: la messa in sicurezza del backend. Fino a quel momento, il codice era stato scritto in modo progressivo e funzionale, spesso seguendo il flusso delle esigenze creative e dei test continui. Nonostante la struttura reggesse, era evidente che per garantire affidabilità e scalabilità, serviva un intervento tecnico mirato.
In questa fase entrò in gioco in modo operativo KNOBS, il cui lavoro fu una correzione puntuale del codice esistente, con l’obiettivo di consolidare ciò che già funzionava, mettendolo però al riparo da problemi futuri.
Le priorità furono chiare: protezione delle chiavi API, miglioramento della sicurezza degli accessi, gestione centralizzata delle variabili sensibili, e soprattutto la preparazione di una struttura più solida per poter testare updates in sicurezza e accogliere un numero crescente di utenti e contenuti.
Iscriviti alla newsletter per tutti i vantaggi!
Per il video delle nostre esperienze seguici su Instagram, YouTube e Twitter.
I nostri riferimenti li trovi sul Linktree or contact us!