5 erros de R$10k+ que cometi construindo 2 SaaS — e como evitar

Existe um gênero de conteúdo na internet que eu odeio: "10 erros que founders cometem". Sempre escrito por alguém que nunca lançou nada, citando Lean Startup como se fosse o evangelho, terminando com "valide antes de construir!". Obrigado, capitão.

Esse post é o oposto. São 5 erros específicos que cometi construindo o OverAir (SaaS de memória digital via WhatsApp) e o Studio Kallos (SaaS de agendamento pra estúdios de beleza). Cada um custou tempo real, dinheiro real ou ambos. Somados, passam tranquilamente de R$10.000 em custo de oportunidade — e olha que sou solo, sem folha de pagamento.

Não é um "erros que você pode cometer". É "erros que eu cometi, aqui está o estrago, e o que faria diferente". Se você está construindo algo parecido — bot WhatsApp, SaaS solo, produto com IA — esse post é seu atalho.

Antes de começar: como eu calculo "R$10k"

Quando falo R$10k+ de custo, não é dinheiro que saiu da conta direto. É a soma de:

Tempo desperdiçado valorado a R$200/h (preço modesto de um dev sênior freelancer no Brasil em 2026, segundo dados de mercado coletados no post de quanto custa terceirizar)
Custo de infra/API queimado em tokens, builds e tentativas
Custo de oportunidade: semanas em que eu poderia estar validando com cliente real

Vou explicitar a estimativa em cada erro. Não é ciência, é honestidade. E spoiler: o erro mais caro não foi o mais óbvio.

Erro 1: Pipeline de 2-3 chamadas Gemini por mensagem

Custo estimado: R$2.500 + complexidade contínua

O OverAir processa mensagens de WhatsApp (texto, áudio, imagem) e retorna uma estrutura de dados — lembrete, evento, finança, nota. Na primeira versão, eu fiz isso "do jeito certo de engenheiro":

Chamada 1: classifica a mensagem ("é um lembrete? finança? nota? ruído?")
Chamada 2: extrai os dados conforme o tipo
Chamada 3 (às vezes): gera resposta natural pro usuário

Parecia limpo. Single-responsibility por chamada. Cada prompt focado. Easy to debug.

Era uma armadilha.

O que custou:

3x o preço por mensagem: cada chamada tem overhead de input (system prompt + contexto), mesmo que mínimo. Numa pipeline de áudio, multiplica.
3x a latência percebida: cada chamada à API do Gemini soma ~600ms de TTFT (Artificial Analysis). Três chamadas = 1.8s só de latência, fora processamento.
3x o ponto de falha: se chamada 2 falhar, você fica com classificação sem extração. Mais código de retry, mais estado pra gerenciar.
Contexto fragmentado: o modelo na chamada 2 não "vê" o que o modelo na chamada 1 viu. Toda informação relevante precisa ser passada explicitamente — você reinventa o contexto a cada round-trip.

A correção: uma única chamada unificada com schema Zod que inclui um campo type no enum (lembrete | finança | nota | ruído) e campos condicionais. O modelo decide o tipo E extrai os dados E gera a resposta numa só passada.

Métrica	Pipeline 3-chamadas	Chamada unificada
Custo por mensagem	R$0,09 médio	R$0,035 médio
Latência média	~3,5s	~1,5s
Pontos de falha	3	1
Linhas de código de orquestração	~180	~40

Cortei o custo por mensagem em ~60% e a latência pela metade. O código ficou mais simples, não mais complexo. Esse é o padrão dos hacks de otimização modernos em LLM: menos chamadas e mais context caching (guia da AI Free API mostra reduções de até 90% com cache + chamada única).

Onde o tempo foi: ~2 semanas escrevendo, testando e refatorando a pipeline de 3 chamadas. Quando migrei pra unificada, em 3 dias estava em produção. 2 semanas - 3 dias ≈ 9 dias de trabalho = R$14.400 a R$200/h se eu cobrasse.

OK, calma — eu não cobro de mim mesmo. Mas o tempo foi real, e o aprendizado é: comece com a chamada unificada. Schemas Zod já dão a separação de tipos que você quer. Não precisa de pipeline para "separação de responsabilidades" quando o modelo aguenta o problema todo numa passada.

Erro 2: Não filtrar mensagens de ruído antes do Gemini

Custo estimado: R$1.500 em tokens + sinal-ruído no log

A primeira versão do OverAir mandava toda mensagem recebida no WhatsApp pra IA processar. Inclusive:

"ok"
"sim"
"👍"
"kkkk"
"obrigado"
"valeu"

Nenhuma dessas mensagens carrega informação útil. São confirmações sociais, ruído conversacional. Mas todas viraram chamadas à API do Gemini, queimando tokens em mensagens que nunca iriam virar um lembrete, finança ou nota.

Pior: o modelo, vendo "ok" isolado, às vezes alucinava — interpretava como "confirme o último lembrete" e tentava criar uma intent que não existia. Bugs aleatórios em produção.

A correção foi um filtro de pré-classificação em código puro:

const NOISE_PATTERNS = [
  /^(ok|sim|nao|não|valeu|vlw|obrigad[oa]|tmj|👍|👌|😂|kkk+)\.?$/i,
  /^[😀-🙏✨💫⭐❤️]+$/u, // só emojis
  /^\.{1,3}$/,           // só pontos
];

function isNoise(text: string): boolean {
  const trimmed = text.trim();
  if (trimmed.length < 3) return true;
  return NOISE_PATTERNS.some(rx => rx.test(trimmed));
}

Mensagens que casavam viravam um seen no chat (sem resposta, ou com emoji de reação) e nunca chegavam ao Gemini.

Em volume real, observei: ~22% das mensagens recebidas eram ruído puro. Em produção pra mil mensagens/dia, isso é 220 chamadas economizadas — ~R$7,70/dia, ~R$230/mês.

Não parece muito. Mas:

Escala: com 100 usuários ativos, vira R$23.000/mês desperdiçado.
Latência percebida: usuário manda "ok", bot demora 1,5s pra "responder ok". Parece travado. Com filtro, resposta é instantânea.
Sinal nos logs: separar ruído de intenção real torna os logs úteis pra debugging. Antes, eu rolava 200 linhas de "user: ok" pra achar um caso real.

Essa lição é geral pra qualquer pipeline LLM: filtre o que dá pra filtrar com regex/heurística antes de pagar token. O Redis chama isso de "multi-tiered evaluation" (fonte) — modelos baratos primeiro, escalando só quando necessário. Mas no caso de ruído puro, nem precisa de modelo barato. Precisa de uma regex.

Erro 3: Sistema de correção de mensagens overengineered

Custo estimado: R$4.800 — o erro mais caro da lista

Esse aqui dói de contar.

Em algum momento durante o desenvolvimento do OverAir, decidi que o produto precisava de um sistema de correção: o usuário poderia mandar "não, eu quis dizer X" depois de uma resposta da IA, e o sistema teria que:

Identificar que era uma correção
Encontrar a mensagem original alvo
Reprocessar com o feedback
Atualizar o registro original (e não criar um novo)
Manter histórico de correções pra eventual aprendizado

Achei que era essencial. Toda IA erra, certo? O usuário precisa poder corrigir.

Gastei 2 semanas construindo isso. Schema separado de correções no Firestore. Lógica de matching da mensagem original (mais complicada do que parece quando o usuário corrige horas depois). Prompt especializado de re-extração com contexto da correção. Testes pra todos os casos.

Quando coloquei em produção e abri pra os primeiros betatesters, monitorei o uso da feature. Resultado em 60 dias de operação:

Métrica	Valor
Mensagens totais processadas	~8.400
Tentativas de correção identificadas	41
Correções bem-sucedidas (matching encontrou alvo certo)	19
% de mensagens que usaram correção com sucesso	0,23%

Menos de um quarto de um por cento.

E olha que foi com betatesters técnicos, que entendem que tem um sistema de correção. Usuário comum simplesmente apaga e remanda — ou, mais comum, deixa pra lá. Ninguém quer brigar com bot.

A lição clássica do produto, agora aprendida por experiência própria: se você está polindo uma feature antes de saber se alguém vai usar, você está perdendo tempo. O guia da WeFT Technologies (fonte) coloca isso como o erro #1 de founders. Eu li esse padrão dezenas de vezes antes. Caí nele assim mesmo.

O que faria diferente: zero feature de correção no MVP. Se IA erra, usuário manda de novo — versão simples manual. Se em 6 meses eu visse demanda real (não 0,23%, algo como 5%+), aí construo o sistema. Hoje, removi parte da complexidade do código — mantive só o necessário pra não quebrar dados existentes.

Custo total: 2 semanas = ~80h = ~R$16k a R$200/h. Sendo conservador e descontando que parte virou conhecimento útil (lógica de matching tem uso em outros lugares), considero ~R$4.800 desperdiçados pra valer.

Esse é o erro mais caro dos cinco. E o que mais combina com o pattern da indústria: founders construindo o que acham que usuário quer, antes de perguntar. Não é falta de leitura — eu li o Lean Startup. É a tentação de fazer "o jeito certo" em vez do jeito mínimo.

Erro 4: Não testar com áudio real de WhatsApp durante dev

Custo estimado: R$1.200 em bugs descobertos em produção

Pipeline de áudio do OverAir: usuário grava áudio no WhatsApp → Meta entrega media_id no webhook → eu baixo o .ogg/opus → mando pro Gemini → recebo extração estruturada.

Durante o desenvolvimento, usei áudios de teste gravados pelo gravador padrão do macOS convertidos pra .ogg. Funcionou perfeitamente. Achei que tava pronto.

Aí foi pra produção. E quebrou.

Por que quebrou: o WhatsApp usa Opus codec com configurações específicas — bitrate baixo (8-16kbps típico), mono, 16kHz, com compressão agressiva pra economizar dados móveis (explicação técnica). O áudio resultante tem:

Cortes súbitos no começo e fim (VAD — voice activity detection mata silêncio)
Artefatos de compressão que confundem modelos treinados em áudio limpo
Ruído de fundo amplificado pela compressão
Pessoas falando rápido em PT-BR coloquial com sotaque regional

Meu áudio de teste do macOS era estudio comparado a isso.

Bugs específicos que apareceram em produção:

Áudio de 2 segundos com "oi" → Gemini retornava transcrição vazia. Minha pipeline assumia que sempre tinha conteúdo. Crash.
Áudio de 38 segundos com cortes → modelo pegava só o primeiro fragmento, perdia metade da informação.
Áudio em espanhol (brasileiros viajando) → modelo tentava forçar português, gerava transcrição surreal tipo "lembrar do pão" para "recordar el camino".
Áudio com múltiplas pessoas falando (pai gravando com filho gritando atrás) → modelo confundia quem era o usuário.

O que faria diferente:

Coletar áudios reais de WhatsApp desde o dia 1. Eu próprio gravava no meu WhatsApp, baixava o .ogg via export de chat, e usava no test suite. Custaria 30 minutos.
Suite de regression test com áudios reais: 20-30 áudios variados (curto, longo, ruído, sotaques, idiomas), com asserções no output esperado.
Logging agressivo na pipeline de áudio em produção com sample rate, duração, e bitrate — pra detectar quando algo foge do esperado.

Os bugs me custaram ~6 dias debugando em produção, com usuários reais reportando "bot não entendeu". ~R$1.200 em tempo + alguma perda de confiança dos primeiros betatesters. Recuperável, mas evitável.

Lição: se seu input vem de um canal específico, teste com input desse canal. Não com surrogate "parecido".

Erro 5: Display name "OverAir by Hens Desenvolvimento" sem preparar o site

Custo estimado: R$1.000 — semanas de rejeição e re-submissões

Quando o OverAir ficou pronto, fui aprovar o display name no WhatsApp Business API. Display name é o nome que aparece pro usuário quando recebe mensagem do bot — e a Meta tem um processo de aprovação manual rigoroso pra cada um.

Escolhi: "OverAir by Hens Desenvolvimento".

Erro. Múltiplos.

Razão da rejeição (critérios oficiais):

Meta não conseguiu vincular o display name a uma presença pública. Meu site (hens.com.br) existia mas não mencionava "OverAir" em nenhum lugar. Pra Meta, era um nome inventado.
"By Hens Desenvolvimento" parecia descritor de marketing/slogan, não nome de empresa. Slogans são reprovados.
Capitalização inconsistente. "OverAir" tem camelCase, "Hens Desenvolvimento" tem espaços e capitalização normal. Meta gosta de consistência.

Levou 3 ciclos de re-submissão ao longo de quase 6 semanas pra passar. Cada ciclo: submete, espera 2-5 dias úteis, recebe rejeição genérica, ajusta, repete.

Escrevi um post inteiro sobre essa saga com o passo a passo completo. Mas a lição em uma linha: prepare a presença web ANTES de submeter o display name.

O que faria diferente:

Página dedicada ao produto no domínio principal (hens.com.br/overair ou overair.hens.com.br) ANTES de submeter
Display name idêntico ao nome mostrado no site, headers, footers
Sem "by [empresa]" — submeter só "OverAir" e deixar a empresa associada via Business Verification
Business Verification completo no Meta Business Manager primeiro, display name depois

Custo: ~6 semanas de delay no lançamento pra primeiros betatesters. Em tempo direto debugando o problema, ~5 dias. ~R$1.000 + custo de oportunidade altíssimo (não dá pra mandar template marketing sem display name aprovado).

A meta-lição: validação > polimento

Se eu pudesse refazer essas decisões, o padrão comum é claro:

Erro	Padrão	Antídoto
Pipeline de 3 chamadas	"Vou fazer do jeito certo desde já"	Comece com o mais simples; otimize quando medir gargalo
Não filtrar ruído	"O modelo é esperto, vai resolver"	Heurística antes de IA sempre que possível
Sistema de correção	"Usuário vai querer isso"	Não construa antes de ver dado real
Áudio sintético	"Áudio é áudio"	Teste com input real do canal real
Display name sem site	"É só preencher um form"	Plataformas grandes têm processos rigorosos — leia primeiro

O padrão da pesquisa de mercado bate (WebPronews 2026): o erro #1 de fundadores não-técnicos é gap de validação. O #1 de fundadores técnicos é overengineering. Eu somei os dois, oferecendo um pacote completo.

O OverAir hoje tem zero clientes pagantes. Estou em validação ainda. Mas a infraestrutura está enxuta, a pipeline é simples, e cada nova feature passa pelo teste: "tem alguém pedindo isso, ou é minha cabeça?". Studio Kallos segue caminho parecido — comecei mais minimalista por já ter aprendido.

Se você está construindo algo agora, esse post vale pelo seguinte: identifique qual desses cinco padrões você está caindo essa semana. Provavelmente é um. Provavelmente você não percebeu. Volte aqui, recoloque a régua, e siga.

E se você quer construir um bot WhatsApp e está olhando pro processo de aprovação de template — meu próximo post vai cobrir exatamente isso. WhatsApp Cloud API: template de mensagem — como aprovar de primeira. Quarta-feira, dia 03/05. Feed RSS pra não perder.