Capítulo 1 – A necessidade inicial: acelerar os POC
A OpenGate nasceu de uma necessidade concreta e operacional: acelerar a criação de proof of concept (POC) para experiências de realidade mista e aumentada. Num contexto de experimentação rápida como o da Metagate, cada dia era uma corrida contra o tempo. Havia muitas ideias, os dispositivos XR como o Meta Quest 3 eram cada vez mais potentes, mas faltava uma ferramenta leve, dinâmica e centralizada para organizar o acesso aos conteúdos e a gestão dos dados. O objetivo era claro: desenvolver mais experiências em menos tempo, com maior controlo e capacidade de iteração.
Na altura, a ferramenta mais flexível e imediata disponível era o Google Sheets. Uma folha partilhada, atualizável em tempo real e facilmente legível também pelo Unity, era suficiente para gerir os primeiros testes com assets multimédia (imagens, 3D, sons) e links dinâmicos. Bastava inserir um URL, atualizar um parâmetro ou alterar uma coordenada, e a experiência no visor adaptava-se de imediato. Uma solução no-code que permitia à equipa criativa e aos programadores trabalharem em conjunto sem estruturas desnecessárias.
Em paralelo, eram desenvolvidas pequenas API em Google Apps Script, diretamente ligadas às folhas. Estes scripts permitiam automatizar a gestão das linhas, extrair dados específicos, gerar tokens de acesso ou até modificar em tempo real a configuração de uma experiência MR. Cada API era uma pequena ferramenta pensada para uma finalidade concreta: acelerar o teste de uma cena, uma personagem ou uma mecânica interativa. Nasceu assim uma microinfraestrutura ágil, leve e, ao mesmo tempo, incrivelmente poderosa.
Esta abordagem, apesar de ter surgido como solução temporária, revelou-se imediatamente eficaz. A equipa conseguia gerir vários projetos XR em simultâneo, com uma configuração centralizada que permitia intervir remotamente em experiências já carregadas nos visores. Bastava abrir uma folha e alterar um valor para transformar o ambiente digital em tempo real. Para uma startup como a Metagate, sempre em movimento entre eventos, exposições e demos, esta flexibilidade era fundamental.
No entanto, os limites eram evidentes. A abordagem baseada em Google Sheets não garantia verdadeira escalabilidade. Não existia um sistema estruturado para controlo de acessos, integração de avatares, gestão de cenas complexas ou interoperabilidade com plataformas NFT. Além disso, o código ligado às folhas estava escrito de forma fragmentada, muitas vezes com soluções de “vibe coding”: rápidas e criativas, mas pouco fáceis de manter a longo prazo.
Foi precisamente nesse momento que surgiu a ideia de transformar aquele sistema provisório em algo mais sólido, modular e escalável.
Capítulo 2 – Os primeiros testes com alpha testers
Com a microinfraestrutura baseada em Google Sheets e API a funcionar, chegou o momento de a testar no terreno. Foi então que envolvemos os primeiros alpha testers: artistas, programadores, curadores e utilizadores avançados já próximos da comunidade da Metagate. O objetivo era perceber se este sistema leve e dinâmico podia realmente simplificar a criação e a utilização de experiências de realidade mista.
O feedback foi desde logo encorajador. Os alpha testers valorizaram a possibilidade de alterar conteúdos em tempo real, sem necessidade de recompilar o projeto Unity. Bastava atualizar um link numa folha e a experiência no visor adaptava-se em tempo real. Isto abriu novas possibilidades tanto para workshops ao vivo como para testes antes de eventos.
Alguns utilizadores, sem qualquer experiência de programação, já conseguiam fazer spawn de assets 3D, imagens e vídeos simplesmente colando um link numa célula. A componente no-code da solução revelou-se decisiva para promover a colaboração entre perfis muito diferentes.
Nesta fase inicial ainda não existia uma UI propriamente dita: a interface era a própria folha. Mas foi suficiente para revelar o potencial da abordagem. A sensação era a de termos encontrado uma forma nova, direta e partilhada de compor experiências XR. A montagem da experiência de mixed reality acontecia manualmente e fisicamente no mundo real! Uma nova forma de entender um “builder”, a meio caminho entre o físico e o digital, em pleno espírito de mixed reality.
Este entusiasmo deu o impulso decisivo para pensar em algo mais estruturado. O sistema funcionava, mas para evoluir tinha de sair da folha e tornar-se uma verdadeira plataforma. A OpenGate, ainda sem nome, estava prestes a nascer de verdade.
Capítulo 3 – GPT-o3, vibe coding e as férias de Natal
Foi durante as férias de Natal que aconteceu algo inesperado. Marco Pizzini, com formação económica e sem formação informática, começou por curiosidade a experimentar o GPT-o3. A ideia era simples: perceber se a IA podia apoiar a escrita de código para ampliar e reforçar o sistema que já utilizávamos.
O que se seguiu foi um período de “vibe coding” puro: uma troca contínua entre intuições, prompts generativos e código imediatamente posto em prática. Cada nova funcionalidade, desde a integração de novos tipos de assets até à gestão dos ID dos utilizadores, era construída com o apoio da IA. A ausência de regras rígidas, aliada à flexibilidade do sistema existente baseado em Sheets e API leves, tornou este momento extremamente fértil.
Em pouco tempo começaram a surgir verdadeiros componentes de produto: um primeiro login, uma gestão básica de avatares, uma ideia inicial de cloud. Tudo continuava artesanal, mas funcionava. E, acima de tudo, tinha sido construído de forma transversal por uma pessoa não técnica, apoiada por uma inteligência artificial.
Foi então que percebemos: se com GPT conseguíamos chegar tão longe, então a OpenGate podia realmente ser para todos.
Tornou-se um desafio: até onde seria possível chegar apenas com GPT, pelo menos na parte da web-app?
Capítulo 4 – A webapp começa a ganhar forma
Depois das primeiras experiências e dos testes bem-sucedidos, foi natural querer transformar aquele conjunto de folhas e scripts em algo mais sólido. Nasceu assim o primeiro protótipo da webapp OpenGate, desenvolvido com Flutter e Supabase. O objetivo era claro: criar um hub central para gerir assets, utilizadores e funcionalidades interoperáveis entre experiências de realidade mista.
As primeiras funcionalidades a serem migradas foram as mais utilizadas: a cloud para carregar assets multimédia, a interface para ligar wallets Web3 como Metamask e WalletConnect, e a integração com Ready Player Me para criar e guardar avatares 3D. A isto juntou-se um sistema base para gerir assistentes de IA com OpenAI, ligados aos avatares.
A força desta abordagem estava na continuidade com a aplicação para visores XR, que entretanto continuava a ler Google Sheets. Agora, porém, era possível aceder aos mesmos dados e conteúdos diretamente a partir da webapp, unificando o ecossistema.
A arquitetura, embora ainda embrionária, começava a tornar-se modular. Cada bloco — cloud, NFT, IA, avatar — era pensado como um componente independente, mas interligável. Começava assim a revelar-se a verdadeira missão da OpenGate: tornar-se uma ponte modular entre mundos digitais.
Capítulo 5 – Adeus, Google Sheets
A passagem de Google Sheets para a webapp foi mais rápida do que o previsto. Apesar de terem sido fundamentais nos primeiros meses, os seus limites começaram a fazer-se sentir: acessos pouco seguros, estrutura frágil e dificuldade em gerir conteúdos complexos ou múltiplas cenas. Com a chegada do backend Supabase e de um frontend Flutter funcional, a webapp assumiu o controlo.
A migração foi decidida. Primeiro foram replicados na base de dados os mesmos campos das folhas; depois, a aplicação no visor começou a ler diretamente do Supabase. Em paralelo, cada novo utilizador passou a ser registado na webapp e deixou de ser registado através do Google. O resultado foi um sistema mais escalável, seguro e coerente.
Em pouco tempo, o Google Sheets foi completamente removido da aplicação. O que tinha nascido como ferramenta provisória foi ultrapassado por uma verdadeira infraestrutura, integrada e preparada para evoluir. Era o sinal de que a OpenGate se estava a tornar algo mais do que uma experiência: um projeto com visão, utilizadores e verdadeiro potencial de crescimento.
Capítulo 6 – O brainstorming sobre interoperabilidade
Depois de consolidada a webapp, surgiu uma pergunta crucial: e agora, o que podemos realmente fazer com ela? Foi nesse momento que aconteceu um brainstorming fundamental. Sentados à volta de uma mesa — real ou virtual — começámos a refletir sobre o verdadeiro potencial da OpenGate: tornar-se uma ponte entre plataformas, uma ferramenta de interoperabilidade entre mundos diferentes.
Já não se tratava apenas de carregar assets ou fazer spawn em realidade mista. A ideia era muito mais ambiciosa: dar aos utilizadores liberdade para levarem consigo os seus conteúdos, avatares e dados de um metaverso para outro, de uma experiência para outra, mantendo coerência narrativa e identitária. NFT, avatares Ready Player Me, assistentes de IA, assets cloud… tudo devia poder ser reutilizado em qualquer lugar.
Nesse momento, a OpenGate começou a definir-se como uma verdadeira infraestrutura de ligação. Não apenas um builder de Mixed Reality, mas uma camada transversal, um ponto de ligação. Uma interface de interoperabilidade compatível com as lógicas de XR, gaming, Web3 e cultura digital.
Foi uma mudança de paradigma. De simples suporte operacional para a Metagate, a OpenGate começava a assumir-se como um produto autónomo, com uma missão clara: construir continuidade entre ecossistemas digitais que ainda hoje vivem em compartimentos estanques, mas deixam aberta a porta a soluções deste tipo cujo potencial ninguém explorou plenamente até agora.
Capítulo 7 – Reestruturação escalável e nova UI para a aplicação no visor
Depois de clarificada a visão da OpenGate como infraestrutura modular e interoperável, percebemos que o elo mais fraco era precisamente a aplicação no visor. Ainda ligada à antiga lógica de Google Sheets, a aplicação tinha-se tornado uma acumulação de patches, testes rápidos e código escrito “em cima do joelho”. Funcionava, mas era frágil, difícil de manter e, sobretudo, pouco escalável.
Assim começou outro brainstorming, desta vez centrado em como limpar e reconstruir a UI da aplicação XR. A interface, inicialmente pensada para testes rápidos, tinha acumulado ao longo do tempo estruturas desnecessárias, passos não otimizados e lógicas herdadas de uma fase em que cada elemento era hard-coded ou lido diretamente de Google Sheets.
Queríamos, pelo contrário, uma UI pensada para os utilizadores finais, e não apenas para programadores: fluida, modular, coerente e fácil de navegar em mixed reality. O objetivo era criar uma estrutura reutilizável em vários projetos, com componentes capazes de se adaptar a diferentes tipos de experiência, de exposições a jogos colaborativos.
Em paralelo, começámos a separar logicamente os módulos da aplicação: assets, IA, multiplayer, NFT, cloud. Cada bloco devia funcionar autonomamente, mas comunicar com os restantes. Era o início da verdadeira transformação da OpenGate num sistema XR flexível.
Capítulo 8 – A seleção no BeFuture e a ajuda da KNOBS
No meio desta reestruturação e revisão geral, chegou uma notícia que marcou um ponto de viragem: a OpenGate foi selecionada entre os projetos vencedores do BeFuture. O programa, dedicado à inovação e experimentação, ofereceu-nos duas coisas fundamentais: credibilidade e recursos. Finalmente tínhamos a possibilidade concreta de organizar o código e tornar a plataforma mais segura, estável e preparada para produção.
Graças aos fundos obtidos — que ficariam disponíveis nos meses seguintes — foi possível planear com precisão os próximos passos, desta vez com uma visão clara e um plano de ação partilhado. Em particular, começámos a trabalhar com a equipa da KNOBS para definir um percurso de refactoring técnico, melhoria da compliance e reforço da segurança da webapp.
O objetivo era ambicioso: limpar todo o backend, modularizar o código, integrar controlos de segurança, reforçar o login, otimizar as API e garantir a robustez do sistema ao longo do tempo. Mas nada disso estava ainda operacional: tudo estava em fase de definição e planeamento.
Entretanto, o trabalho continuava em paralelo na parte mais visível: a aplicação no visor, que iria receber as primeiras versões públicas previstas para o verão. O verdadeiro trabalho técnico, graças ao BeFuture, começaria pouco depois.
Capítulo 9 – Duas vias: nova UI em desenvolvimento, antiga UI adaptada ao Meta Store
Durante os meses da primavera, a OpenGate evoluía em duas vias paralelas. Por um lado, Daniele estava a trabalhar na nova UI/UX da aplicação no visor: um redesign completo, limpo e modular, pensado para oferecer uma interação fluida e intuitiva aos utilizadores finais. O design era construído de raiz, com especial atenção à clareza dos fluxos, à escalabilidade e à coerência visual.
Entretanto, decidimos não esperar pela nova interface para começar a confrontar a plataforma com o mundo real. Assim, em paralelo, Paolo e Giada concentraram-se noutra prioridade: limpar e adaptar a antiga UI, cheia de estruturas herdadas do período de Google Sheets, para a tornar minimamente publicável no Meta Store.
O objetivo era pragmático: publicar o mais cedo possível, mesmo com uma versão limitada, para testar o processo de submission, enfrentar eventuais bloqueios técnicos ou burocráticos e começar a compreender as políticas de publicação da Meta, muitas vezes pouco transparentes e complexas. Era um confronto controlado com a realidade, útil para antecipar problemas futuros e preparar as versões seguintes. Reduzir o risco.
A OpenGate dava assim o primeiro salto para fora do laboratório: ainda não perfeita, mas real.
“Se não tens vergonha do teu primeiro produto, lançaste-o tarde demais!” Cit.
Capítulo 10 – Primeira versão gratuita em junho e teste no ATLAS MEET
Em junho chegou o momento da primeira versão pública da OpenGate. Apesar de a UI ainda ser uma solução provisória, ajustada apenas o suficiente para ultrapassar a submission no Meta Store, decidimos publicar gratuitamente a primeira versão. O objetivo ainda não era conquistar utilizadores, mas testar a robustez técnica e o comportamento da plataforma num contexto real.
A oportunidade perfeita foi o ATLAS MEET, evento organizado pelo MEET Digital Culture Center em Milão, para o qual fomos convidados pelo segundo ano consecutivo por Maria Grazia Mattei. Para o evento lançámos uma Call for Artists, permitindo carregar conteúdos no visor muito rapidamente e visualizá-los em realidade mista.
Foi um teste importante em todos os sentidos: a gestão da cloud funcionou bem, o sistema manteve-se estável e conseguíamos realmente “fazer spawn” de assets sem escrever código. Mas foi também uma oportunidade para recolher feedback direto no terreno: o que funcionava, o que não funcionava, o que era pouco claro e onde a experiência podia melhorar.
Esta primeira saída pública representou um momento simbólico: a OpenGate deixou de ser um projeto interno ou um protótipo e tornou-se uma plataforma XR pronta para encontrar as pessoas.
Capítulo 11 – Segunda versão em julho e teste no Broletto di Novara
Em julho chegou a segunda versão da OpenGate, desta vez com um avanço importante: a primeira versão da nova UI, resultado do trabalho realizado nos meses anteriores. Ainda não era definitiva, mas já permitia oferecer uma experiência mais fluida, coerente e moderna do que a versão anterior, pensada apenas para ultrapassar a publicação no store.
Para a testar, foi essencial o convite ao Broletto di Novara, graças à colaboração com Andrea Barbara Romita e ao apoio de Marta Ballara. Num contexto artístico e cultural, apresentámos a OpenGate como ferramenta no-code para gerir conteúdos digitais em realidade mista, com uma demo interativa acessível a diferentes tipos de público.
A experiência foi extremamente útil: o novo fluxo de interação simplificava realmente a utilização da aplicação, tornando-a mais acessível até para quem nunca tinha utilizado um visor XR. As funcionalidades de cloud, avatar e IA começavam a coexistir numa interface unificada.
Capítulo 12 – Terceira versão em agosto: multiplayer, cenas e mundo persistente
A terceira versão da OpenGate, publicada em agosto, marca um verdadeiro ponto de viragem. É a primeira versão realmente estruturada e completa da aplicação no visor, com algumas das funcionalidades mais esperadas: sistema multi-cena, multiplayer sincronizado e persistência dos objetos no mundo real.
Os utilizadores podem agora navegar entre diferentes cenas, cada uma com a sua própria ambientação, regras, conteúdos e layout. Cada cena foi concebida para poder ser modificada em tempo real e, sobretudo, reutilizada, com configurações guardadas na cloud. Mas a grande novidade é que, pela primeira vez, tudo o que é colocado no espaço misto — assets, objetos, elementos — permanece guardado e sincronizado mesmo depois de reiniciar, tornando a experiência persistente e partilhada.
O multiplayer permite que vários utilizadores estejam na mesma cena e vejam os objetos na mesma posição, abrindo caminho a colaborações, jogos e exposições interativas multiutilizador. É o primeiro passo concreto para um espaço XR coletivo.
A versão está online há poucos dias e estamos agora numa fase de observação ativa: queremos perceber como as pessoas vão utilizar estas ferramentas, que tipo de conteúdos irão criar e até onde nos levará esta nova forma de presença digital aumentada.
Capítulo 13 – Segurança e escalabilidade do backend com a KNOBS
Com a terceira versão finalmente online, chegou o momento de enfrentar um ponto crucial: a segurança do backend. Até então, o código tinha sido escrito de forma progressiva e funcional, muitas vezes seguindo o ritmo das necessidades criativas e dos testes contínuos. Apesar de a estrutura se manter, era evidente que, para garantir fiabilidade e escalabilidade, era necessária uma intervenção técnica específica.
Nesta fase entrou operacionalmente em ação a KNOBS, cujo trabalho consistiu numa correção pontual do código existente, com o objetivo de consolidar o que já funcionava e protegê-lo contra problemas futuros.
As prioridades foram claras: proteção das chaves API, melhoria da segurança dos acessos, gestão centralizada das variáveis sensíveis e, sobretudo, a preparação de uma estrutura mais robusta para testar updates em segurança e suportar um número crescente de utilizadores e conteúdos.
Subscreva a nossa newsletter para aproveitar todas as vantagens!
Para ver vídeos das nossas experiências, siga-nos no Instagram, YouTube e Twitter.
Encontre os nossos links no Linktree ou contacte-nos!
Por Marco Pizzini