Vibe coding para precificar por crédito com base no custo real da API

Crédito é uma moeda que você inventa. Ela só é segura quando cada unidade está amarrada ao que a chamada custa de verdade, e a hora de amarrar é antes de anunciar quantos créditos vêm em cada plano. Thiago fez nessa ordem ao vivo, na plataforma que ele está construindo: ditou ao agente a regra que converte custo de API em crédito e só depois admitiu que a quantidade por plano continuava em aberto.

A regra que ele passou:

"precisaríamos transformar as chamadas API em créditos, com base nos valores que custa para a empresa, algo como pegar o valor em dólar ou real da chamada API, aplicar algo como 4x valor e transformar isso em [crédito]"

A conta cabe em uma linha

O exemplo que ele deu na sequência é aritmética de padaria. Uma chamada que custa US$ 1 de API entra como R$ 5,50. Multiplicada por 4, vira R$ 22,00, e esse passa a ser o valor daquela chamada para o cliente.

Ele ditou uma regra no lugar de uma tabela de preços, e essa escolha se paga com o tempo. Quem crava o valor do crédito na mão precisa lembrar de revisá-lo toda vez que o provedor reajusta ou o dólar sobe, e quase ninguém lembra a tempo. Com o multiplicador fixo, o preço do crédito sobe junto com o custo pela mesma fórmula de sempre, sem renegociação e sem nova rodada de pricing. Quem faz vibe coding costuma deixar essa parte para depois porque ela parece contabilidade, quando na prática ela é uma linha da regra que o agente vai implementar.

Por que o multiplicador não é 1

Um multiplicador 1 cobraria exatamente o que o produto paga, e o trabalho todo sairia de graça. A chamada de API é a parte visível da conta. Em volta dela tem infraestrutura ligada enquanto ninguém usa, suporte de quem responde quando o resultado sai errado, e as falhas que precisam rodar de novo e cobram 2 vezes para entregar uma. O markup existe para cobrir essa órbita antes de sobrar margem.

Nada disso transforma 4 em número universal. Foi o multiplicador que ele escolheu para o caso dele, com os custos dele. O que é portátil é o método: achar o custo unitário real e escolher um fator que cubra tudo que orbita esse custo, com folga suficiente para você não descobrir o buraco pela fatura.

A lacuna que o vibe coding deixa à vista

Fechada a fórmula, ele foi direto ao que ainda não sabia:

"Agora, quantos créditos? Eu não sei. Mas gostaria que fosse bem fácil do cliente entender."

O critério de custo estava resolvido, o pacote não, e essa ordem é o que protege. O multiplicador defende a margem; a quantidade de crédito por plano é ajuste comercial, que se mexe depois sem quebrar a conta de baixo. Ele levantou também, sem resolver, que ainda precisa fazer as contas direito para os planos não ficarem desbalanceados entre si.

Quem começa pela embalagem faz o caminho contrário. Escolhe quantos créditos ficam bonitos na tabela, publica, e só então vai medir o que cada chamada consome. Quando o custo aparece, o número já foi prometido, e a saída é mexer no preço de quem já comprou ou absorver a diferença.

Decidir o preço no meio da implementação, e não numa reunião separada, é o que o vibe coding tem de diferente de um plano de negócios escrito antes. A fórmula nasceu na frente do agente, na mesma sessão em que ele construía o produto, e o que faltava ficou dito em voz alta em vez de disfarçado de decisão tomada.

Como em qualquer regra amarrada ao agente, aqui também vale trazer um limite. Vibe coding para não deixar o agente em loop de retry sem limite mostra que regras precisam de freios, e precificar é escrever uma regra que o agente vai executar. Vibe coding para dar permissão pontual ao agente sem virar regra vai além: nem toda regra precisa ser permanente. E toda mudança de estrutura precisa separar certeza técnica de suposição: vibe coding para migrar dados sem perder historico lembra disso. Vale ver como isso terminou em como precificar pacote de servicos com vibe coding.

O acervo que cresce junto com as sessões também precisa de organização, e vibe coding para organizar varios documentos de plano sem apagar historico mostra como marcar o que morreu sem deletar a história.

O crédito que não expira quando deveria é outro piso: vibe coding para creditos anuais nao expirarem como os mensais distingue a validade da entrada do desconto de preço, e essa diferença é tudo que importa em qualquer tabela de planos. Foi o mesmo caminho de vibe coding para nao congelar rendimento de credito do fundador.

Dentro de uma sessão longa, o que separa bug de enfeite é a capacidade de nomear: vibe coding para separar bug bloqueante de polimento visual mostra como decidir em voz alta o que fica para depois, e por quê.

Quando o agente trabalha em paralelo, o critério que separa ruído de defeito real é o relatório: vibe coding para distinguir falha de worker redundante de bug real mostra como checá-lo por fora sem depender da máquina. Isso aparece também em vibe coding para validar saas por receita real.

O acompanhamento do consumo em tempo real mantém a decisão reversível: vibe coding para monitorar memoria ao rodar varios workers em paralelo mostra que o limite vem de baixo, da sua máquina, não de cima, do plano.

Uma decisão de escopo que não fica registrada volta a ser pergunta: vibe coding para congelar decisao de escopo e nao reabrir mostra por que marcar o que já foi decidido custa uma linha e economiza dias.

E quando a IA rejeita, guardar o motivo é o que a faz aprender: vibe coding para ia aprender com o motivo da rejeicao lembra que a escada de confiança sobe com feedback específico, não com reprodução cega.

O custo real vem antes do preço

No dia anterior, o mesmo builder tinha ido checar a cobrança real antes de instrumentar telemetria e descoberto que só a fatura do provedor diz como a cobrança funciona de verdade. Os dois dias encaixam nessa ordem: primeiro você sabe o custo, depois precifica em cima dele. Invertido, o multiplicador multiplica um chute.

O que fazer para montar o seu preço por crédito

Pegue uma operação do seu produto, uma só, a mais usada. Rode ela e olhe quanto ela cobrou na fatura do provedor, não na estimativa da documentação. Converta para a sua moeda com a cotação do dia e guarde esse número como custo unitário.

Liste ao lado dele o que a operação carrega junto: o servidor, o armazenamento do que ela gera, o tempo de quem atende o cliente quando o resultado sai ruim, e a fatia de execuções que falham e rodam de novo. Some esses valores ao custo unitário e divida o resultado pelo custo unitário: esse número é o piso do multiplicador, o ponto em que você empata. O seu fator fica acima dele, com a margem que você quer, e vira a regra escrita no código: custo da chamada vezes fator igual a preço em crédito.

Só depois abra a tabela de planos e decida quantos créditos cada um leva. Nessa hora a pergunta é de embalagem, e você pode brincar com ela à vontade, porque qualquer combinação que você montar já está apoiada num crédito que se paga. Rode a mesma conta em cada plano para conferir que nenhum deles sai melhor que os outros por acidente. Confira também quantas cobranças separadas cada plano coloca na frente do cliente: na mesma live ele refez o plano de agência para não cobrar assinatura e crédito ao mesmo tempo, fundindo a mensalidade por cadeira dentro do próprio pacote de créditos.

Dá para ver a regra sendo ditada, com o exemplo do dólar e o multiplicador saindo na hora, ao assistir à live.