Sinal e parcelas no projeto freelance: quanto pedir de entrada e como dividir o pagamento por marcos (sem financiar o cliente)

Você fechou o projeto. R$ 24 mil, quatro meses, cliente animado. Na hora de falar de pagamento, ele sugere: “pago metade quando começar e metade quando estiver pronto”. Parece justo, e você aceita. No terceiro mês, você percebe que o “pronto” depende do cliente mandar os textos, aprovar o layout e testar no celular da sócia. Os textos não chegam, e a segunda metade também não.

Pode ter sido de outro jeito: você não pediu entrada nenhuma, com medo de assustar o cliente. Trabalhou seis semanas, entregou a primeira versão e só então descobriu que o cliente “estava esperando um investidor”. Se você já passou por alguma dessas situações, o problema não foi o contrato nem o cliente. Foi o cronograma de pagamento. Você deixou o cliente montar esse cronograma por você.

Pagamento no final é crédito sem juros que você dá ao cliente

A verdade desconfortável é esta: quando você trabalha antes de receber, está financiando o projeto do cliente. Sem juros, sem garantia e sem análise de crédito. Nenhum banco faria isso, e você faz porque parece educado.

A conta é simples. Pense num projeto de R$ 24 mil em quatro meses, com 50% de entrada, e num custo de vida de R$ 8 mil por mês. Os R$ 12 mil da entrada cobrem um mês e meio. Os outros dois meses e meio, R$ 20 mil, saem do seu bolso até a parcela final cair. Isso se ela cair no dia combinado. Na prática, a entrega final atrasa por motivos que não dependem de você: conteúdo do cliente, revisão da loja de aplicativos, homologação do time de TI dele.

O cronograma de pagamento não é detalhe administrativo. É a parte da proposta que decide se você chega ao fim do projeto com caixa ou no cheque especial.

Quanto pedir de sinal no projeto freelance: a regra das semanas cobertas

Esqueça o percentual mágico. O sinal certo paga o trabalho até o primeiro marco que o cliente consegue ver funcionando. A gente pensa assim:

1. Calcule o custo das primeiras semanas. Setup, arquitetura, autenticação, modelagem do banco. O cliente não enxerga esse trabalho, mas ele consome de 3 a 5 semanas num projeto médio.
2. O sinal precisa cobrir esse período inteiro. Se a sua hora vale R$ 150 e você fatura 30 horas por semana no projeto, quatro semanas dão R$ 18 mil. Num projeto de R$ 45 mil, isso é 40%.
3. Nunca abaixo de 30%. Com menos que isso, você continua financiando o projeto, mesmo com entrada.
4. O código só começa depois que o sinal cair. O Pix caiu, o kickoff é marcado. Antes disso, nenhum repositório é criado.

Vou te falar como funciona do lado de quem recebe os leads: o cliente que trata 30% de entrada como absurdo raramente é o cliente que paga a última parcela em dia. O sinal filtra cliente, além de garantir caixa. Quem já separou o dinheiro do projeto não se assusta com ele.

Como dividir as parcelas por marcos: o modelo por tamanho de projeto

Depois do sinal, o resto do valor precisa estar amarrado a entregas, não a datas soltas nem ao “quando ficar pronto”. Esta é a divisão que usamos como ponto de partida:

A lógica da tabela: quanto maior e mais longo o projeto, menor deve ser a fatia que depende da entrega final. É na entrega final que está o maior risco de atraso que não depende de você.

O gatilho de cada parcela precisa ser objetivo

“Parcela 2 quando o cliente aprovar o módulo de cadastro” é um gatilho ruim. A aprovação depende da agenda do cliente, do humor dele e de ele ter testado. Um gatilho bom pode ser conferido por qualquer pessoa:

• Entregável disponível em ambiente de homologação, com o link enviado por escrito.
• Prazo de aceite definido: o cliente tem 5 dias úteis para apontar problemas dentro do escopo. Sem retorno nesse prazo, o marco conta como aceito e a parcela é faturada.
• Bug pontual não segura parcela. Ele entra na lista de correções e é resolvido no ciclo seguinte, mas o marco está entregue.

Sem esse aceite tácito, o cronograma de pagamento é só uma lista de desejos. Ele precisa estar escrito no contrato, com essa redação, e repetido na proposta.

Discovery e manutenção ficam fora do parcelamento

Se o projeto começa com uma fase de descoberta paga, ela é cobrada à parte e quitada antes do orçamento final. A manutenção depois da entrega também é outro contrato, mensal. Quem mistura tudo na mesma parcela acaba dando três meses de suporte sem perceber.

Os erros de cronograma de pagamento que quebram o caixa do freelancer

As situações abaixo a gente viveu na pele ou viu acontecer com devs próximos.

A última parcela presa à aprovação da loja

“Pago o restante quando o app estiver na App Store.” A revisão da Apple não depende de você. E a conta de desenvolvedor costuma estar no nome do cliente, que demora para pagar a taxa ou para responder um pedido de informação da loja. O gatilho certo é “build enviado para revisão”, não “app publicado”.

O prazo de pagamento corporativo que ninguém leu

Empresa média e grande costuma pagar 30, 45 ou 60 dias depois da emissão da nota fiscal. Se o seu marco vence no dia 10, você emite a nota e o dinheiro só cai um ou dois meses depois. Pergunte o ciclo de pagamento antes de fechar e aumente o sinal para cobrir esse buraco.

O projeto longo sem cláusula de paralisação

É o projeto de oito meses parcelado por entregas que trava porque o cliente sumiu por três semanas. Sem marco entregue, não há parcela, e você fica parado sem receber. Inclua uma cláusula simples: se o projeto ficar parado por mais de 15 dias por responsabilidade do cliente, as parcelas seguem o calendário original ou o projeto é reprecificado.

Começar “só para adiantar”

O cliente pede para você começar enquanto o financeiro dele processa o sinal. Você começa, porque quer mostrar boa vontade. Duas semanas depois, o sinal ainda não caiu e você já está dentro do projeto, sem poder de negociação. Sem sinal, sem código. Sem exceção.

Do lado de quem repassa projetos: o que a OCA espera de um parceiro

A OCA aparece no Google e nas IAs quando alguém procura desenvolvimento de software no Brasil. Isso gera dezenas de leads por dia, mais do que o nosso time sênior consegue atender. Por isso estamos montando uma rede de parceiros: devs seniores e pequenos times que recebem projetos já qualificados e com escopo definido pela OCA.

Quando a gente avalia um parceiro, olha justamente para esse tipo de maturidade:

• Você sabe montar sinal, marcos e aceite sem improvisar?
• Você comunica o que entregou de um jeito que o cliente consiga aprovar?
• Você tem trabalho em produção para mostrar, do mesmo nível do portfólio de projetos da OCA?
• Você segura o escopo sem brigar com o cliente?

Em troca, o parceiro recebe projetos que já passaram por uma conversa de qualificação, de clientes que sabem o que querem construir. Não prometemos volume nem aceitação: cada projeto vai para quem combina com o stack e tem disponibilidade. Mas se você já entrega bem, o seu problema não é técnico, é distribuição. E demanda é o que a OCA tem de sobra.

Próximo passo: refaça o cronograma de pagamento da sua próxima proposta

Pegue a última proposta que você enviou e reescreva a seção de pagamento com três números: o percentual do sinal calculado pelas semanas cobertas, os marcos com gatilho objetivo e o prazo de aceite em dias úteis. Se algum deles não couber numa frase, ainda não está pronto para entrar no contrato.

E se você quer receber projetos repassados por quem já tem a demanda, manda uma mensagem:

Entre para a rede de parceiros da OCA