Criar um clone do WhatsApp com InsForge

Vamos diretos ao assunto. Este post não é sobre copiar o WhatsApp pixel a pixel nem sobre montar a demo perfeita para postar no LinkedIn. É sobre mostrar como trabalharia hoje um programador que sabe delegar bem em agentes, usando InsForge como backend e deixando a IA tratar da parte pesada sem perder completamente o controlo.

O resultado final parece mais um Discord minimalista com estética de WhatsApp do que um clone puro. E sinceramente, ainda bem. Para um MVP isso faz muito mais sentido: login, salas públicas, mensagens em tempo real e deploy rápido. Se quiseres mexer no código, o repositório público é este: github.com/edunavajas/whatsapp-clone.

A ideia não era copiar o WhatsApp, era mostrar um fluxo real

O objetivo do vídeo não era exibir interface. Era mostrar até onde consegues ir hoje se montares bem o ambiente. A jogada foi começar do zero, criar o repositório, ligar o backend e deixar que o agente tratasse primeiro da definição e depois da implementação.

O repositório é criado publicamente no GitHub e descarregado em local com o habitual:

git clone https://github.com/edunavajas/whatsapp-clone.git

No vídeo também aparece este comando para confirmar que a instalação da skill realmente deixou a sua marca no projeto:

ls -la

Aqui entra uma das primeiras decisões inteligentes do fluxo. Antes de começar a despejar código à maluca, instala-se uma skill do género “Grill with Docs” para o agente fazer perguntas e aterrar o alcance. Isto é exatamente o contrário do vibe coding sem travões. Primeiro defines o que raio queres construir e só depois te pões a fazê-lo.

E aqui chega a parte que eu mais sinto falta em muitos conteúdos deste género: o que fazes depois de clonar para não ficares só a olhar para a pasta sem saber por onde pegar. O caminho sensato é este. Primeiro instalas dependências e arrancas a app localmente para confirmar que o frontend pelo menos respira antes de meter backend, autenticação ou realtime. Se isso já falha, não vale a pena andares a caçar fantasmas na camada de dados.

No fluxo menciona-se npm install, mas depois o trabalho continua com pnpm, por isso o coerente é escolher uma ferramenta e ficar com ela até ao fim:

pnpm install
pnpm run dev

Com isso já deves conseguir abrir a app em local e validar o básico: carrega sem rebentar, os ecrãs principais existem e não estás perante um starter meio partido desde o minuto zero. Não é preciso dramatizar. Basta confirmar que o ambiente arranca, que o login faz sentido visualmente e que a estrutura do clone já lá está.

Depois sim, em paralelo levantas o projeto no InsForge, escolhes uma região europeia por latência e autenticas a CLI para o editor conseguir falar com a instância sem andares a copiar configurações estranhas à mão. O detalhe importante aqui é que o próprio fluxo deixa pronto um project.json com os dados de ligação, e isso fica fora do commit graças ao .gitignore. Isso está bem pensado, sem dúvida.

A sequência saudável seria: clonar, instalar, arrancar em local, ligar o backend e só então pedir ao agente que comece a mexer em tabelas, políticas e realtime. Se saltas essa ordem, acontece o costume: deixas de saber se o erro é do frontend, do ambiente, da auth ou de uma interpretação meia torta do alcance por parte do agente.

O bom MVP não é o que enfia mais coisas, é o que menos atrapalha

Assim que o agente começa a fazer perguntas, o projeto deixa de ser “faz-me um WhatsApp” e passa a ser algo bem mais razoável. Define-se como uma app web, não como uma app móvel. Permite multiutilizador, mas sem números de telefone. As salas são públicas para qualquer utilizador autenticado. As mensagens são só texto. Não há edição, não há apagado e não há ficheiros no MVP. Ao entrar existe uma sala geral e, além disso, cada utilizador pode criar no máximo uma sala própria.

Sinceramente, aqui está uma das lições mais úteis do vídeo: se não limitares o alcance, o agente dispersa-se. E quando se dispersa, gera mais código, mais contexto e mais lixo. Por isso o autor separa a conversa de definição da conversa de implementação, guarda o contexto em memória e até muda de modelo para a fase de picar código. Isto não é teatro. É gestão de contexto. Se enches a janela com demasiado histórico, o modelo começa a ficar difuso, e depois a malta culpa a IA quando o problema real é que lhe atirou para cima um caos monumental.

Onde o InsForge muda mesmo o jogo

É aqui que está a graça toda. O InsForge não é só uma base de dados bonita. É o backend completo que o agente consegue operar a partir do editor: autenticação, realtime, regras de segurança, tabelas, políticas e deploy. Se vens de Supabase, a ideia vai soar-te familiar num instante, mas com uma diferença importante: todo o fluxo foi muito mais pensado para trabalhar com agentes.

O post anterior que publiquei sobre InsForge já ia nessa direção, mas neste exemplo isso vê-se de forma muito mais crua. O agente deteta que precisa de backend, cria as tabelas de mensagens e salas, adiciona triggers, configura políticas e deixa o realtime pronto para o chat funcionar sem montar manualmente a infraestrutura do costume.

E isso importa porque o MVP deixa de ser um monte de frontend com mocks. Aqui tens login real, dados reais e sincronização em tempo real entre dois utilizadores diferentes. Aliás, essa é a validação-chave do vídeo: abrir duas contas distintas em dois separadores, escrever numa e ver a mensagem aparecer na outra no mesmo instante.

Se clonares o repositório para repetir a experiência, essa é também a validação que eu faria quando a configuração estiver pronta: primeiro confirmar que consegues iniciar sessão, depois entrar numa sala, a seguir enviar uma mensagem e, por fim, abrir outra sessão separada para verificar que o realtime não é só fogo de vista. Se uma dessas quatro peças falha, o MVP ainda não está fechado, por muito bonita que a interface pareça no screenshot.

Se quiseres experimentar o mesmo tipo de abordagem sem montar o teu backend à unha, deixo outra vez o link do InsForge com UTM, porque é precisamente a peça que faz este fluxo ter sentido.

O melhor do vídeo é que também mostra as asneiras

Ainda bem. Se não, parecia o típico tutorial aldrabado em que tudo funciona à primeira e depois ninguém em casa consegue reproduzir aquilo.

A primeira iteração não fica grande coisa. O design não respeita totalmente a referência carregada a partir de design.md, o login por email falha e o frontend não transmite bem essa sensação de clone do WhatsApp que se procurava. Depois vem uma segunda iteração, corrige-se o login com Google e volta-se a apertar com o agente para ele respeitar melhor o design.

Depois aparece outro problema bem mais sério: as mensagens não se mostram corretamente e o fluxo do chat continua sem fechar bem. Nesse ponto pede-se ao agente para validar com Playwright e continuar a afinar. Isto importa porque deixa uma lição muito clara: desenvolvimento agêntico não significa desenvolvimento às cegas. Tu continuas a ter de olhar, testar, partir coisas e voltar a pedir alterações. O Jarvis ajuda; o Tony Stark continua a ter de perceber o que está a construir.

No fim, depois de várias fases, a coisa fica bastante sólida. A interface já lembra muito mais o WhatsApp, o login entra bem, há duas contas a funcionar ao mesmo tempo e as mensagens viajam em tempo real. Até se podem criar salas novas, embora o próprio vídeo reconheça uma limitação: a lista de salas nem sempre atualiza de forma limpa e às vezes é preciso refrescar para ver tudo bem. Esse tipo de honestidade editorial era importante manter porque é exatamente isso que torna o artigo credível.

Se o clonares hoje, este seria o percurso sensato

Não faz falta transformar isto num tutorial para totós, mas convém deixar bem clara a ordem mental do trabalho.

Clonas o repositório e verificas que estás no projeto certo:

git clone https://github.com/edunavajas/whatsapp-clone.git
ls -la

Instalas dependências com um único gestor e arrancas em local:

pnpm install
pnpm run dev

Com a app aberta, valida três coisas antes de continuar. Uma: o frontend arranca sem erros graves. Duas: o fluxo de login faz sentido e não parece desligado do resto. Três: a UI base do chat está lá e não é só uma capa bonita.

Depois chega a vez do backend. Se vais seguir o vídeo, é aqui que entra o InsForge: criar o projeto, autenticar a CLI, deixar pronta a ligação local e permitir que o agente monte auth, tabelas, políticas e realtime. Neste ponto não estás a “configurar por configurar”. O que procuras é que o projeto deixe de assentar em fumo e possa trabalhar com utilizadores e mensagens reais.

A última verificação é a que realmente interessa: duas sessões diferentes, dois utilizadores diferentes e uma mensagem a atravessar de uma para a outra em tempo real. Se isso funciona, a demo está viva. Se além disso conseguires criar uma sala e voltar a entrar sem partir nada, melhor ainda.

Os comandos que aparecem no fluxo

Como no vídeo aparecem comandos concretos, deixo-os aqui bem formatados. Alguns pertencem ao projeto e outros ao fluxo de validação local.

Para clonar o repositório:

git clone https://github.com/edunavajas/whatsapp-clone.git

Para verificar os ficheiros gerados pela instalação de skills:

ls -la

Para instalar dependências, o agente propõe primeiro npm install, embora depois o vídeo mude para pnpm por preferência pessoal:

npm install

E esta é a variante que acaba por ser usada para trabalhar em local:

pnpm install
pnpm run dev

Há um momento em que se menciona a instalação de uma skill de design com um comando mostrado no ecrã, mas a transcrição literal não conserva a cadeia completa. Não a inventei do nada porque isso seria vender fumo. Se quiseres reproduzir esse passo exato, o sensato é ir ao vídeo e ao link referido lá.

O que importa mesmo não é esse comando solto. O que importa é a ordem do conjunto: dependências, servidor local, backend ligado e validação com dois utilizadores. É isso que separa uma demo bonita de um MVP que pelo menos se aguenta em pé.

O que me parece realmente útil nesta abordagem

Sejamos honestos: o interessante não é o clone do WhatsApp. O interessante é o padrão. Defines o MVP, ligas o backend, deixas o agente propor e executar, revês o que ele fez, corriges as partes fracas e fazes deploy só quando o resultado já passa um mínimo filtro humano.

Isso remove uma quantidade absurda de fricção. E num produto pequeno ou numa prova de conceito nota-se imenso. Ainda mais quando o backend já te resolve autenticação, regras de segurança e realtime. O vídeo insiste bastante nisto e com razão: se a segurança das tabelas, o login e o controlo de acesso já forem tratados pelo InsForge, tiras de cima da mesa uma das partes mais delicadas do MVP.

Agora, isso não significa que possas desligar o cérebro. Para um produto sério, com utilizadores reais, arquitetura mais complexa ou regras de negócio mais finas, tens de pensar mais, rever mais e desenhar bastante melhor. O próprio vídeo deixa isso claríssimo. Isto é uma demonstração de fluxo, não um convite para delegares TUDO e depois ficares a rezar.

Repo, deploy e uma conclusão honesta

O clone final é colocado em produção a partir do próprio ecossistema do InsForge, com domínio gerado pela plataforma e sem teres de montar outra novela de alojamento por fora. Essa parte também é potente porque fecha o ciclo: definição, implementação, backend e deploy dentro de um fluxo bastante compacto.

Se quiseres olhar para o código com calma, aqui tens outra vez o repositório: github.com/edunavajas/whatsapp-clone. E se quiseres experimentar a ferramenta que torna possível quase todo o backend deste exemplo, aqui vai novamente o InsForge.

No fim de contas, a mensagem do vídeo não é “vejam, a IA programa sozinha”. A mensagem certa é outra: se souberes limitar o alcance, separar contexto, rever iterações e apoiar-te num backend pensado para agentes, consegues tirar um MVP funcional ridiculamente depressa. E sim, isso muda bastante as regras do jogo.

Se quiseres, depois de leres este post recomendo também ver o vídeo anterior sobre InsForge e comparar os dois enfoques: um mais conceptual e este muito mais de trincheira. É aí que realmente se percebe porque este tipo de tooling está a começar a fazer diferença.

O que você achou?

Deixe sua opinião, pergunta ou sugestão. Os comentários são sincronizados com GitHub Discussions .