Cliente red flag: os sinais de que o projeto freelance vai dar problema antes de você assinar

Você fechou o projeto animado. Três semanas depois, o cliente some por dez dias, volta pedindo "só um ajustezinho" que muda metade do sistema, e o pagamento da segunda parcela está atrasado. Você conhece essa história porque já viveu ela, ou porque está a um contrato de distância de viver.

A parte que ninguém te conta: quase todo projeto que azeda já dava sinal antes da assinatura. O problema não é azar, é filtro. Vou te falar como funciona do lado de quem recebe os leads: a OCA recebe dezenas de contatos por dia, e uma parte do trabalho é justamente decidir quais projetos entram e quais não entram. Depois de anos fazendo isso, os padrões ficam óbvios. Este artigo é a lista dos sinais que a gente aprendeu a levar a sério.

Por que dev freelancer aceita cliente ruim

A verdade desconfortável primeiro: você aceita cliente ruim porque tem medo de ficar sem cliente nenhum. Quando o pipeline está vazio, qualquer lead parece bom. Você ignora o sinal amarelo, racionaliza o sinal vermelho e assina.

A conta é simples. Um projeto ruim não custa só o prejuízo direto. Ele custa as semanas que você passa preso nele em vez de atender clientes bons, custa a energia mental de brigar por pagamento e custa o case que você não vai poder colocar no portfólio porque terminou mal. Um projeto de R$ 15 mil que vira quatro meses de dor de cabeça vale menos que um de R$ 8 mil que fecha em seis semanas e gera indicação.

Filtrar cliente não é arrogância. É a diferença entre freelancer que sobrevive e freelancer que constrói uma operação.

Os sinais que aparecem no primeiro contato

A maioria das red flags aparece antes de qualquer proposta. Você só precisa parar de fingir que não viu.

1. "É bem simples, coisa rápida"

Quando o cliente descreve o próprio projeto como simples antes de você analisar, ele já decidiu quanto quer pagar. Qualquer orçamento acima da expectativa dele vai virar negociação desgastante, e qualquer prazo realista vai soar como enrolação. Cliente que respeita seu trabalho pergunta "quanto custa e quanto tempo leva", não afirma.

2. Pressa sem motivo

"Preciso disso para semana que vem" sem nenhum evento concreto por trás (lançamento marcado, contrato assinado, prazo regulatório) geralmente significa desorganização, não urgência. E cliente desorganizado na venda é cliente desorganizado no projeto inteiro: feedback atrasado, material que nunca chega, decisão que muda toda semana.

3. Já passou por dois ou três devs

Às vezes o dev anterior era ruim mesmo. Acontece. Mas quando o histórico tem três desenvolvedores e todos "abandonaram o projeto" ou "não entregaram nada que presta", a constante da equação é o cliente. Pergunte em detalhe o que aconteceu. Se a resposta for vaga ou só culpar os outros, você já sabe como vai ser contada a sua parte da história.

4. Resistência a formalizar

Cliente que acha contrato "burocracia desnecessária", que quer combinar tudo por áudio de WhatsApp, ou que empaca quando você pede sinal, está te dizendo exatamente como pretende agir quando houver conflito. Acredite na primeira demonstração.

5. Pagamento como "detalhe para depois"

"A gente acerta os valores depois, primeiro me mostra o que você faria." Não. Quem trata pagamento como detalhe trata o seu trabalho como detalhe. Na OCA, condição comercial se discute antes de qualquer linha de código, sempre. Isso não é teoria, é literalmente como a gente evita 90% dos problemas de cobrança.

6. Equity no lugar de dinheiro

"Não tenho budget agora, mas te dou 10% da empresa." Sociedade é uma decisão de investimento, não uma forma de pagamento. Se você acredita no negócio e quer ser sócio, essa é outra conversa, com contrato de sociedade, vesting e tudo. Aceitar equity como substituto de pagamento é trabalhar de graça com etapas extras.

Os sinais que aparecem na conversa de escopo

Passou do primeiro filtro? Ótimo. A conversa de levantamento revela a segunda camada.

O cliente não consegue dizer o que o sistema resolve

Peça para ele descrever o problema em uma frase. Se a resposta for uma lista de funcionalidades ("quero login, dashboard, relatórios, um app e integração com tudo") sem um problema central, o escopo vai inflar sem parar, porque não existe critério para dizer não a nenhuma ideia nova.

Comparação constante com orçamento fantasma

"O outro dev falou que fazia por um terço disso." Talvez tenha falado mesmo. A pergunta que resolve: "e por que você não fechou com ele?". Cliente que usa orçamento fantasma como ferramenta de pressão vai usar pressão como ferramenta o projeto inteiro.

Muitos decisores, nenhum responsável

Quando o feedback vem do dono, do sócio, do sobrinho que "entende de tecnologia" e do gerente de marketing, cada entrega gera quatro opiniões conflitantes. Antes de fechar, defina uma pessoa que aprova. Se o cliente não aceita nomear uma, o projeto não tem dono, e projeto sem dono não termina.

Como recusar sem queimar ponte

Identificou red flag demais? Recuse bem. O mercado brasileiro de tecnologia é menor do que parece, e o cliente que você recusou com elegância hoje pode voltar maduro daqui a um ano, ou indicar alguém que presta.

• Não minta sobre agenda. "Estou sem capacidade" funciona uma vez. Prefira a versão honesta e neutra: "pelo formato que o projeto está hoje, não sou o profissional certo para ele".
• Dê um encaminhamento real. Sugira que ele documente melhor o escopo, valide a ideia com usuários, ou procure uma solução pronta se o caso for esse. Você vira referência mesmo sem fechar.
• Nunca detone o projeto. Recusar não é dar consultoria gratuita de tudo que está errado. Uma frase de contexto basta.

E existe o caminho do meio: alguns sinais amarelos se neutralizam com condição comercial. Cliente com histórico confuso mas projeto bom? Sinal de 40% ou 50% em vez de 30%, escopo fechado por escrito, marcos de pagamento curtos. Se ele aceita, o risco caiu. Se recusa, a red flag se confirmou sozinha e a decisão fica fácil.

O filtro é o que permite crescer

Se você já entrega bem, o seu problema não é técnico, é distribuição. E distribuição tem duas partes: fazer chegar lead suficiente e escolher bem entre os que chegam. A segunda parte é a deste artigo, e ela só funciona de verdade quando a primeira existe. Com pipeline cheio, dizer não custa pouco. Com pipeline vazio, todo não dói.

É aqui que entra uma alternativa que pouca gente considera: receber projeto já filtrado. A OCA aparece no Google e nas IAs para buscas de desenvolvimento de software no Brasil, e isso gera mais demanda de clientes do que o time consegue atender. A resposta foi montar uma rede de parceiros: devs seniores e times pequenos que recebem projetos repassados. E o detalhe que importa para este artigo: todo projeto repassado já passou pelo filtro descrito aqui. Cliente qualificado, escopo cercado, condição comercial definida. As red flags morreram antes de chegar em você.

O que a OCA espera de um parceiro é o que você esperaria: entrega sênior, comunicação de adulto e compromisso com prazo. O que o parceiro recebe é o que mais falta para quem trabalha sozinho: projeto vetado, sem ter que prospectar, negociar e filtrar. Você pode ver o tipo de produto que a gente constrói no portfólio da OCA.

Entre para a rede de parceiros da OCA

E independente da rede, uma ação para esta semana: escreva sua própria lista de red flags, com os três sinais que apareceram nos seus piores projetos. Cole ela perto do teclado e consulte antes de responder o próximo lead. O melhor projeto que você vai fechar este ano talvez seja o que você recusar.