Começámos por pagar por uma ferramenta pronta a usar para vídeos de demonstração, como faz a maioria das equipas. Depois pusemo-nos a contar as combinações: dois temas, sete idiomas e uma interface que muda quase todas as semanas. As contas não davam. Por isso, construímos o nosso próprio estúdio de demonstrações — e o facto de uma equipa de duas pessoas o ter conseguido, em poucos dias, é uma história maior do que a própria ferramenta.
O problema: uma demonstração não é um vídeo, são catorze
O promptShield é distribuído em tema claro e escuro e em sete idiomas — inglês, francês, alemão, espanhol, italiano, neerlandês e português. Uma única demonstração do produto — "é assim que se oculta um contrato" — não é, portanto, um só clipe. São dois temas × sete idiomas = catorze renderizações, cada uma a mostrar exatamente as mesmas ações sobre uma interface que tem de parecer nativa nesse idioma e correta nesse tema.
Multiplique agora isto por cada demonstração no site de marketing e, depois, lembre-se de que a aplicação por baixo é um alvo em movimento. Mudamos disposições, renomeamos botões, ajustamos espaçamentos e adicionamos funcionalidades a um ritmo semanal. Cada uma dessas mudanças invalida silenciosamente as gravações feitas a partir dos ecrãs antigos.
Porque é que a abordagem SaaS deixou de funcionar
As ferramentas da categoria Arcade / Storylane / Supademo / Trupeer são excelentes naquilo que fazem: percorre a sua aplicação com cliques, elas capturam o ecrã e obtém um percurso guiado bem polido. Mas todas partilham um pressuposto — o de que uma demonstração é um artefacto capturado de píxeis. É precisamente esse pressuposto que se desmorona à nossa escala:
- A explosão combinatória é manual. Catorze variantes de uma demonstração significam catorze tomadas gravadas à mão. Ninguém grava o mesmo fluxo catorze vezes seguidas sem desvios, e voltar a gravar a versão alemã em tema escuro seis semanas mais tarde para condizer com as restantes não apetece a ninguém.
- Um desvio na interface deixa tudo obsoleto de uma só vez. Mova um botão e todas as gravações que lhe tocaram ficam subtilmente erradas. Como a gravação é feita de píxeis, não há forma de a "reexecutar" — volta a gravar, à mão, catorze vezes, para cada demonstração afetada pela mudança.
- A localização é um segundo emprego. O SaaS grava aquilo que por acaso estava no ecrã num dado idioma. Manter sete versões linguísticas de uma dúzia de demonstrações perfeitamente sincronizadas com o produto é uma função de conteúdos a tempo inteiro que não temos nem queremos.
A conclusão honesta foi que esta categoria de ferramenta é feita para um mundo em que se cria uma demonstração uma vez e ela se mantém válida durante meses. O nosso mundo é o oposto: a demonstração tem de ser regenerada constantemente, em cada tema e em cada idioma, a partir de um produto que nunca está quieto.
A vantagem que já tínhamos
Eis a peça que tornou a construção da nossa própria ferramenta uma opção realista, e não temerária. A nossa página pública /demo não finge a aplicação — monta o verdadeiro frontend da aplicação de secretária no browser, os mesmos componentes React, o mesmo CSS, a mesma i18n, com as chamadas ao backend substituídas por mocks. Cada mudança de interface que fazemos na aplicação de secretária já flui automaticamente para a demonstração, porque a demonstração é a aplicação.
Isso significava que não precisávamos de uma ferramenta para "capturar" a nossa aplicação. Precisávamos de uma ferramenta para a conduzir — e, uma vez que a aplicação já corre no browser e já sabe renderizar-se em qualquer tema e qualquer idioma, os eixos do tema e do idioma podiam vir de borla.
O que construímos
Internamente chamamos-lhe Demo Studio. A mudança de pensamento é pequena e muda tudo: gravamos um guião de ações, não um vídeo de píxeis.
Gravar por demonstração
Ative o modo de captura e percorra o fluxo uma vez, num idioma e num tema. O Studio não grava o ecrã. Grava aquilo que fez — uma lista de eventos semânticos: "clicar neste elemento", "deslocar até aqui", "abrir este painel" — cada um associado a um seletor resolúvel, às pré-condições de que precisa e a uma marca temporal. Na reprodução, o elemento clicado pisca para que quem assiste possa acompanhar a ação, sem nada do trémulo rasto de cursor com que os gravadores de ecrã se debatem.
Um guião, catorze renderizações
Esse único guião é depois entregue a um browser headless que o reproduz e captura o resultado — uma vez por tema, uma vez por idioma. Uma sessão de gravação produz os catorze vídeos WebM e os respetivos fotogramas fixos, de forma determinística, porque é o mesmo guião a conduzir a mesma aplicação real com o tema e a região definidos de cada vez. A versão alemã em tema escuro e a versão inglesa em tema claro têm a garantia de mostrar ações idênticas, porque vieram de um guião idêntico.
Uma linha temporal de efeitos — e uma IA que os sugere
Sobre a reprodução em bruto assenta uma linha temporal para o acabamento que uma boa demonstração exige: aproximar uma região, fazer pulsar um controlo, sobrepor uma legenda. Há também um passo "Ask Claude" que propõe uma faixa de efeitos para um guião, de modo que a primeira versão de "onde devemos aproximar?" já lhe é rascunhada, em vez de ajustada fotograma a fotograma.
Slots que se mantêm honestos
Cada sítio onde uma demonstração aparece no site é um <DemoMedia slot="..."/> no código. O Studio percorre todo o código-base à procura destes e mostra-lhe, num relance, quais os slots totalmente gravados em cada tema e idioma, quais os que estão sem uma renderização e quais os diretórios de media que ficaram órfãos por o slot a que pertenciam ter sido eliminado. É a ferramenta que lhe diz o que está desatualizado, em vez de ser um cliente a dá-lo a conhecer.
A economia inverteu-se em silêncio
O objetivo de tudo isto não são as funcionalidades. É o que aconteceu à curva de custos. Com o SaaS, o custo marginal de uma mudança na interface era "voltar a gravar cada demonstração afetada, catorze vezes cada uma, à mão". Com o Demo Studio, o custo marginal de uma mudança na interface é carregar em renderizar de novo. O guião continua válido — descreve ações, e as ações continuam a existir — por isso a correção é tempo de máquina, não tempo humano.
Acrescentar um novo idioma costumava significar voltar a gravar cada demonstração nele. Agora é mais um valor no eixo da região. Acrescentar um tema era a mesma história. O trabalho que costumava crescer linearmente com (temas × idiomas × demonstrações × ritmo de lançamentos) cresce agora com o número de fluxos distintos, e o resto é renderização.
O sintoma de algo maior
Durante décadas, a resposta por defeito a "precisamos de uma ferramenta para X" foi "alugue-a". Construir a sua era caro, lento e uma distração do seu produto real, por isso cresceu toda uma indústria a vender ferramentas estreitas, por posto, cada uma a fazer razoavelmente um único trabalho para toda a gente. A fronteira entre construir e alugar situava-se bem do lado do "alugar", e a maior parte das ferramentas internas vivia no lado errado de um custo de construção que ninguém conseguia justificar.
Essa linha mudou. Com um agente de programação com IA no processo, uma pequena equipa pode agora construir uma ferramenta interna à medida — moldada ao seu problema exato, e não à média dos problemas de mil clientes — no tempo que antes se levava a avaliar fornecedores. O Demo Studio não foi um projeto de um trimestre. Foram uns quantos dias concentrados, e encaixa na nossa realidade de dois temas, sete idiomas e movimento constante melhor do que qualquer produto de uso geral alguma vez conseguiria, porque foi construído precisamente para isso e para mais nada.
Vale a pena determo-nos nesta parte. Boa parte do ecossistema de software como serviço assenta na velha economia de construir ou alugar — no pressuposto de que construir a sua própria versão de uma ferramenta estreita é antieconómico, pelo que pagará por posto para sempre. Quando o custo de construir a coisa feita à medida se desmorona, esse pressuposto deixa de se sustentar. As ferramentas mais expostas não são as plataformas profundas e difíceis de replicar; são as finas — os produtos do género "fazemos um fluxo de trabalho bem feito e cobramos a cada utilizador por ele" que uma equipa capaz consegue agora montar internamente, ajustados exatamente à sua própria forma, numa tarde.
Não construímos um estúdio de demonstrações porque quiséssemos entrar no negócio das ferramentas de demonstração. Construímo-lo porque, de repente, ficou mais barato construir a coisa certa do que continuar a lutar com a alugada. Essa conta vai ser feita, em silêncio, em muitas empresas ao longo dos próximos anos — e, de cada vez que o for, um pouco mais daquilo que era uma subscrição passa a ser um fim de semana de código que é seu por inteiro.
Como isto se liga àquilo que fazemos
É o mesmo instinto que move o próprio promptShield. A resposta corrente a "deixe a IA ajudar com os seus documentos" é entregar os seus ficheiros a um serviço na nuvem e confiar nos termos de serviço. Nós achamos que a melhor resposta, quando a ferramenta é barata o suficiente para se construir como deve ser, é manter os dados na sua máquina e enviar à IA apenas aquilo de que ela precisa. O Demo Studio é esse instinto virado para dentro: quando construir a coisa à medida fica barato, deixe de alugar o compromisso.
