Aplicar IA num Produto SaaS: O caso de estudo Firepanel

O que o Firepanel faz, na prática

O Firebase dá aos developers uma infraestrutura sólida: autenticação, base de dados, armazenamento, hosting. O que não dá é uma forma de o resto da equipa gerir conteúdo sem mexer diretamente em documentos do Firestore. O Firepanel é essa camada em falta: um CMS e painel de administração para Firebase onde developers e as suas equipas ou clientes gerem tipos de conteúdo, coleções, armazenamento, utilizadores, pesquisa e notificações através de uma interface visual. Mantém-se headless, por isso o frontend continua a correr na stack que a equipa já usa, seja React, Next.js, Flutter, Vue ou outra.

Só essa interface já resolve um problema real. Mas mesmo com uma consola melhor, os developers continuam a repetir o mesmo trabalho de configuração e manutenção em cada novo projeto. Foi essa repetição, e não a vontade de “adicionar IA”, que serviu de ponto de partida para a Yetiman.

Gerar tipos de conteúdo em vez de definir cada campo à mão

Antes de uma aplicação Firebase poder fazer seja o que for, alguém tem de decidir como os dados estão estruturados: que coleções existem, que campos cada uma tem, que tipo é cada campo e como tudo se relaciona. A isto chama-se modelação de conteúdo (content modeling) e é um trabalho previsível que continua a levar tempo real quando é feito campo a campo.

O Firepanel já analisa coleções existentes no Firestore e propõe automaticamente os tipos de conteúdo correspondentes. Para projetos novos, a Yetiman e o Firepanel adicionaram o Generate with AI: o developer descreve o que precisa em linguagem natural, por exemplo “um blog com posts, autores e categorias”, e o Firepanel usa o Vertex AI com Gemini, a correr dentro do próprio projeto Google Cloud do cliente, para interpretar essa descrição e propor coleções, subcoleções ou componentes reutilizáveis. O developer revê e ajusta os campos antes de qualquer coisa ser usada.

O objetivo não é tirar o developer do processo. É eliminar a folha em branco. Em vez de construir uma estrutura previsível a partir do zero, o developer parte de um rascunho gerado e concentra a atenção nas decisões que realmente precisam de um humano, não nas que não precisam.

A vantagem não é só a velocidade. Um esquema escrito à mão é exatamente onde surgem pequenos erros: um campo chamado customerName numa coleção e client_name noutra, uma data guardada como texto simples em vez de um tipo de data correto, um erro de escrita que só aparece quando o frontend falha. Como o Firepanel propõe toda a estrutura a partir de uma única descrição, a nomenclatura mantém-se consistente entre coleções e cada campo recebe o tipo que os dados realmente precisam, sem o developer ter de verificar cada entrada à mão. Isto também muda quem pode iniciar o processo: alguém que nunca modelou uma base de dados NoSQL, um product manager ou um responsável de conteúdo, pode descrever o que precisa em linguagem natural e entregar ao developer uma estrutura só para rever, em vez de esperar que alguém traduza o pedido campo a campo.

Transformar uma coleção vazia em dados de exemplo realistas

Uma coleção nova com três registos de teste escritos à mão não diz grande coisa a uma equipa. Para ver como uma interface se comporta de verdade, os developers precisam de dados suficientemente realistas para expor títulos longos, valores fora do comum, listas maiores e casos limite que não tinham previsto ao desenhar a aplicação. Criar esses dados à mão é exatamente o tipo de tarefa que consome uma tarde inteira sem produzir nada que um cliente alguma vez veja.

O Generate Sample Data transforma essa tarde num prompt. Depois de um tipo de conteúdo existir, o developer escolhe quantos documentos gerar e pode acrescentar indicações, para um tipo Blog Post, por exemplo, “artigos de tecnologia sobre IA, publicados em 2026”. O Firepanel gera registos estruturados que respeitam o tipo de conteúdo e escreve-os diretamente no Firestore, deixando para o developer terminar apenas media, referências e relações que precisem de configuração extra.

O retorno aparece antes do lançamento, não depois. Conjuntos de dados realistas permitem testar paginação, filtros, pesquisa, estados vazios e o comportamento geral da interface enquanto ainda há tempo para corrigir o que falha. Para protótipos e demos, significa também passar de uma base de dados vazia para algo que parece um produto a

Ask Firepanel: consultar o Firestore em linguagem natural

Gerar estrutura e dados resolve dois problemas. O terceiro é mais simples e surge constantemente: perceber os dados que já lá estão. O Ask Firepanel, atualmente em beta, é um assistente apenas de leitura para explorar o Firestore em linguagem natural, em vez de abrir coleções manualmente, inspecionar documentos e montar queries só para responder a uma pergunta.

Um developer pode perguntar coisas como “quantos documentos existem em cada coleção”, “mostra-me os 10 registos criados mais recentemente”, “que conteúdo mudou mais este mês” ou “resume os dados disponíveis neste projeto”. O assistente explora os documentos acessíveis, identifica padrões e calcula métricas, e mantém-se deliberadamente apenas de leitura. Essa restrição é a decisão de design mais importante: o objetivo não é um agente autónomo com acesso irrestrito a uma base de dados em produção, é uma camada conversacional que ajuda os developers a investigar e perceber os seus dados mais depressa, mantendo total controlo sobre o que muda.

Como as perguntas são feitas em linguagem natural e não numa sintaxe de query, alguém sem qualquer conhecimento de Firestore ou de bases de dados, um PM a verificar o estado do conteúdo, um responsável de suporte a investigar um problema, pode obter uma resposta diretamente, em vez de esperar que um developer escreva e execute uma query por ele.

O que isto realmente poupa: tempo e dinheiro

A forma mais clara de avaliar estas funcionalidades não é contar o que a IA consegue gerar, é contar o trabalho repetitivo que elimina, e esse trabalho vai muito além de escrever campos num formulário. Considere um projeto Firebase de dimensão média, com cerca de 20 tipos de conteúdo: alguns simples, como uma Tag ou um Autor, outros bem mais trabalhosos, como um Produto com variantes, média e várias relações aninhadas com outras coleções:

Definir as estruturas é apenas o início. As equipas continuam a gastar tempo real em reuniões para alinhar nomenclatura e relações antes de escrever uma linha de código, depois mais tempo a corrigir as inconsistências que passaram despercebidas, e ainda mais tempo a verificar cruzadamente se cada referência entre coleções aponta mesmo para onde deve. Com as funcionalidades de IA do Firepanel a tratar do primeiro rascunho e a garantir nomenclatura e tipos consistentes desde o início, um fluxo de trabalho que de outra forma levaria 37–65 horas, bem mais do que uma semana de trabalho, passa a cerca de 4,5–9,5 horas de geração, revisão e refinamento.

Estes números são indicativos, não são benchmarks medidos; a poupança real depende da complexidade do projeto, do tamanho da equipa e de quanta configuração manual e alinhamento o projeto exigiria de outra forma. Usando um custo de desenvolvimento interno ou faturável de 50 €/hora, 33,5–55,5 horas poupadas traduzem-se em cerca de 1700 €–2800 € num único projeto de dimensão média. A uma tarifa de agência de 100 €/hora, a mesma redução passa a representar cerca de 3350 €–5550 € em custo de produção potencialmente evitado.

E nada disto é uma poupança pontual. Os dados de exemplo voltam a ser gerados para novos ambientes. Os modelos de conteúdo mudam à medida que os produtos evoluem. Os developers inspecionam bases de dados repetidamente durante QA, debugging e desenvolvimento de funcionalidades, e as equipas voltam a ter as mesmas reuniões de alinhamento em cada novo projeto. Em vários projetos Firebase, estas reduções no trabalho repetitivo e no retrabalho acumulam-se, o que significa que o verdadeiro valor não está em uma ação ficar mais rápida, mas sim em a equipa deixar de gastar repetidamente tempo de desenvolvimento caro em trabalho manual, reuniões e correções que um primeiro rascunho consistente teria evitado.

A IA funciona melhor quando remove fricção

As funcionalidades construídas para o Firepanel refletem a forma como a Yetiman aborda a IA em produtos digitais, de um modo geral: nem todos os workflows precisam de um agente, nem todas as interfaces precisam de um chatbot, e adicionar IA generativa a um produto não o torna automaticamente melhor. A pergunta útil é mais estreita: em que é que o utilizador gasta repetidamente tempo que uma máquina poderia razoavelmente fazer por ele?

No Firepanel, a resposta foi específica. Os developers definiam estruturas de conteúdo previsíveis à mão, por isso a IA cria o primeiro rascunho. Preenchiam manualmente bases de dados com conteúdo de teste, por isso a IA gera-o. Navegavam pelos dados para responder a perguntas relativamente simples, por isso um assistente recupera-os e resume-os. Em todos os casos, o developer continua a rever a estrutura, a validar o conteúdo gerado e a decidir o que acontece a seguir. A IA assume mais do trabalho repetitivo à volta do desenvolvimento, o que liberta os developers para passarem mais tempo a construir o produto propriamente dito. É nesse ponto que a IA deixa de ser uma funcionalidade numa lista e passa a funcionar como infraestrutura de um workflow melhor.

O Generate with AI e o Generate Sample Data são, na prática, copilots de automação com IA integrados diretamente numa ferramenta para developers. O Ask Firepanel segue a mesma disciplina que a Yetiman aplica ao construir chatbots com IA para outras empresas: uma camada conversacional com limites claros sobre o que pode tocar, e não um agente de acesso livre.

O próximo passo

As funcionalidades de IA com maior retorno raramente são as que têm a interface mais vistosa. São as que eliminam, discretamente, uma tarefa que ninguém queria continuar a fazer manualmente. Antes de adicionar uma funcionalidade de IA ao seu próprio produto, liste as três ou quatro tarefas que a sua equipa repete em todos os projetos e pergunte qual delas uma máquina conseguiria produzir como um primeiro rascunho revisável, não como substituição totalmente autónoma. É este todo o modelo por trás das funcionalidades de IA do Firepanel, e vale a pena testá-lo no seu próprio workflow antes de construir algo mais ambicioso.