Capítulo 1 – La necesidad inicial: acelerar los POC
OpenGate nace de una necesidad concreta y operativa: acelerar la creación de proof of concept (POC) para experiencias de realidad mixta y aumentada. En un contexto de experimentación rápida como el de Metagate, cada día era una carrera contrarreloj. Había muchas ideas, los dispositivos XR como Meta Quest 3 eran cada vez más potentes, pero faltaba una herramienta ligera, dinámica y centralizada para organizar el acceso a los contenidos y la gestión de los datos. El objetivo era claro: desarrollar más experiencias en menos tiempo, con mayor control y capacidad de iteración.
En aquel momento, la herramienta más flexible e inmediata disponible era Google Sheets. Una hoja compartida, actualizable en tiempo real y fácilmente legible también por Unity, bastaba para gestionar las primeras pruebas con assets multimedia (imágenes, 3D, sonidos) y enlaces dinámicos. Bastaba con introducir una URL, actualizar un parámetro o cambiar una coordenada para que la experiencia en el visor se adaptara al instante. Una solución no-code que permitía al equipo creativo y a los desarrolladores trabajar juntos sin estructuras innecesarias.
En paralelo, se desarrollaban pequeñas API en Google Apps Script, directamente vinculadas a las hojas. Estos scripts permitían automatizar la gestión de filas, extraer datos específicos, generar tokens de acceso e incluso modificar en tiempo real la configuración de una experiencia MR. Cada API era una pequeña herramienta pensada para un objetivo concreto: acelerar la prueba de una escena, un personaje o una mecánica interactiva. Así nació una microinfraestructura ágil, ligera y, al mismo tiempo, increíblemente potente.
Este enfoque, aunque nació como solución temporal, demostró enseguida su eficacia. El equipo podía gestionar múltiples proyectos XR al mismo tiempo, con una configuración centralizada que permitía intervenir a distancia sobre experiencias ya cargadas en los visores. Bastaba abrir una hoja y cambiar un valor para transformar el entorno digital en tiempo real. Para una startup como Metagate, siempre en movimiento entre eventos, exposiciones y demos, esta flexibilidad era fundamental.
Sin embargo, los límites eran evidentes. El enfoque basado en Google Sheets no garantizaba una verdadera escalabilidad. No existía un sistema estructurado para controlar accesos, integrar avatares, gestionar escenas complejas o garantizar la interoperabilidad con plataformas NFT. Además, el código vinculado a las hojas estaba escrito de forma fragmentaria, a menudo mediante soluciones de «vibe coding»: rápidas y creativas, pero poco mantenibles a largo plazo.
Fue precisamente entonces cuando nació la idea de transformar aquel sistema provisional en algo más sólido, modular y escalable.
Capítulo 2 – Las primeras pruebas con alpha testers
Con la microinfraestructura basada en Google Sheets y API ya operativa, llegó el momento de probarla sobre el terreno. Así involucramos a los primeros alpha testers: artistas, desarrolladores, comisarios y usuarios avanzados ya cercanos a la comunidad de Metagate. El objetivo era entender si este sistema ligero y dinámico podía simplificar realmente la creación y el uso de experiencias de realidad mixta.
Los comentarios fueron alentadores desde el principio. Los alpha testers valoraron la posibilidad de modificar contenidos sobre la marcha, sin tener que recompilar el proyecto de Unity. Bastaba actualizar un enlace en una hoja para que la experiencia en el visor se adaptara en tiempo real. Esto abrió nuevas posibilidades tanto para talleres en directo como para pruebas previas a los eventos.
Algunos usuarios, sin ninguna experiencia en programación, ya podían spawnear assets 3D, imágenes y vídeos simplemente pegando un enlace en una celda. El carácter no-code de la solución resultó decisivo para facilitar la colaboración entre perfiles muy diferentes.
En esta fase inicial todavía no existía una UI propiamente dicha: la interfaz era la propia hoja. Pero fue suficiente para mostrar el potencial del enfoque. La sensación era haber encontrado una forma nueva, directa y compartida de componer experiencias XR. ¡El montaje de la experiencia de mixed reality se realizaba manual y físicamente en el mundo real! Una nueva forma de entender un «builder», a medio camino entre lo físico y lo digital, plenamente en el espíritu de la mixed reality.
Ese entusiasmo dio el impulso decisivo para pensar en algo más estructurado. El sistema funcionaba, pero para evolucionar tenía que salir de la hoja y convertirse en una plataforma real. OpenGate, todavía sin nombre, estaba a punto de nacer de verdad.
Capítulo 3 – GPT-o3, vibe coding y las vacaciones de Navidad
Durante las vacaciones de Navidad ocurrió algo inesperado. Marco Pizzini, con formación económica y sin estudios informáticos, empezó por curiosidad a experimentar con GPT-o3. La idea era sencilla: entender si la IA podía ayudar a escribir código para ampliar y potenciar el sistema que ya utilizábamos.
Lo que siguió fue una etapa de «vibe coding» puro: un intercambio continuo entre intuiciones, prompts generativos y código puesto inmediatamente en práctica. Cada nueva función, desde la integración de nuevos tipos de assets hasta la gestión de los ID de usuario, se construía con ayuda de la IA. La ausencia de reglas rígidas, combinada con la flexibilidad del sistema existente basado en Sheets y API ligeras, hizo que aquel periodo fuera extraordinariamente fértil.
En poco tiempo comenzaron a surgir auténticos componentes de producto: un primer login, una gestión básica de avatares, una idea inicial de cloud. Todo seguía siendo artesanal, pero funcionaba. Y, sobre todo, había sido construido de forma transversal por una persona no técnica con el apoyo de una inteligencia artificial.
Fue entonces cuando lo entendimos: si con GPT podíamos llegar tan lejos, OpenGate podía ser realmente para todos.
Se convirtió en un reto: ¿hasta dónde podíamos llegar utilizando únicamente GPT, al menos para la parte de la web-app?
Capítulo 4 – La webapp empieza a tomar forma
Después de las primeras pruebas y experimentos satisfactorios, fue natural querer transformar aquel conjunto de hojas y scripts en algo más sólido. Así nació el primer prototipo de la webapp OpenGate, desarrollado con Flutter y Supabase. El objetivo estaba claro: crear un hub central para gestionar assets, usuarios y funciones interoperables entre experiencias de realidad mixta.
Las primeras funciones migradas fueron las más utilizadas: el cloud para cargar assets multimedia, la interfaz para conectar wallets Web3 como Metamask y WalletConnect, y la integración con Ready Player Me para crear y guardar avatares 3D. A ello se añadió un sistema básico para gestionar asistentes de IA con OpenAI vinculados a los avatares.
La fuerza de este enfoque residía en la continuidad con la aplicación para visores XR, que mientras tanto seguía leyendo Google Sheets. Sin embargo, ahora era posible acceder a los mismos datos y contenidos directamente desde la webapp, unificando el ecosistema.
La arquitectura, todavía embrionaria, empezaba a ser modular. Cada bloque —cloud, NFT, IA, avatar— estaba pensado como un componente independiente pero conectable. Así comenzó a perfilarse la verdadera misión de OpenGate: convertirse en un puente modular entre mundos digitales.
Capítulo 5 – Adiós a Google Sheets
El paso de Google Sheets a la webapp fue más rápido de lo previsto. Aunque habían sido fundamentales durante los primeros meses, sus límites empezaban a notarse: accesos poco seguros, estructura frágil y dificultad para gestionar contenidos complejos o varias escenas. Con la llegada del backend de Supabase y un frontend Flutter operativo, la webapp tomó el relevo.
La migración fue decidida. Primero se replicaron en la base de datos los mismos campos de las hojas; después, la aplicación del visor empezó a leer directamente desde Supabase. En paralelo, cada nuevo usuario se registraba en la webapp y ya no a través de Google. El resultado fue un sistema más escalable, seguro y coherente.
En poco tiempo, Google Sheets se eliminó por completo de la aplicación. Lo que había nacido como herramienta provisional quedó sustituido por una infraestructura real, integrada y preparada para evolucionar. Era la señal de que OpenGate se estaba convirtiendo en algo más que un experimento: un proyecto con visión, usuarios y verdadero potencial de crecimiento.
Capítulo 6 – El brainstorming sobre interoperabilidad
Una vez consolidada la webapp, surgió una pregunta crucial: ¿qué podíamos hacer realmente con ella ahora? Fue entonces cuando tuvo lugar un brainstorming fundamental. Sentados alrededor de una mesa —real o virtual— empezamos a reflexionar sobre el verdadero potencial de OpenGate: convertirse en un puente entre plataformas, una herramienta de interoperabilidad entre mundos diferentes.
Ya no se trataba únicamente de cargar assets o hacerlos aparecer en realidad mixta. La idea era mucho más ambiciosa: dar a los usuarios libertad para llevar consigo sus contenidos, avatares y datos de un metaverso a otro y de una experiencia a otra, manteniendo una coherencia narrativa e identitaria. NFT, avatares Ready Player Me, asistentes de IA, assets cloud… todo debía poder reutilizarse en cualquier lugar.
En ese momento, OpenGate empezó a definirse como una auténtica infraestructura de conexión. No solo un builder de Mixed Reality, sino una capa transversal, un nodo. Una interfaz de interoperabilidad compatible con las lógicas de XR, gaming, Web3 y cultura digital.
Fue un cambio de paradigma. De simple soporte operativo para Metagate, OpenGate empezó a perfilarse como un producto autónomo, con una misión clara: crear continuidad entre ecosistemas digitales que todavía viven en compartimentos estancos, pero dejan abierta la puerta a soluciones de este tipo cuyo potencial nadie ha aprovechado todavía por completo.
Capítulo 7 – Reestructuración escalable y nueva UI para la app del visor
Una vez definida la visión de OpenGate como infraestructura modular e interoperable, nos dimos cuenta de que el eslabón débil era precisamente la aplicación del visor. Todavía vinculada a la antigua lógica de Google Sheets, la app se había convertido en una acumulación de parches, pruebas rápidas y código escrito «sobre la marcha». Funcionaba, pero era frágil, difícil de mantener y, sobre todo, poco escalable.
Así comenzó otro brainstorming, esta vez centrado en cómo limpiar y reconstruir la UI de la aplicación XR. La interfaz, diseñada inicialmente para pruebas rápidas, había ido acumulando estructuras innecesarias, pasos poco optimizados y lógicas heredadas de una época en la que cada elemento se hard-codeaba o se leía directamente desde Google Sheets.
Queríamos, en cambio, una UI pensada para los usuarios finales, no solo para desarrolladores: fluida, modular, coherente y fácil de navegar en mixed reality. El objetivo era crear una estructura reutilizable en varios proyectos, con componentes capaces de adaptarse a distintos tipos de experiencia, desde exposiciones hasta juegos colaborativos.
En paralelo, empezamos a separar lógicamente los módulos de la aplicación: assets, IA, multiplayer, NFT y cloud. Cada bloque debía funcionar de forma autónoma, pero comunicarse con los demás. Era el comienzo de la verdadera transformación de OpenGate en un sistema XR flexible.
Capítulo 8 – La selección en BeFuture y la ayuda de KNOBS
En plena reestructuración y revisión general, llegó una noticia que marcó un punto de inflexión: OpenGate fue seleccionado entre los proyectos ganadores de BeFuture. La convocatoria, dedicada a innovación y experimentación, nos aportó dos elementos fundamentales: credibilidad y recursos. Por fin teníamos la posibilidad concreta de ordenar el código y hacer que la plataforma fuera más segura, estable y preparada para producción.
Gracias a los fondos obtenidos —que estarían disponibles en los meses siguientes— fue posible planificar con precisión los siguientes pasos, esta vez con una visión clara y un plan de acción compartido. En particular, empezamos a trabajar con el equipo de KNOBS para definir una ruta de refactoring técnico, mejora de la compliance y refuerzo de la seguridad de la webapp.
El objetivo era ambicioso: limpiar todo el backend, modularizar el código, integrar controles de seguridad, reforzar el login, optimizar las API y garantizar la solidez del sistema a largo plazo. Pero nada de aquello era todavía operativo: todo seguía en fase de definición y diseño.
Mientras tanto, el trabajo continuaba en paralelo en la parte más visible: la aplicación del visor, que albergaría las primeras versiones públicas previstas para el verano. El verdadero trabajo técnico gracias a BeFuture comenzaría poco después.
Capítulo 9 – Dos vías: nueva UI en desarrollo y antigua UI adaptada al Meta Store
Durante los meses de primavera, OpenGate avanzaba por dos vías paralelas. Por un lado, Daniele trabajaba en la nueva UI/UX de la aplicación del visor: un rediseño completo, limpio y modular, pensado para ofrecer una interacción fluida e intuitiva a los usuarios finales. El diseño se construía desde cero, prestando especial atención a la claridad de los flujos, la escalabilidad y la coherencia visual.
Sin embargo, decidimos no esperar a la nueva interfaz para empezar a confrontarnos con el mundo real. Así, en paralelo, Paolo y Giada se centraron en otra prioridad: limpiar y adaptar la antigua UI, cargada de estructuras heredadas de la época de Google Sheets, para hacerla al menos publicable en el Meta Store.
El objetivo era pragmático: publicar cuanto antes, incluso con una versión limitada, para probar el proceso de submission, afrontar posibles bloqueos técnicos o burocráticos y empezar a comprender las políticas de publicación de Meta, a menudo opacas y complejas. Era una confrontación controlada con la realidad, útil para anticipar futuros problemas y preparar las siguientes versiones. Reducir el riesgo.
OpenGate daba así su primer salto fuera del laboratorio: todavía no perfecto, pero real.
«Si no te avergüenza tu primer producto, lo has lanzado demasiado tarde». Cit.
Capítulo 10 – Primera versión gratuita en junio y prueba en ATLAS MEET
En junio llegó el momento de la primera versión pública de OpenGate. Aunque la UI seguía siendo provisional, ajustada apenas lo necesario para superar la submission del Meta Store, decidimos publicar gratuitamente la primera versión. El objetivo aún no era captar usuarios, sino probar la solidez técnica y el comportamiento de la plataforma en un contexto real.
La ocasión perfecta fue ATLAS MEET, evento organizado por el MEET Digital Culture Center de Milán, al que Maria Grazia Mattei nos invitó por segundo año consecutivo. Para el evento lanzamos una Call for Artists, que permitía cargar contenidos en el visor muy rápidamente y visualizarlos en realidad mixta.
Fue una prueba importante desde todos los puntos de vista: la gestión del cloud funcionó bien, el sistema se mantuvo estable y realmente podíamos «spawnear» assets sin escribir código. También fue una oportunidad para recoger feedback directo sobre el terreno: qué funcionaba, qué no, qué resultaba poco claro y dónde podía mejorarse la experiencia.
Esta primera salida pública representó un momento simbólico: OpenGate ya no era un proyecto interno ni un prototipo, sino una plataforma XR preparada para encontrarse con las personas.
Capítulo 11 – Segunda versión en julio y prueba en el Broletto di Novara
En julio llegó la segunda versión de OpenGate, esta vez con un avance importante: la primera versión de la nueva UI, fruto del trabajo de los meses anteriores. Aún no era definitiva, pero bastaba para ofrecer una experiencia más fluida, coherente y moderna que la versión previa, pensada únicamente para superar la publicación en el store.
Para probarla, fue crucial la invitación al Broletto di Novara, gracias a la colaboración con Andrea Barbara Romita y al apoyo de Marta Ballara. En un contexto artístico y cultural, presentamos OpenGate como herramienta no-code para gestionar contenidos digitales en realidad mixta, con una demo interactiva accesible a distintos tipos de público.
La experiencia fue extremadamente útil: el nuevo flujo de interacción simplificaba realmente el uso de la aplicación y la hacía más accesible incluso para quienes nunca habían utilizado un visor XR. Las funciones de cloud, avatar e IA empezaban a convivir en una interfaz unificada.
Capítulo 12 – Tercera versión en agosto: multiplayer, escenas y mundo persistente
La tercera versión de OpenGate, publicada en agosto, marca un auténtico punto de inflexión. Es la primera versión realmente estructurada y completa de la aplicación del visor, con algunas de las funciones más esperadas: sistema multiescena, multiplayer sincronizado y persistencia de objetos en el mundo real.
Ahora los usuarios pueden navegar entre diferentes escenas, cada una con su propia ambientación, reglas, contenidos y layout. Cada escena está diseñada para modificarse en tiempo real y, sobre todo, ser reutilizable, con configuraciones guardadas en el cloud. Pero la gran novedad es que, por primera vez, todo lo colocado en el espacio mixto —assets, objetos, elementos— permanece guardado y sincronizado incluso tras reiniciar, haciendo que la experiencia sea persistente y compartida.
El multiplayer permite que varios usuarios estén en la misma escena y vean los objetos en la misma posición, abriendo la puerta a colaboraciones, juegos y exposiciones interactivas multiusuario. Es el primer paso concreto hacia un espacio XR colectivo.
La versión lleva pocos días publicada y ahora estamos en una fase de observación activa: queremos entender cómo utilizarán las personas estas herramientas, qué tipo de contenidos crearán y adónde nos llevará esta nueva forma de presencia digital aumentada.
Capítulo 13 – Seguridad y escalabilidad del backend con KNOBS
Con la tercera versión por fin online, había llegado el momento de afrontar una cuestión crucial: la seguridad del backend. Hasta entonces, el código se había escrito de forma progresiva y funcional, siguiendo a menudo el ritmo de las necesidades creativas y las pruebas continuas. Aunque la estructura se mantenía, era evidente que para garantizar fiabilidad y escalabilidad hacía falta una intervención técnica específica.
En esta fase entró en juego de forma operativa KNOBS, cuyo trabajo consistió en una corrección puntual del código existente, con el objetivo de consolidar lo que ya funcionaba y protegerlo frente a problemas futuros.
Las prioridades estaban claras: protección de las claves API, mejora de la seguridad de los accesos, gestión centralizada de variables sensibles y, sobre todo, preparación de una estructura más sólida para poder probar actualizaciones de forma segura y admitir un número creciente de usuarios y contenidos.
Suscríbete a la newsletter para disfrutar de todas las ventajas.
Para ver vídeos de nuestras experiencias, síguenos en Instagram, YouTube y Twitter.
Encuentra nuestros enlaces en Linktree o contacta con nosotros.
Por Marco Pizzini