Sinal, parcelas e marco de entrega: como estruturar o pagamento de um projeto freelance para não trabalhar de graça

Você fechou o projeto, combinou o valor, apertou a mão virtual no WhatsApp e começou a codar. Seis semanas depois, entregou tudo. Aí o cliente some, pede "só mais uns ajustes antes de pagar" ou solta a clássica: "o financeiro paga em 45 dias". Você trabalhou um mês e meio financiando a empresa dos outros com o seu tempo. Se isso já aconteceu com você, o problema não foi o cliente. Foi a estrutura de pagamento que você aceitou, ou melhor, que você não definiu.

Vou te falar como funciona do lado de quem recebe os leads: a OCA fecha projetos todo mês, repassa outros tantos para parceiros, e a diferença entre projeto tranquilo e projeto que vira cobrança judicial quase sempre está em como o pagamento foi desenhado antes da primeira linha de código.

A verdade desconfortável: quem entrega primeiro e cobra depois assume todo o risco

Dev bom tende a pensar assim: "entrego um trabalho excelente e o pagamento é consequência". Não é. Pagamento é consequência de contrato e de estrutura, não de qualidade. O cliente pode adorar seu código e mesmo assim atrasar três meses porque o caixa dele apertou.

Quando você trabalha sem sinal e recebe tudo no final, você está, na prática, emprestando dinheiro para o cliente. Um empréstimo sem juros, sem garantia e sem data firme de retorno. Nenhum banco faria isso. Você faz porque tem medo de perder o projeto se "complicar" a negociação. A conta é simples: perder um projeto na proposta custa zero horas trabalhadas. Perder um pagamento depois de seis semanas de trabalho custa seis semanas.

O modelo que funciona: sinal + marcos de entrega

O formato que a OCA usa nos próprios projetos, e que exigimos dos contratos que repassamos para parceiros, tem três blocos:

1. Sinal de 30% a 40% antes de começar

O sinal não é só dinheiro adiantado. Ele é um filtro. Cliente que se recusa a pagar sinal está te dizendo, antes do projeto começar, como ele trata pagamento. Cliente sério entende que sinal é padrão de mercado: reserva sua agenda, cobre o setup inicial e prova que existe orçamento real do outro lado.

Em projetos de R$ 15 mil a R$ 60 mil, que é a faixa comum de sistemas web e apps de escopo médio no Brasil, 30% de sinal é aceito sem drama pela maioria dos clientes. Se o projeto é pequeno, abaixo de R$ 8 mil, considere 50% na entrada. O custo administrativo de cobrar parcela pequena atrasada não compensa.

2. Parcelas amarradas a marcos, não a datas

Aqui está o erro mais comum: parcelar por calendário ("30% dia 15, 30% dia 30"). Se o projeto atrasa por causa do cliente, que não mandou os acessos, não aprovou o layout, sumiu por duas semanas, você fica sem receber por um atraso que não causou.

Amarre cada parcela a uma entrega verificável:

• Marco 1: ambiente configurado + telas principais navegáveis. Libera parcela 2.
• Marco 2: fluxo principal funcionando em homologação (cadastro, checkout, o que for o coração do sistema). Libera parcela 3.
• Marco final: deploy em produção + repasse de acessos. Libera a última parcela.

Regra de ouro: o marco seguinte só começa depois do pagamento do anterior. Isso precisa estar escrito na proposta. Não é grosseria, é o mesmo mecanismo que qualquer fornecedor sério usa. E tira de você o papel constrangedor de cobrar: o próprio cronograma cobra.

3. A última parcela nunca pode ser a maior

A parcela final é a que mais atrasa, porque depois da entrega o cliente perde a urgência. Se você deixou 40% para o final, deu ao cliente 40% de motivo para enrolar. Estruture algo como 35% / 35% / 20% / 10%. A última parcela deve ser pequena o suficiente para que, no pior cenário, o calote nela não destrua sua margem.

Repasse de código e acessos: sua única alavanca real

Depois que o cliente tem o código no repositório dele e as chaves de produção na mão, sua capacidade de negociar cai para perto de zero. Então trate o repasse como parte da estrutura de pagamento:

• Durante o projeto, o código fica em repositório seu, com o cliente acompanhando por ambiente de homologação.
• Transferência de repositório, domínio, credenciais de infra e documentação acontece após a quitação, e isso está escrito no contrato.
• Se o cliente exige o repositório na conta dele desde o início (algumas empresas exigem, e é legítimo), compense aumentando o sinal e encurtando os marcos.

Isso não é teoria, é literalmente como a OCA opera. Já vimos parceiro entregar produção completa com 50% em aberto "porque o cliente pediu para adiantar o lançamento". O lançamento saiu. O pagamento, não.

Quando o cliente atrasa: o roteiro em três etapas

Mesmo com estrutura boa, atraso acontece. O que separa o profissional do amador é a resposta:

1. D+1 do vencimento: mensagem neutra, sem drama. "Oi, a parcela do marco 2 venceu ontem, consegue verificar com o financeiro? Enquanto isso, o marco 3 fica pausado conforme combinamos na proposta." Você não está ameaçando, está executando o contrato.
2. D+7: pausa efetiva do trabalho, comunicada por escrito, com data. Continuar trabalhando com parcela vencida ensina o cliente que o prazo de pagamento é decorativo.
3. D+30: notificação formal (e-mail com aviso de que o caso vai para cobrança). Com contrato assinado e marcos documentados, uma ação de cobrança de valor até 40 salários mínimos cabe no Juizado Especial Cível, sem advogado obrigatório até 20 salários. Na maioria dos casos, só a notificação formal já destrava o pagamento.

O detalhe que muda tudo: esse roteiro só funciona se estava combinado antes. Pausar projeto sem cláusula de pausa vira briga. Pausar com cláusula vira cumprimento de acordo.

As armadilhas que ainda pegam dev experiente

• "Confio nele, é indicação": indicação reduz risco de má-fé, não risco de caixa. A empresa indicada também pode ter um mês ruim. Estrutura de pagamento não é desconfiança, é higiene.
• Aceitar boleto de 30/60/90 depois da entrega: isso é condição de fornecedor de commodity, não de serviço especializado. Se a empresa só trabalha assim, embuta o custo financeiro no preço ou recuse.
• Misturar pagamento do projeto com pagamento da manutenção: são contratos separados. Manutenção mensal não pode virar moeda de troca para quitar parcela atrasada do desenvolvimento.
• Dar desconto para "pagamento tudo no final": é o inverso do racional. Receber depois vale menos, não mais. Se alguma condição merece desconto, é o pagamento antecipado.

Como isso funciona quando o projeto vem repassado por uma software house

Uma das razões pelas quais devs entram para redes de parceria é justamente tirar essa camada de risco da frente. Quando a OCA repassa um projeto para um parceiro, o cliente já passou pelo funil: proposta assinada, sinal pago, escopo fechado e estrutura de marcos definida. O parceiro entra para executar com as regras de pagamento já cercadas, em vez de negociar sozinho com um cliente desconhecido.

A OCA recebe mais leads por dia do que consegue atender, e a rede de parceiros existe para absorver esse excedente com projetos já vetados. O que esperamos do outro lado é o básico que este artigo descreve: profissionalismo comercial no mesmo nível da entrega técnica. Se você já entrega bem, o seu problema não é técnico, é distribuição, e estrutura.

Entre para a rede de parceiros da OCA

Uma ação para esta semana

Independente da rede: pegue sua próxima proposta e reescreva a seção de pagamento com quatro linhas. Sinal de 30% para iniciar. Duas parcelas amarradas a marcos verificáveis. Última parcela de no máximo 10% na entrega final, com repasse de código condicionado à quitação. Cliente que aceita isso sem drama é cliente com quem vale trabalhar. Cliente que briga com essa estrutura acabou de te economizar seis semanas de prejuízo.