Cap

O que é o Cap

O Cap (github.com/CapSoftware/Cap) se descreve como a alternativa open source ao Loom: gravações de tela bonitas e compartilháveis, feitas para times que querem ser donos dos próprios dados. Ele publica apps de desktop para macOS e Windows mais um painel web para ver, compartilhar e gerenciar o que você grava, e o repositório lista demos de produto, relatos de bug, onboarding, tutoriais, revisões de design, explicações técnicas, standups assíncronos e atualizações para clientes como os momentos para os quais foi construído. O código é um monorepo Turborepo: um app de desktop com SolidStart e Tauri, um app web em Next.js e crates Rust cuidando de captura, codificação, renderização e exportação.

A decisão de design que vale entender antes de instalar são os dois modos de gravação, porque eles correspondem a dois trabalhos genuinamente diferentes. O modo Instant faz upload enquanto você grava e entrega o link no instante em que você para — o que você quer para um relato de bug ou uma resposta assíncrona. O modo Studio grava localmente e abre um editor com fundos, zooms, cortes, legendas e controles de exportação — o que uma demo de landing page precisa. Recorrer ao modo caprichado quando um colega fez uma pergunta de uma linha é a forma mais comum de fazer a gravação parecer cara.

O que o repositório entrega

Retirado do README do próprio projeto, não de uma lista de desejos:

O licenciamento merece uma frase, porque "código aberto" cobre mais de um arranjo. O arquivo LICENSE do Cap divide o repositório: as famílias de crates Rust `cap-camera` e `scap-` são MIT, componentes de terceiros mantêm os próprios termos, e todo o resto é AGPLv3. Para gravar suas próprias demos essa distinção nunca aparece. Se você pretende construir um produto em cima dele ou oferecê-lo como serviço, a AGPL é uma restrição real e vale ler direito antes de começar, não depois.

Onde um gravador de tela entra no stack de crescimento de um fundador

O valor de uma ferramenta assim não é produzir conteúdo. É tirar a etapa de produção de quatro trabalhos que você já precisa fazer:

1. A demo da landing page — 60 a 90 segundos do produto fazendo o trabalho real dele, para visitantes que não vão ler três parágrafos para descobrir o que é aquilo. É o mesmo trabalho de conversão que o resto da página faz: transformar visitantes em cadastros.
2. O passo a passo de onboarding — o caminho do cadastro até o primeiro resultado útil, gravado uma vez e colocado no e-mail de boas-vindas e na documentação, que é a forma mais barata disponível de encurtar o time to value. Veja melhorar o onboarding de usuários.
3. A resposta de suporte ou de vendas — uma gravação de dois minutos respondendo exatamente à pergunta feita, no lugar de um e-mail longo que será mal lido. É aqui que o modo Instant se paga, e onde fundadores percebem primeiro o retorno da ferramenta.
4. O clipe de funcionalidade — quinze segundos de uma coisa funcionando, recortados de uma gravação e reaproveitados em changelogs, posts de lançamento e redes sociais. Distribuir esses clipes é outro problema, resolvido por ferramentas como o brightbean-studio.

Se tudo isso soma a um motivo para abrir um canal é outra pergunta, e na maioria das vezes a resposta é não — os ativos valem a pena muito antes do hábito. Essa decisão é trabalhada em devo fazer vídeos para divulgar minha startup?. E se os clipes precisarem de mais montagem do que o editor embutido cobre, o OpenCut é o editor de código aberto para acompanhar.

O limite honesto

Um gravador barateia a produção e não decide nada sobre distribuição. Uma demo que ninguém envia vale exatamente o mesmo que uma demo que ninguém fez, e o motivo pelo qual fundadores terminam com uma pasta de gravações sem uso quase nunca é a ferramenta — é que ninguém decidiu em qual página o vídeo vive, em qual e-mail ele entra ou a qual pergunta ele responde. Escolha o trabalho antes de apertar gravar.

Nota em primeira mão de construir a AgentCeres — o AI Growth Officer, em agentceres.com: a demonstração da nossa própria home é deliberadamente não uma gravação. É uma animação de chat roteirizada renderizada pela página, com o roteiro em um arquivo de código ao lado do componente e um teste que quebra a build se o mockup mostrar algo que o produto não pode fazer. O motivo é manutenção: quando a interface muda, editar uma linha do roteiro leva um minuto, enquanto uma demo gravada precisa ser regravada, remontada e reenviada — então ela envelhece e passa a anunciar um produto que você não entrega mais. Gravações são a ferramenta certa para os quatro trabalhos acima, todos eles respostas a uma pergunta em um momento específico. A demo sempre visível é a que vale construir num meio que você consegue manter atualizado.