Vibe coding para validar demanda antes de construir o backend

Ele subiu só o front end de um produto e rodou uma campanha real de mensagens contra essa página, com o back end ainda inexistente. Quem abria a oferta via preço e promessa, com um botão de comprar que aceitava dinheiro, e não tinha como saber que atrás do botão não havia sistema. Para descobrir se alguém pagava, o front end já era suficiente.

O teste rodou com 200 disparos e com o que ele chamou de "prazo real, dados reais". Entrou receita antes de o back end existir, e foi esse sinal que autorizou construir o resto. Jhonatan resumiu a postura em uma frase:

"o cara testa lançando, velho, tipo, valendo mesmo. Se der errado, não tem problema."

Um front end sozinho já é uma oferta inteira

O comprador lê o preço, entende o que vai receber e decide com a mesma informação que teria se o produto estivesse pronto. É por isso que a resposta dele serve para decidir alguma coisa. Ele descreveu o estado da plataforma sem enfeitar:

"na verdade não tá lançado essa plataforma aqui, é só o meu front end, tem o back end inteiro que vai ser"

A campanha correu contra essa oferta pela metade como se ela fosse a oferta do dia do lançamento, e foi assim que apareceram o prazo real e os dados reais de que ele fala.

Vibe coding para validar demanda antes de construir o backend

Uma página de vendas com preço e botão de compra é o pedaço mais barato do produto, e é justamente o pedaço que carrega a decisão de compra inteira. O que custa caro vem depois, no sistema que precisa realmente entregar o que a página promete. Construir essa parte antes de saber se a página converte é a forma mais comum de queimar semanas de trabalho em algo que ninguém queria comprar. O mesmo problema apareceu em vibe coding para renomear entidade sem quebrar link no sistema. Vale ver como isso terminou em tam sam som.

O vibe coding encurtou tanto o tempo de produzir a página que ela deixou de ser protótipo e virou instrumento de medição. Você monta a oferta em uma tarde, põe na frente de gente que pode pagar, com o preço escrito, e o que volta são compras ou silêncio, sem intermediário nenhum interpretando o resultado para você.

O canal foi WhatsApp, e o mecanismo sobrevive sem ele

A campanha foi feita por disparo de WhatsApp, 200 disparos no total. De onde vem a lista de contatos é uma decisão à parte, com regra própria, e cada um responde pela sua.

O mecanismo não depende do canal. Anúncio pago, lista de e-mail, comunidade, indicação de cliente antigo, qualquer coisa serve, desde que ponha uma oferta real na frente de gente real com preço cobrado. O que faz o teste funcionar é a oferta estar completa e o dinheiro estar em jogo.

Alguém pagar é o único sinal que não dá para fabricar

Entrou receita real antes de o back end existir. O valor fica de fora deste post: a legenda da live grafa a cifra de 2 maneiras diferentes dentro da mesma fala, e não dá para saber dali o número, a moeda nem se era recorrente. Para a decisão que estava na mesa isso muda pouco, porque o que autoriza escrever o back end é a receita ter sido maior que zero.

Um cadastro em lista de espera diz que a pessoa achou interessante. Uma venda diz que ela tirou dinheiro do bolso por uma promessa que ainda não tinha software atrás, e só esse segundo tipo de resposta paga o custo de construir o resto.

O que esse método cobra de você

Se alguém compra, você tem que entregar. Enquanto o back end não existe, entregar significa fazer na mão, mandando o material por e-mail ou executando o serviço você mesmo, cliente por cliente. Antes de subir a página, decida se consegue honrar na unha todas as vendas que a campanha pode trazer. Se não consegue, cada venda que entrar vira uma dívida com quem pagou.

Esse é o preço do "se der errado, não tem problema". O erro pode ser seu sem custo nenhum; a entrega de quem pagou continua sendo obrigação.

Como usar isso amanhã

Pegue a parte mais cara do que você planejou construir e adie essa parte. Publique a página com preço e checkout, ponha a oferta na frente de gente real por qualquer canal que você já tenha, e trate a primeira venda como autorização para construir. Quem faz vibe coding costuma usar a velocidade para entregar o produto inteiro mais cedo, e aqui ela serve para descobrir mais cedo se vale entregar. Enquanto ninguém compra, o back end continua sendo um palpite caro. Se as vendas chegarem, prospecção ativa é o canal para repetir a campanha conforme a base de leads qualificados cresce. O modelo de preço também pode mudar conforme você aprende: revenue share é uma alternativa quando o cliente não tem orçamento de assinatura. E enquanto faz tudo isso, use instruções negativas para manter o agente no padrão que aprovado: quando o resultado sai certo, documenta como e proíbe o desvio. Antes de testar qualquer fluxo que sai do software, coloque em ambiente local para não brincar com a produção do cliente. O mesmo problema apareceu em vibe coding para salvar regras positivas e negativas em markdown.

No acervo há um caminho vizinho com mecanismo diferente: em validar MVP com primeiro cliente pagante, o builder vende o serviço na conversa e entrega na unha antes de o software existir, enquanto aqui o front end vai ao ar sozinho e a campanha decide. Vale assistir à live para ver o estado real da plataforma no momento em que ele conta o que já entrou.