Condições de pagamento no freelance dev: quanto pedir de entrada, como dividir em marcos e quando entregar o código

Você fechou o projeto. Escopo cercado, proposta aprovada, cliente animado. Aí vem a pergunta que muito dev responde no impulso: "e o pagamento, como funciona?". Com medo de perder o negócio, sai um "pode pagar na entrega". Três meses depois o sistema está 90% pronto, o cliente sumiu por duas semanas para "alinhar internamente" e você já bancou 200 horas de trabalho do próprio bolso. Se você entrega bem, o seu problema quase nunca é técnico. Nesse caso específico, é fluxo de caixa. Este artigo é sobre o que definir antes do primeiro commit: quanto pedir de entrada, como dividir o restante em marcos e em que momento o código passa para o nome do cliente.

Pagamento na entrega é você financiando o cliente

Quando você aceita receber só no final, você virou banco. Está emprestando seu tempo, sem juros e sem garantia, para uma empresa que conheceu há duas semanas. Um projeto de R$ 30 mil em dez semanas com pagamento no final é um empréstimo de R$ 30 mil a juro zero, com risco de calote concentrado em uma única parcela. Nenhum outro fornecedor do seu cliente aceita isso. A gráfica pede 50% para rodar a impressão. O contador cobra o mês adiantado. A agência de marketing fatura antes de subir a campanha.

Tem um segundo efeito, menos óbvio: cliente que ainda não pagou nada não tem pele no jogo. Ele some na homologação, demora para mandar o conteúdo, muda de ideia sem sentir custo nenhum. A entrada não é só proteção financeira. É o que faz o projeto andar do lado dele.

Vou te falar como funciona do lado de quem recebe os leads: na OCA, todo projeto por escopo começa com entrada. Sem exceção, inclusive para cliente indicado e para cliente grande. Em anos fazendo isso, não lembro de um projeto bom que a gente perdeu por causa da entrada. Quem trava nessa etapa costuma ser exatamente o mesmo perfil que travaria na última parcela.

Quanto pedir de entrada: por que 30% é o piso

A conta é simples. A entrada precisa cumprir três funções ao mesmo tempo: cobrir o seu custo até o primeiro marco, provar que o cliente tem orçamento real e reduzir o tamanho da parcela final, que é onde o risco mora. As faixas que funcionam na prática, por porte de projeto:

• Projeto pequeno (até R$ 10 mil, duas a quatro semanas): 50% na assinatura e 50% na entrega. Marco intermediário aqui é burocracia que não paga o próprio custo.
• Projeto médio (R$ 10 mil a R$ 50 mil, um a três meses): 30% a 40% de entrada, o restante em dois ou três marcos, com a última parcela em 20% ou menos.
• Projeto grande (acima de R$ 50 mil, mais de três meses): 30% de entrada, marcos mensais ou por entrega funcional, última parcela de 10% a 15%.

A regra que resume tudo: a última parcela nunca pode ser maior do que você aguenta perder. Se ela representa 50% do projeto e o cliente atrasa, você perdeu metade do trabalho. Se representa 15%, dói, mas não quebra o mês. Duas regras complementares vão direto para o contrato: a entrada não é reembolsável depois do kickoff, e o trabalho só começa quando o valor compensar na conta, não quando o contrato for assinado.

Como dividir em marcos sem virar refém da aprovação

O erro clássico é amarrar o marco à "aprovação do cliente". Parece razoável, mas na prática você acabou de atrelar o seu pagamento à agenda de outra pessoa. Cliente viaja, troca de gerente, entra em fechamento de trimestre, e o seu marco fica em aberto por seis semanas com o trabalho pronto.

A solução é amarrar o marco à entrega, não à aprovação. Entrega significa: código em ambiente de homologação, acessível para o cliente, com um vídeo curto demonstrando o que foi feito. A partir daí corre um prazo de aceite, geralmente cinco dias úteis. Sem retorno nesse prazo, a entrega é considerada aceita e a parcela vence. Isso precisa estar escrito no contrato e repetido na proposta, senão não vale nada na hora do aperto.

Um exemplo real de estrutura para um aplicativo de R$ 45 mil em doze semanas, com backend, app iOS e Android e painel administrativo:

1. 35% na assinatura (R$ 15.750). Libera o kickoff após compensação.
2. 25% na semana 5: backend, autenticação e fluxo principal do app em homologação.
3. 25% na semana 9: versão beta distribuída via TestFlight e teste interno do Google Play, com painel administrativo funcional.
4. 15% na semana 12: publicação nas lojas e transferência do repositório.

Repare que cada marco é algo que o cliente consegue abrir e testar. Marco baseado em "70% do backend concluído" não serve, porque ninguém consegue verificar isso e a discussão vira opinião. Marco baseado em "o usuário consegue se cadastrar, fazer login e comprar um ingresso em homologação" é verificável em dez minutos.

Quando entregar o código e em nome de quem ficam as contas

Aqui separa quem já se queimou de quem ainda vai se queimar. Existem duas coisas diferentes: o código e a infraestrutura. Elas seguem regras opostas.

O código fica no seu repositório durante o projeto, com o cliente tendo acesso de leitura desde o primeiro dia. Isso é transparência, não concessão: ele vê o progresso real, você não precisa provar que está trabalhando. A transferência de propriedade do repositório acontece na quitação da última parcela. Isso não é chantagem, é a cláusula padrão de cessão de propriedade intelectual condicionada ao pagamento integral, e qualquer advogado que já viu contrato de software conhece. O que você não pode fazer é usar isso para segurar código de um cliente que pagou tudo e só está discutindo um bug.

A infraestrutura é o inverso: tudo em nome do cliente desde o início. Conta do Supabase, projeto na Vercel, Apple Developer, Google Play Console, domínio, gateway de pagamento. Isso protege você mais do que protege ele. Você não quer o seu cartão pagando servidor de um cliente que sumiu, nem quer ser o responsável legal pelos dados de usuários de um produto que não é seu. Na Revo, nosso próprio produto, as contas estão no nosso nome porque o produto é nosso. Em projeto de cliente, a regra é o cliente criar as contas e te dar acesso como colaborador. Se ele não sabe fazer, você senta com ele em uma call de 30 minutos e cria junto, no e-mail dele.

E o deploy em produção? Só acontece depois que a parcela anterior compensou. O build final para as lojas é o último marco, e a publicação sai junto com a última parcela. Cliente que diz "preciso do app no ar para começar a faturar e te pagar" está te pedindo para virar investidor sem participação. A resposta é não, com educação, mas é não.

As armadilhas que quebram freelancer nessa etapa

Situações que eu já vi de perto ou já vivi. Se alguma soar familiar, é sinal de que a sua proposta precisa de uma seção de pagamento mais dura.

• Começar antes da entrada cair. "Já assinei, pode começar". Você começa, faz duas semanas de trabalho, e a entrada "está com o financeiro". Nesse momento você perdeu toda a alavancagem: já investiu e ainda não recebeu nada. Não começa sem compensação, mesmo que o cliente seja simpático.
• "Pago quando o produto começar a faturar". Isso é sociedade sem contrato social. Se você quer aceitar risco de negócio, cobre participação de verdade, com contrato. Se não quer, cobre em dinheiro e nas datas combinadas.
• Nota fiscal como pretexto. O cliente aprova, aí avisa que só paga com NF e você não tem CNPJ estruturado. Resolva isso antes de mandar a primeira proposta, não depois do primeiro marco.
• Prazo de pagamento corporativo sem ajuste nos marcos. Empresa grande paga 30 ou 45 dias após a nota. Não tem problema, mas então a nota do marco sai no dia da entrega em homologação, não no dia da aprovação. E a entrada precisa cair antes do kickoff, mesmo que isso atrase o início em um mês.
• Marco de aprovação sem prazo. Já falamos, mas vale repetir: sem prazo de aceite tácito no contrato, você não tem marco, tem esperança.
• Desconto errado. Dar desconto para pagar na entrega é o pior negócio possível: você reduz o preço e aumenta o risco. Se quiser oferecer desconto, ofereça no sentido contrário: até 10% para quem paga 100% adiantado. Acontece mais do que parece com empresa fechando orçamento de fim de ano.

O que muda quando o projeto chega repassado

Tudo acima pressupõe que você está negociando sozinho, com um cliente que você mesmo prospectou. Existe outro cenário. A OCA aparece no Google e nas respostas das IAs para buscas de desenvolvimento de software no Brasil, e isso traz dezenas de leads de clientes por dia, mais do que a equipe consegue atender. Isso não é teoria, é literalmente como a OCA cresceu, e você pode ver os projetos que saíram dessa máquina no portfólio da OCA. Para dar vazão, a OCA repassa projetos qualificados para uma rede de devs sêniores parceiros.

Do ponto de vista de pagamento, a diferença é grande. Quando um projeto chega repassado, a parte comercial já foi feita: escopo cercado, proposta aprovada, entrada paga e marcos definidos com o cliente. O parceiro entra com o fluxo de caixa desenhado e não precisa negociar nada disso. A relação com o cliente e o risco de cobrança ficam com a OCA.

O que a OCA espera em troca é direto: entrega sênior, comunicação clara e respeito aos marcos, porque marco atrasado é pagamento atrasado para todo mundo na cadeia. Não existe garantia de volume nem promessa de entrada na rede; existe uma conversa honesta sobre o que você entrega bem e uma primeira oportunidade para provar isso.

Próximo passo

Se você já entrega bem e quer receber projetos com a parte comercial resolvida, o caminho é esse:

Entre para a rede de parceiros da OCA

E independente disso, uma ação para esta semana: abra o seu modelo de proposta e substitua a linha de pagamento por uma seção completa. Um texto base que você pode adaptar:

Condições de pagamento: 35% na assinatura, com início dos trabalhos após a compensação. 25% na entrega do marco 1 em ambiente de homologação. 25% na entrega do marco 2. 15% na publicação e transferência do repositório. Cada entrega tem cinco dias úteis para aceite; sem retorno nesse prazo, a entrega é considerada aceita e a parcela correspondente vence. Contas de infraestrutura, lojas e domínio ficam em nome do contratante desde o início do projeto.

Seis linhas. Elas não fecham mais projeto, mas fecham os projetos certos, e é isso que mantém você freelancer no ano que vem.