Radar de Obras
Produto de dados B2B para licitações
Validei o produto inteiro antes da primeira linha de código.
O contexto
§ produto próprioRadar de Obras é um produto meu, não um cliente. SaaS/DaaS B2B que coleta editais de licitação pública, filtra, dá score por relevância e entrega as oportunidades curadas via WhatsApp pra fornecedores de material de construção em Mato Grosso. Rodou em produção de abril a junho de 2026. Hoje está pausado.
Construí esse case ao contrário do reflexo de designer: nada de abrir o Figma e desenhar tela. A pergunta que importava era anterior. Existe dor real? Quem sente? Vale resolver? Validei o produto inteiro antes da primeira linha de código. O que segue é a decisão de produto primeiro; a interface que ela gerou aparece como prova, não como ponto de partida.
Processo
§ discovery → entrega8 rodadas de pesquisa até a dor real aparecer
Rodei 8 rodadas de pesquisa de ICP com deep-research e painéis de IA, mais benchmark dos concorrentes: ConLicitação, Effecti, AlertaLicitação. Todos vendem a mesma promessa: "ache o edital". A pesquisa mostrou que esse não é o problema. O lojista até acha o edital. O que ele perde é a oportunidade, porque o balcão consome o dia inteiro. Ninguém tem tempo de garimpar portal de licitação entre um cliente e outro. A dor não era de busca, era de atenção.
ICP destilado, 16 anti-ICPs, foco em 3 clusters
Destilei a persona do comprador e, mais útil ainda, mapeei 16 anti-ICPs: quem parece cliente mas não é. Saber pra quem você não vende afia o produto tanto quanto saber pra quem você vende. Em vez de "plataforma de licitações" genérica, escolhi 3 clusters de fornecedores pra atacar. Os requisitos passaram a ser centrados num operador leigo, alguém que não vai ler manual nem aprender filtro avançado. Se exige treino, falhou.
Arquitetura de informação que reduz carga cognitiva
Decisão de IA deliberada: separei o painel de negócio do painel de saúde técnica. O lojista vê só oportunidade, score e ação. A saúde do scraper, fila e logs ficam num painel à parte, longe dos olhos de quem só quer saber se vale dar lance. Misturar os dois é o erro clássico que afoga o usuário leigo em ruído. O scoring é adaptativo: aprende com o comportamento, sobe o que o fornecedor abre e responde, desce o que ele ignora.
PAINEL DE NEGÓCIO → oportunidade · score · ação · WhatsApp
PAINEL DE SAÚDE → scraper · fila · logs · erros (fora da vista do lojista)
No ar, com "Cliente Zero" como loop de qualidade
Produto entrou em produção. Antes de expor a qualquer usuário pagante, criei o mecanismo "Cliente Zero": eu mesmo na ponta, recebendo as oportunidades curadas e checando se o filtro entregava sinal e não lixo. É um loop de QA da relevância, não um teste de usabilidade. Editais que vazavam o score viravam ajuste no peso. O objetivo era garantir que, no dia em que alguém pagasse, o WhatsApp dele só recebesse oportunidade que valia a leitura.
A interface
§ a decisão virou telaUtilitária de propósito: o operador é leigo, zero treino. Cada tela materializa uma decisão do produto, não enfeite.
As 4 fases
§ pass A → DEm números
§ peso do discoveryIA como copiloto de pesquisa, do discovery ao código
Todo o discovery (deep-research, painéis de decisão com múltiplos modelos), os planos e a própria construção foram conduzidos com Claude Code e agentes. Validar produto com IA como copiloto de pesquisa é o meu jeito de trabalhar.
Produto próprio, sem cliente pagante. O "Cliente Zero" é um QA interno de qualidade do filtro, não teste de usabilidade com usuário externo. Não houve teste A/B nem protótipo em Figma (a especificação era textual). A interface em produção é utilitária de propósito, operador leigo e zero treino; este case mostra a decisão de produto e o discovery que a sustentam, com as telas reais como evidência.