Vibe coding para cobrar por revenue share em vez de assinatura fixa

Um cliente pode enxergar valor no seu produto e mesmo assim não conseguir assinar. O que trava é o caixa dele, que não tem entrada previsível para comportar mais uma despesa fixa todo mês.

Na live "DIA 00 - Programando com IA até faturar com meu SaaS", alguém no chat perguntou a Jhonatan qual é o valor que ele entrega e como ele cobra por isso. Ele respondeu com um desenho de cobrança para o SaaS dele para igrejas, e começou pelo cliente:

"Só que a nossa ideia não é ficar tirando dinheiro de igreja. A igreja precisa crescer."

Uma igreja tem público e não tem linha de orçamento para software. Cobrar dela uma mensalidade é pedir que ela tire dinheiro de um caixa apertado antes de o produto ter gerado qualquer receita para ela.

A conta que ele fez no ar

O estado atual é o de sempre:

"Agora, se for para pagar, ele paga somente a mensalidade."

O que ele desenhou no lugar tem 2 partes. A primeira cobra a implementação:

"Talvez ela vai pagar no máximo um mês, que é a implementação."

A segunda troca a recorrência por uma fatia do que a própria igreja vende para o público dela:

"Um curso de R$ 47, seja na recorrência, seja no eh um curso nesse valor com revenue share de 50%"

"ela vai ter o lucro [música] de R$ 23%, de R$ 23. Se ela tiver 10 alunos, ela já paga a mensalidade, tá vendo?"

A legenda tem um marcador de música no meio e ele se corrige sozinho enquanto fala, então deixei a citação como saiu.

A igreja publica um curso de R$ 47 para a comunidade dela, cada venda se divide em 50%, e ela fica com R$ 23. O que era despesa fixa vira um pedaço de dinheiro que só existe se houver venda, e um mês sem venda não gera cobrança nenhuma.

O que muda entre 10 alunos e 11

"Então, a partir de 11 alunos, ele já tem uma renda para ele."

Esse número reorganiza a conversa de vendas. Na mensalidade, você precisa convencer o cliente a abrir espaço no orçamento para uma despesa nova, e o orçamento dele já estava fechado antes de você chegar. No revenue share, você mostra a partir de quantos alunos ele para de pagar e começa a ganhar: 10 cobrem o produto, e o de número 11 já é receita dele.

A objeção deixa de ser o preço e passa a ser a capacidade de venda. "Está caro" vira "eu consigo vender 11 cursos?", uma pergunta que dá para responder junto com o cliente, olhando o tamanho da comunidade que ele já tem.

Hoje o cliente ainda paga mensalidade

Ele diz "a nossa ideia" e diz "Talvez", e na mesma resposta afirma que hoje o cliente paga somente a mensalidade. O revenue share é a direção que ele desenhou ao vivo, respondendo uma pergunta do chat, e não o preço que está rodando com as igrejas clientes.

A live também não informa quanto é a mensalidade. Ele diz que 10 alunos a cobrem e para por aí, então tratar essa frase como se fosse um preço divulgado seria inventar o número. Vale ver como isso terminou em quanto cobrar por um site.

Por que o vibe coding empurra você para esse acordo

Quem constrói com vibe coding costuma chegar ao primeiro cliente antes de ter modelo comercial pronto. O produto nasce de uma conversa, roda numa semana, e a pergunta de quanto cobrar só aparece quando alguém já está usando. Nessa ordem, o primeiro cliente raramente é a empresa com orçamento de software aprovado. Costuma ser quem tem uma dor grande e nenhuma linha no orçamento para resolvê-la. Foi o mesmo caminho de vibe coding para guardar valor unitario em vez de media.

Cobrar pelo resultado do cliente é uma saída que só existe porque o custo de construir com vibe coding caiu muito. Quando a implementação custava meses de equipe, ninguém apostava a receita no esforço comercial de terceiro. Com o custo de construir baixo, dá para entregar primeiro e ganhar depois. O mesmo movimento de generalizar a solução antes de saber os seus limites aparece também em vibe coding para agendar liberacao de conteudo com um campo generico. Vale também revisar onde a generalização encontra seus limites em centralizar comentários numa caixa de entrada, onde os limites vêm da ferramenta que você escolheu, e como documentar as regras que você descobriu.

2 respostas para a mesma objeção

Em baixar a barreira de entrada do preço, outro builder ataca esse mesmo problema mexendo na altura do preço, com um plano de entrada mais barato e upgrade depois. A alavanca dele é quanto se cobra. A alavanca aqui é quem paga e quando. São 2 respostas para a mesma objeção. Qual delas cabe depende do cliente que está na sua frente, e é melhor decidir isso antes da reunião.

Minha análise sobre o que pode dar errado

O que vem abaixo é leitura minha, não está na live.

Revenue share transfere o seu risco para a capacidade de venda do cliente. Se a igreja nunca vender curso nenhum, você entregou a implementação e não recebe recorrência. O seu faturamento passa a depender do esforço comercial de outra pessoa, que é a variável que você menos controla.

Tem um requisito de produto escondido nessa decisão de preço: o dinheiro precisa passar pelo seu produto. Se a venda acontece fora dele, no boleto, no grupo, na secretaria, você depende do cliente declarar quanto vendeu, e cobrança baseada em autodeclaração vira atrito todo mês.

50% é confortável no começo e fica caro para o cliente quando dá certo. Com poucos alunos ninguém questiona a divisão. Com muitos, o cliente vai comparar a sua fatia com o que pagaria numa mensalidade fixa, e a comparação não vai favorecer você. Desenhe desde já o teto, ou a migração para preço fixo, antes de o cliente pedir.

Dá para assistir à live e ouvir a resposta inteira, improvisada para o chat.

O que fazer antes de fechar um acordo desses

Escreva os 2 pontos em que o acordo deixa de servir, um de cada lado. Abaixo de que volume ele não paga o seu trabalho, e acima de que volume o cliente vai querer sair. O intervalo entre os 2 é o tempo de vida do acordo, e você precisa conhecer esse intervalo antes do cliente. Quando escrever essa definição, inclua também como o agente vai se comportar durante as mudanças de modelo: instrução negativa é o que segura a série quando o agente tenta atalhos que quebram o padrão do produto. E antes de testar qualquer fluxo que sai do software, certifique-se de estar em ambiente local, não no servidor do cliente.