Duzentas pessoas. Uma só trabalhava com e-mail marketing.
Era sexta-feira, meia-noite. Tinha duzentas pessoas me assistindo construir uma ferramenta ao vivo.
Eu perguntei quem ali trabalhava com gestão de e-mail marketing.
Uma pessoa.
As outras 199 estavam acompanhando meu processo. Queriam entender como eu construía, quais ferramentas usava, como fazia aquilo funcionar.
Eu tinha passado meses tentando criar um produto para gestores de e-mail. Só que as pessoas estavam pedindo acesso à ferramenta que eu tinha feito para mim, para conseguir desenvolver aquele produto.
Eu tinha a audiência certa e estava oferecendo a coisa errada.
O Overclock virou um negócio quando eu aceitei olhar para isso. Mas, para entender por que essa decisão foi difícil, eu preciso voltar ao negócio que eu já tinha.
A pergunta que deu origem à palestra
Quando recebi o convite para falar no Scale or Die, fiquei pensando na diferença entre crescer e escalar.
Se eu vendo cem mil reais investindo cinquenta mil em tráfego e, no mês seguinte, vendo duzentos mil investindo cem mil, dobrei as vendas. Também dobrei o investimento.
O que eu queria descobrir era como aumentar a receita sem precisar aumentar a estrutura na mesma proporção.
Foi com essa pergunta que organizei a minha jornada: construir em público, usando vibe coding, rumo a um milhão de reais em vendas.
Um milhão era a meta. Eu ainda estava no caminho.
No momento deste relato, eram 73 dias de jornada, 207 clientes e R$ 450 mil de ARR, a receita recorrente anualizada. Esse número não significa R$ 450 mil já recebidos. Na operação, eu estava com zero funcionários e sem investimento em tráfego pago.
Eu estava começando a construir minha presença em outro mercado. Porque, no e-mail marketing, eu já tinha uma história.
O cliente que me mostrou a ameaça
Meu nome é Laschuk. Eu já tinha vendido mais de vinte milhões de reais por meio de e-mail marketing. Minha empresa de e-mail tinha faturado sete milhões, e o negócio estava crescendo.
Eu revendia uma ferramenta. Um cliente podia me pagar para usar aquela plataforma, como já acontecia. Mas agora podia ter alguém na equipe construindo uma ferramenta interna com IA.
Até que recebi um cancelamento exatamente por esse motivo.
O cliente estava migrando para uma plataforma que a própria empresa estava desenvolvendo com vibe coding.
A ameaça tinha chegado à minha operação. Eu precisava entender o que conseguiria oferecer para continuar sendo útil àquele cliente.
Foi daí que veio a ideia: criar um agente capaz de operar a ferramenta de e-mail marketing. Um agente que ajudasse a mandar campanhas, montar automações e executar o trabalho que alguém ainda precisava fazer dentro do software.
Meses construindo sem mostrar
Minha aproximação com IA tinha começado antes. Usei o ChatGPT para escrever textos de e-mail. Depois comecei a copiar códigos que ele gerava e executar scripts, mesmo sem entender o que estava escrito ali.
Em 2025, passei a construir no Lovable.
Uma palestra sobre agentes verticais ajudou a dar forma à ideia. Eu queria que o cliente dissesse aonde pretendia chegar e que o agente conduzisse as etapas, pedindo as confirmações necessárias.
Essa era a minha aposta para o e-mail marketing.
Passei meses naquilo. Gastei cerca de doze mil reais no Lovable desenvolvendo a ferramenta, quase sempre dentro da minha própria caverna.
Até que minha mulher me chamou a atenção: eu fazia coisas que surpreendiam ela todos os dias, mas precisava mostrar aquilo para outras pessoas.
Resolvi abrir uma série de lives. A ideia inicial era construir em público até vender um milhão de reais com e-mail marketing.
Na primeira live, apareceram duas pessoas. Ficaram comigo por seis horas.
No final, perguntei se elas eram gestoras de e-mail.
Nenhuma das duas era. Elas tinham ficado para me ver construir.
O primeiro sinal já estava ali.
Eu queria continuar construindo, mas precisava mudar o jeito
Enquanto as lives continuavam, comecei a questionar meu jeito de desenvolver.
Eu estava pagando por uma ferramenta que usava modelos de IA para escrever código. Quis entender se conseguia trabalhar diretamente com esses modelos, nos arquivos do meu computador.
Descobri os terminais.
De um lado, eu conversava com a IA. Do outro, acompanhava o resultado no navegador. Consegui continuar construindo com uma organização que me era familiar.
Só que uma janela começou a parecer pouco.
Eu pedia uma coisa e esperava. Queria avançar em outra tarefa ao mesmo tempo. Então abri uma segunda janela.
Agora eram dois agentes trabalhando.
E um novo problema apareceu: um mexia nos arquivos do outro.
De duas janelas a um time
Eu precisava organizar o trabalho entre os agentes. Coloquei um coordenador acima dos dois executores: alguém para pensar no plano e distribuir as tarefas.
Foi assim que cheguei a três panes na tela.
Também precisava lidar com os limites das minhas assinaturas. Se usava um modelo caro em todas as tarefas, consumia a cota rápido demais.
Passei a usar Opus no planejamento e Sonnet na execução. Eu estava tentando reservar o modelo mais caro para o trabalho em que ele fazia diferença.
Durante uma das lives, uma pessoa ameaçou atacar o aplicativo e ele saiu do ar. Fui pesquisar como revisar as vulnerabilidades. Naquele momento, escolhi experimentar o Gemini nessa função.
Abri mais um terminal.
Agora havia planejamento, execução e revisão. Cada agente tinha uma responsabilidade.
O que continuava difícil era fazer todos trabalharem juntos de um jeito organizado. Então construí um aplicativo para conectar aqueles terminais e continuar usando minhas assinaturas.
Era uma ferramenta interna. Eu a tinha feito para conseguir desenvolver o meu agente de e-mail marketing.
O pedido que mudou o produto
As pessoas entravam nas lives e perguntavam como eu estava usando os modelos daquele jeito. Até que começaram a perguntar como faziam para ter acesso ao Overclock.
Eu ainda pensava nele como uma ferramenta minha.
Foi nessa fase que a conversa com a audiência deixou a situação clara: quase todo mundo estava ali por causa do processo de construção. A ferramenta que eu usava para trabalhar despertava mais interesse do que o produto que eu estava tentando vender.
Entre a live 16 e a 17, parei por três dias.
Precisava tomar coragem para sair do mercado de e-mail marketing e entrar de cabeça em vibe coding. Era abandonar a direção em que eu vinha investindo meses de trabalho.
De uma sexta para um domingo, transformei aquela ferramenta interna em algo que pudesse ser comercializado.
O nome vinha do conceito de overclock no hardware: aumentar a capacidade de processamento de uma máquina. Era a ideia que me interessava para aquele aplicativo, aproveitar melhor as ferramentas que eu já tinha.
Eu tinha começado a construir o Overclock para resolver um problema meu. Agora havia gente pedindo para resolver o mesmo problema com ele.
O primeiro cliente perguntou pelo Windows
Lancei a primeira versão para Mac, que era o computador em que eu estava construindo.
Preparei uma condição especial para o primeiro assinante. Eu queria usar aquela primeira venda para dar o passo de entrar no programa de desenvolvedores da Apple e assinar a distribuição do aplicativo.
O primeiro cliente assinou. Comemorei ao vivo.
Então ele perguntou como fazia para baixar a versão para Windows.
Eu nem tinha parado para pensar nisso.
Prometi entregar em 48 horas. E, em 48 horas, lancei a versão para Windows.
Ela veio cheia de bugs. O cliente começou a usar, reportar os problemas, e eu fui corrigindo. Nesse intervalo, já estávamos saindo de um assinante para quinze, vinte pessoas.
Eu deixava claro que o aplicativo podia quebrar. As pessoas viam a construção acontecer e eu ia atrás do que elas precisavam.
Só que vender trouxe uma responsabilidade nova: agora tinha gente dependendo daquilo. Eu precisava corrigir e entregar mais rápido.
As próximas prioridades vieram de quem estava usando
Cheguei a pensar em contratar alguém. Ao mesmo tempo, queria descobrir quanto conseguiria avançar organizando melhor o meu próprio processo.
Criei um Discord. Abri um espaço para as pessoas pedirem melhorias. No momento deste relato, a comunidade já reunia 2.500 pessoas conversando sobre vibe coding.
Uma demanda apareceu várias vezes: custo.
Para muita gente no Brasil, manter as assinaturas necessárias para desenvolver pesava no orçamento. A comunidade começou a trazer alternativas e a pedir compatibilidade com outros modelos.
Quando surgiu uma oportunidade de acesso a tokens da Xiaomi, perguntaram se dava para usar aquilo no Overclock.
Fomos atrás e fizemos a integração. Pessoas da comunidade conseguiram suas cotas e passaram a desenvolver com esse acesso.
Quem usava o aplicativo estava me mostrando o que faltava nele. E a questão do custo me levou a olhar com mais cuidado para a escolha dos modelos.
Qual modelo resolve esta tarefa?
Eu já tinha percebido uma diferença quando parei de usar Opus para tudo e passei a dividir o trabalho com Sonnet. Conseguia continuar entregando e preservar mais da minha cota.
Também comecei a prestar atenção nas instruções que cada agente recebia. Uma boa skill dá um processo para ele seguir. O harness reúne as condições em que aquele modelo vai trabalhar.
Isso passou a fazer parte da minha escolha: o modelo, a tarefa e a forma de executar.
Só que toda semana surgiam novos lançamentos. Eu não conseguia acompanhar todos, e cada um vinha com uma apresentação dizendo em que era melhor.
Melhor para qual trabalho?
No meu dia a dia, eu precisava corrigir bugs, mexer em banco de dados, construir páginas, fazer criativos e outras tarefas bem diferentes entre si.
Um resultado geral de benchmark não respondia sozinho qual modelo eu deveria usar em cada uma delas.
Comecei a testar com o trabalho que eu realmente fazia
Peguei meu histórico de prompts e comecei a fazer uma bateria de testes com as tarefas do meu próprio desenvolvimento.
Eu queria observar três coisas: se o agente entregava o que foi pedido, quanto tempo levava e qual era o custo.
Porque havia dois erros possíveis. Gastar um modelo caro numa tarefa simples. Ou colocar um modelo que não dava conta numa tarefa difícil e ficar tentando consertar o resultado.
A pergunta ficou muito mais concreta: para este trabalho, qual combinação entrega melhor?
Essa busca foi mudando o produto. Eu queria que a organização das tarefas e a escolha dos modelos fizessem parte do fluxo de desenvolvimento.
Do pedido ao trabalho dividido
Foi nesse caminho que comecei a trabalhar com a ideia de um ambiente agêntico de desenvolvimento: o Overclock ADE.
Pensa no pedido para criar um site.
Antes de sair construindo, há coisas para esclarecer. Qual é o negócio? Para quem é a página? Existe uma referência? O que precisa estar pronto no final?
Depois vem a pesquisa. Olhar referências, entender ofertas e estudar como outros negócios apresentam uma solução. Com isso, dá para especificar o que será desenvolvido.
Você acompanha essa definição e aprova o caminho. A partir daí, o trabalho pode ser dividido entre agentes, cada um com uma tarefa e com as instruções de que precisa.
Na demonstração que eu descrevo, esse fluxo chega a abrir quinze panes executando atividades diferentes.
É a evolução daquela organização que começou com poucas janelas na minha tela: esclarecer o pedido, planejar, distribuir o trabalho e revisar o que foi entregue.
O aplicativo pronto trouxe a pergunta sobre vendas
Conforme outras pessoas começaram a construir seus aplicativos, apareceu uma dificuldade que eu conhecia bem: como vender aquilo.
E aqui no Scale or Die tem uma sala cheia de gente do mercado digital, gente que entende de venda.
No meu caso, as lives tinham ajudado a aproximar quem se interessava pelo trabalho. As pessoas acompanhavam as decisões, os problemas, as correções. Foi assim que a demanda pelo Overclock apareceu.
Criei então o movimento Vibe em Public para incentivar outras pessoas a abrir uma live e construir também.
Eu queria reunir gente mostrando o próprio processo, enquanto desenvolvia o próprio negócio.
A prova estava acontecendo ao vivo
Quem vende sabe como pode ser difícil conseguir um depoimento. O cliente usa, tem resultado, mas sente vergonha de gravar ou simplesmente não manda o vídeo.
Com as lives, começamos a ter outro tipo de registro: pessoas usando o aplicativo por horas, construindo diante de quem quisesse acompanhar.
No momento deste relato, já eram mais de setecentas horas de pessoas fazendo vibe coding com o Overclock.
Isso mostrava o uso acontecendo. Não significava que todo projeto tinha dado certo ou que todo mundo já estava faturando.
Para incentivar quem estava começando, passei a direcionar minha audiência para uma dessas lives no final da minha transmissão.
Eu encerrava a minha e convidava as pessoas a continuar acompanhando alguém da comunidade.
Assim, mais gente ganhava a oportunidade de mostrar o trabalho. O movimento crescia com pessoas construindo o próprio negócio em público.
E o trabalho que volta amanhã?
Desenvolver a primeira versão do aplicativo resolvia uma parte. No dia seguinte, continuavam chegando pedidos, melhorias e tarefas da operação.
Quando conheci o Grok Bot, vi ali uma possibilidade: usar um computador operado por um bot para receber uma demanda, executar o trabalho e devolver a entrega para aprovação de quem tinha pedido.
Quis experimentar esse fluxo com o Overclock.
Fizemos uma simulação ao vivo com a comunidade. O pedido era simples: criar uma aparência vermelha para o aplicativo, com um fundo vermelho.
O fluxo recebeu a demanda, executou, gerou a versão e entregou a mudança.
Era uma alteração pequena. Mas tinha percorrido o caminho do pedido até a entrega. Foi isso que me interessou.
Eu passei a enxergar uma forma de lidar com parte das solicitações sem precisar contratar alguém naquele momento.
As rotinas que comecei a colocar nesse fluxo
Havia outras tarefas recorrentes na minha operação.
Eu queria manter a Jornada atualizada com os resumos das lives. Queria avisar no Discord quando alguém da comunidade entrasse ao vivo. E queria transformar as transmissões em textos que pudessem ser encontrados por quem pesquisava sobre vibe coding.
Comecei a distribuir essas rotinas entre bots.
Cada uma tinha uma finalidade: registrar o que aconteceu, ajudar a comunidade a se encontrar e reaproveitar o conteúdo que já estávamos produzindo.
Eu estava tentando fazer o negócio funcionar também nas tarefas que se repetiam todos os dias.
Outro problema meu virou desenvolvimento
Ao usar o Grok Bot, encontrei novas limitações para o que eu queria fazer. Havia o custo de outra assinatura e a vontade de poder escolher qual modelo conduziria o trabalho.
Eu queria aproveitar melhor os acessos que já tinha, inclusive usando outros modelos na coordenação.
Foi daí que veio o Overclock Bot. Peguei as telas do Grok Bot como referência e construí uma primeira versão em 24 horas, ao vivo.
A proposta era facilitar a configuração de um computador remoto para executar aquelas rotinas e ampliar a escolha dos modelos utilizados.
Mais uma vez, eu tinha encontrado uma dificuldade enquanto operava meu negócio. Fui construir uma solução para ela e comecei a disponibilizá-la para quem precisava do mesmo tipo de trabalho.
Eu também precisava produzir para vender
Enquanto o produto evoluía, eu tentava entender o conteúdo que gerava assinaturas.
Comecei a perceber funções diferentes nas lives e nos vídeos. As transmissões aproximavam a comunidade. Alguns vídeos ajudavam a mostrar o que estava acontecendo no produto e despertavam intenção de compra.
Só que postar criava mais uma tarefa: editar.
Eu podia contratar um editor ou fazer sozinho. Resolvi construir um fluxo para cuidar dessa parte também.
O desafio que eu tinha colocado no começo da jornada aparecia de novo: como fazer a operação avançar aproveitando melhor o que eu já tinha à disposição.
O trabalho continuava existindo. Eu estava mudando a maneira de executá-lo.
Um problema que não tinha nada a ver com o meu aplicativo
No início de 2026, meu pai recebeu um diagnóstico de esclerose múltipla.
Houve um problema no laudo, e o tratamento foi negado. Eu passei horas tentando entender os exames e o que estava impedindo o acesso.
Usei o Claude para me ajudar a examinar aquelas informações. A conversa levantou uma dúvida sobre o tipo da doença que constava no diagnóstico.
Procurei outro médico. Depois, conseguimos a liberação do tratamento pelo SUS, com a intenção de fazer a transferência para o plano.
Para mim, o papel da IA ali foi ajudar a investigar uma dúvida num momento em que eu estava tentando encontrar um caminho para o meu pai. A decisão sobre o diagnóstico e o tratamento continuava precisando passar por um médico.
Essa experiência fez a pergunta sobre o que eu podia construir ficar pequena perto de outra: que problema eu precisava resolver e como podia usar as ferramentas disponíveis para avançar nele?
O próximo problema
Eu comecei essa história tentando defender um negócio de e-mail marketing.
Um cliente cancelou. Fui construir um agente. Para conseguir desenvolver, montei uma ferramenta para mim. Mostrei o processo, ouvi quem estava assistindo e mudei o produto.
Depois vieram o primeiro assinante, a versão para Windows, os bugs e os pedidos de quem estava usando. Cada etapa trouxe um problema que eu ainda precisava resolver.
O milhão continua sendo a meta desta jornada. O que eu trouxe aqui foi o caminho percorrido até o momento do relato, com os resultados e os erros que aconteceram nele.
Você conhece algum problema recorrente no seu mercado? Alguma tarefa que seu cliente precisa fazer toda semana? Alguma dificuldade pela qual ele já procura uma solução?
Pode começar por aí: construir uma primeira resposta, mostrar para quem vive o problema e ouvir o que essa pessoa pede.
A ferramenta que virou meu negócio nasceu enquanto eu tentava construir outra coisa. Eu só consegui perceber isso porque tinha gente acompanhando e dizendo o que queria.
Qual problema você vai colocar na frente agora?
Obrigado.