Vibe coding para validar SaaS por receita real: onde cravar o piso

Um piso de receita é um número que você crava antes de abrir a lista de concorrentes, para não ir se convencendo produto por produto. Martin Blume estava montando com o assistente de código o plano da busca que ia varrer o mercado por MRR, e o rascunho já trazia um piso de 3 mil dólares por mês. Antes de mandar executar, ele parou em cima do número.

Você acredita que o piso de 3 mil é realmente um bom piso ou poderia ser mais?

Ele mesmo respondeu e subiu o corte para 10 mil dólares por mês, com nenhuma busca rodada e nenhuma ideia escolhida até ali. Revisar o piso para cima antes do primeiro resultado é a parte que quase ninguém faz, porque depois que a lista chega todo número vira negociável.

O piso entra no plano, antes de a busca rodar

Martin não é desenvolvedor e está procurando ao vivo o SaaS que vai construir. Ao abrir a conversa sobre a pesquisa, a primeira coisa que pediu foi a ordem das etapas:

vamos pensar nos fatores delimitantes o mínimo de MRR que a gente quer pra gente fazer um plano e depois sim você aplicar esse filtro e trazer as ideias aqui pra mim

Ele insistiu nisso enquanto o plano não estava fechado, com um "vamos traçar o plano primeiro antes de você sair" e, mais adiante, "Então só confirma pra mim o plano aqui antes de executar".

Piso definido depois que você já viu a lista deixa de ser piso. Aparece um produto simpático logo abaixo do corte, você monta o argumento de por que aquele caso é exceção, e a triagem termina validando o que você já queria fazer. Martin ainda mandou aplicar o mesmo corte no acervo inteiro, sem abrir exceção por nicho: "Você vai refazer no banco de dados como um todo".

Por que 3 mil dólares por mês não filtravam quase nada

O piso de 3 mil veio no rascunho do plano e ele não engoliu: "Eu acho que é meio baixo não". Em seguida pediu a conta da poda, "como você acha que vai diminuir pra se a gente colocar acima de 10 mil dólares, por exemplo?", porque queria saber quanto da lista sobreviveria ao corte mais alto antes de escolher onde cortar.

Um piso baixo demais custa caro justamente porque parece rigor. Você anota 3 mil dólares de MRR no plano e sai com a sensação de ter sido criterioso, enquanto a lista volta praticamente do mesmo tamanho que voltaria sem filtro nenhum.

A decisão veio com a conta feita em voz alta:

Vamos definir o piso para 10 mil dólares por mês E 10 mil dólares por mês é 120 mil dólares por ano, né? Que dá uns 600 mil reais

A conversão para reais é conta de cabeça dele, no ar, e ele se embola na sequência da frase. O que vale copiar ali é traduzir o piso mensal para o horizonte de 1 ano, na moeda em que você paga as suas contas. 10 mil dólares por mês é fácil de escrever sem sentir peso nenhum. A versão anual você julga na hora, porque ela se compara com salário e com o tempo que você vai gastar construindo.

A outra metade do filtro é o seu próprio limite

Um piso alto sozinho aprovaria os concorrentes mais pesados da base, que faturam bem porque têm anos de engenharia dentro. Por isso Martin cravou, no mesmo plano, uma restrição sobre ele mesmo: quer "Facilidade de ser construído por mim", "levando em consideração que eu não sou um desenvolvedor sênior ou alguma coisa assim".

Antes de ver qualquer resultado ele também mandou fora o candidato que depende de aprovação de API restritiva de terceiro e o que for "uma coisa que seja disfarçada de SaaS porque tem trabalho manual". Para quem faz vibe coding sem base técnica, essa parte pesa tanto quanto o piso de receita: adianta pouco achar um produto muito acima do corte se manter aquilo de pé exige um time. Foi o mesmo caminho de vibe coding para distinguir falha de worker redundante de bug real. Vale ver como isso terminou em ideias de saas.

O que uma receita alta prova, e o que ela não prova

O piso de 10 mil dólares por mês prova uma coisa, e ela vale o trabalho de filtrar: existe gente pagando todo mês por aquela categoria de produto. Isso derruba o erro mais caro do começo, que é passar meses construindo solução para uma dor que ninguém nunca aceitou pagar para resolver. O outro caminho para a mesma pergunta é testar a procura com o produto ainda por existir, que é o vibe coding para validar demanda antes de construir o backend: a receita alheia mostra que a categoria tem dinheiro, a sua própria fila de interessados mostra se querem de você. Foi o mesmo caminho de vibe coding para importar produto por sitemap ou planilha.

O que a receita do concorrente não prova é justamente o que você mais quer saber, se você conseguiria construir aquilo e se ainda sobra espaço para mais um. Martin apontou outro limite no fim da live, ao comentar que uma base de receita só enxerga quem escolheu aparecer: "gente que está fazendo dinheiro provavelmente está quietinha na sua". Um piso alto seleciona categorias com dinheiro circulando, e a sua chance dentro delas continua uma pergunta aberta depois que o filtro roda.

Onde cravar o seu piso na próxima sessão de vibe coding

Antes de abrir qualquer lista, escreva 2 coisas: o piso mensal com o equivalente em 1 ano na sua moeda, e o limite do que você consegue construir e manter sozinho. Vale ver como isso aparece também em arquivo de contexto no vibe coding. Rode a busca com as 2 restrições fixadas e leia o que voltar. Se a primeira leva vier cheia de coisa que você mesmo descartaria à primeira vista, o piso estava frouxo, então suba o número e rode de novo, que foi o que Martin fez com o 3 mil. Vale ver como isso terminou em o que e mcp.

O corte dele é 10 mil dólares por mês porque é ele quem vai construir e é ele quem decide o que compensa 1 ano de trabalho. O seu depende do que você quer que esse produto pague. Dá para assistir à live e ver a decisão ser tomada em voz alta, com conta de cabeça e tudo. A live acaba com o plano fechado e a busca ainda por rodar, o que é bem a cara do vibe coding feito às claras, com o critério gravado antes do resultado.