Avaliações negativas de app no vibe coding: como filtrar o que vale

A avaliação de nota mínima é a única fonte gratuita que descreve um produto depois que o dinheiro trocou de mãos. Nenhuma pesquisa de mercado vai te avisar que a compra do concorrente não restaura quando o usuário formata a máquina. A ficha da loja avisa, de graça, na letra de quem passou por isso.

Martin tem uma agência de marketing, se descreve como iniciante em vibe coding e estava escolhendo qual app ia construir. Abriu a ficha de loja de um app concorrente da categoria, clicou em ver todas as avaliações, filtrou nota uma estrela e foi lendo em voz alta, uma por uma. Abrir a lista já é mais do que a maioria faz, mas o que salva a leitura é o passo seguinte: ele descartou parte das notas mínimas sem nem considerar.

Ler uma por uma, em vez de pedir um resumo

Ele não pediu para a IA resumir o sentimento dos usuários. Foi na fonte:

Ver todas as avaliações. Nota uma estrela.

Um resumo achata a diferença que importa. Uma linha dizendo que os usuários reclamam da cobrança cobre tanto quem acha caro quanto quem pagou e perdeu o acesso, e essas duas pessoas mandam você construir coisas opostas. Só a reclamação inteira, com a sequência de eventos que a pessoa viveu, serve de requisito.

Reclamação de defeito e reclamação de quem nunca ia pagar

A primeira que ele leu era sobre anúncio. Ele descartou na hora:

Botar anúncio por tudo. Ah, o cara quer usar de graça também. Não quer pagar.

E emendou que o sujeito não quer nem ver um anúncio ali. Nota mínima também é o lugar onde escreve quem nunca ia pagar por nada, e quem lê sem filtro importa essa fúria inteira para dentro do próprio roadmap.

A reclamação vale quando descreve uma promessa quebrada, e não vale quando descreve o modelo de negócio funcionando como foi anunciado. Anúncio e plano pago são o modelo rodando. Cobrar duas vezes pela mesma licença é outra coisa.

Se o que te interessa é o eixo do preço, já tratamos disso em o que a avaliação revela sobre o modelo de cobrança. Aqui a conversa é sobre quem já pagou.

O que sobrou depois do filtro

As reclamações que passaram têm todas o mesmo formato: alguém entregou dinheiro ou dado ao app e não recebeu de volta o combinado.

- houve reclamação de que o app não estava permitindo criar usuário gratuito - alguém reinstalou o sistema operacional e, ao instalar de novo a versão paga que já tinha comprado, o app pediu uma nova compra - alguém comprou a versão paga e perdeu o acesso numa atualização - segundo outro avaliador, o app bloqueou a contagem de dias sem cigarro dele para forçar a compra

As duas mais duras estão escritas assim:

mas precisei reinstalar o sistema operacional e quando tentei instalar a versão pro que já havia pago, o aplicativo pede para fazer uma nova compra.

O app fez o bloqueio de todas as minhas contagens desde meu último cigarro para adquirir o Pro.

Nenhuma das duas fala de preço. Na primeira, a licença comprada evaporou junto com o sistema operacional. Na outra, o app pegou o dado que o próprio usuário tinha produzido, o tempo dele sem fumar, e usou como refém para vender a versão paga. Uma lista dessas funciona como especificação do que não fazer, e chega pronta antes de você escrever qualquer linha.

Os defeitos de operação que quem faz vibe coding sozinho esquece

Restaurar compra é o exemplo mais claro. A loja te dá a API, mas o caso só aparece quando alguém troca de aparelho ou formata o computador, o que costuma acontecer meses depois do lançamento, com você já olhando para outra tela. Ninguém abre um card de restauração de compra no primeiro dia de projeto.

Com moderação acontece a mesma coisa:

O chat dentro do app não é moderado. Tem anúncio de site, blog, canal do YouTube, download pirata de livros, ofensas.

O chat entra no produto como funcionalidade de comunidade, funciona, atrai gente, e aí atrai também quem divulga o próprio canal e quem posta link de download pirata. O defeito não está no código do chat, que provavelmente roda bem. Está em não ter ninguém do outro lado, nem uma regra escrita sobre o que pode ser postado ali.

Os dois problemas mais graves daquela lista são de operação. Quem faz vibe coding sozinho entrega a tela redonda e empurra a operação para depois, e a fila de nota mínima do concorrente mostra em público onde esse adiamento costuma parar. O rigor que vale aplicar aparece também em guardrails no vibe coding, onde se escreve o que proibir.

O que fazer com isso amanhã

Antes de escrever a primeira linha, abra a ficha do app mais parecido com o que você quer construir, filtre nota mínima e leia até as reclamações começarem a se repetir, o que costuma custar poucos minutos. Vá separando em duas pilhas conforme lê: promessa quebrada de um lado, modelo de negócio funcionando do outro.

A primeira pilha vira sua lista de requisitos, e costuma vir cheia de coisa que nenhum tutorial cobre: o fluxo de restauração de compra, a regra de quem pode postar o quê, o que acontece com o dado do usuário quando ele deixa de pagar. Essas descobertas, junto com as outras dimensões que você avalia, entram na matriz quando é hora de escolher entre ideias de SaaS. A segunda pilha te diz quem não é seu cliente: se o cara já reclama de ver anúncio no app do concorrente, ele não vai virar seu assinante. O mesmo problema apareceu em vibe coding para salvar regras positivas e negativas em markdown. Vale ver como isso terminou em ideias para app.

Dá para ver a leitura acontecendo, avaliação por avaliação, na live em que ele escolheu o app. É o trabalho barato e sem glamour que o vibe coding permite fazer sozinho, sem time de produto e sem pesquisa contratada.