Qual percentual pedir de sinal?

Algo entre 30% e 50% é a prática mais comum no mercado brasileiro para projetos de software. Abaixo de 30% você financia o início do trabalho; acima de 50% pode assustar cliente novo. Para clientes desconhecidos ou projetos curtos, o percentual maior se justifica.

Posso começar a trabalhar antes de receber o sinal?

Não é recomendável. O sinal é o primeiro teste real de intenção do cliente e filtra quem nunca teve condição ou vontade de pagar. Começar antes elimina sua única alavanca e é a origem mais frequente de calote.

Como cobrar de projeto longo, de vários meses?

Prefira parcelas mensais fixas vinculadas a marcos do cronograma, ou um retainer mensal com escopo por ciclo. Projetos longos com poucos pagamentos grandes concentram risco nos dois lados e dificultam o fluxo de caixa.

Como estruturar o pagamento de um projeto

A estrutura que protege os dois lados é simples: sinal antes de começar, parcelas ligadas a entregas verificáveis e uma parcela final pequena. O que quebra projeto é o oposto, começar sem sinal, parcelar por datas do calendário em vez de entregas, e deixar 40% do valor para depois do lançamento, quando você já não tem nenhuma alavanca.

Por que o sinal não é negociável

O sinal cumpre três funções que nenhuma outra cláusula cumpre:

Filtra intenção. Cliente que não paga a entrada raramente paga o resto. É o teste mais barato que existe.
Financia o início. As primeiras semanas costumam ser as mais intensas: descoberta, arquitetura, ambiente, modelagem. Você não deveria bancar isso.
Cria compromisso mútuo. Quem pagou entra no projeto com atenção, responde e-mail e disponibiliza acesso.

Faixa usual no mercado brasileiro: 30% a 50%. Para cliente novo, projeto curto ou escopo com muita incerteza, fique na parte alta. Reserva de agenda também justifica sinal maior, você está recusando outros trabalhos por causa daquele.

Parcelas por marco, nunca por data

Pagamento vinculado a data ("todo dia 10") transforma o financeiro em calendário e desconecta pagamento de valor entregue. Se o projeto atrasa, a discussão vira desconfortável dos dois lados.

Marco é uma entrega verificável pelo cliente: ele consegue abrir, clicar e confirmar que existe.

Exemplos de marcos utilizáveis:

Ambiente no ar com login funcionando e usuários cadastrados.
Módulo de cadastro completo, com permissões, disponível em homologação.
Integração com o ERP funcionando com dados reais.
Fluxo de pagamento operando em ambiente de teste.
Sistema publicado em produção e time treinado.

Exemplos de marcos ruins: "conclusão do backend", "50% do desenvolvimento", "modelagem finalizada". O cliente não consegue verificar nada disso.

Modelos de cronograma financeiro

Modelo	Distribuição	Quando usar
Clássico 40/30/30	Sinal / meio / entrega	Projetos de 2 a 4 meses com escopo fechado
50/25/25	Sinal alto / marco / entrega	Cliente novo, projeto curto, escopo incerto
Mensal por marco	30% de sinal + parcelas mensais iguais	Projetos de 4 meses ou mais
Retainer	Valor fixo mensal, escopo por ciclo	Evolução contínua, sustentação, time alocado
Por sprint	Pagamento a cada ciclo de 2 semanas	Escopo aberto, trabalho iterativo
Hora com teto	Faturamento mensal por hora, com limite acordado	Consultoria, descoberta, manutenção

Regra que evita o pior cenário: a última parcela deve ser menor que o custo de te substituir. Se sobrar 40% no final, o cliente insatisfeito calcula que sai mais barato contratar outro e não pagar você. Se sobrar 10% a 15%, o cálculo se inverte.

O que escrever no contrato sobre pagamento

Além dos valores e datas, quatro itens fazem diferença real:

Prazo de pagamento após a nota. "Em até 10 dias corridos da emissão", com o ciclo do cliente considerado.
Multa e juros de mora. Percentuais definidos numericamente.
Direito de suspensão. "Após X dias de atraso, os trabalhos ficam suspensos até a regularização, com prorrogação equivalente do cronograma."
Aceite e prazo de homologação. Sem regra de aceite, a última parcela nunca vence, porque o cliente sempre acha mais um ajuste.

Esses são pontos jurídicos, vale ter o modelo revisado por um advogado uma vez e reutilizar.

Como apresentar o cronograma ao cliente

A forma da conversa muda a aceitação. Não apresente como exigência sua; apresente como proteção mútua.

O argumento que funciona: "O pagamento acompanha a entrega. Você só paga a próxima parcela depois de conseguir abrir e testar o que foi feito. Se em algum momento não estiver satisfeito, o projeto para ali e você não fica com prejuízo acumulado."

Isso inverte a percepção: o cronograma deixa de ser uma cobrança e vira uma garantia. Cliente sério gosta desse arranjo, porque ele também tem medo de pagar adiantado por algo que não aparece.

Custos que precisam sair do bolso do cliente

Deixe explícito, desde a proposta, o que não está no seu valor e deve ser contratado no nome dele:

Hospedagem, domínio e serviços de nuvem.
Licenças de software e APIs pagas.
Contas de desenvolvedor da Apple e do Google.
Gateway de pagamento e taxas de transação.
Serviços de e-mail transacional, SMS ou WhatsApp.

Se você adianta esses custos, some uma taxa administrativa e defina reembolso mensal. Mas o padrão mais saudável é que essas contas estejam no nome do cliente desde o começo, evita que você vire refém de assinatura alheia e simplifica a transição no fim do projeto.

Sinais de que o cronograma financeiro está errado

Você está trabalhando há mais de seis semanas sem receber nada.
A próxima parcela depende de algo que só o cliente pode fazer (fornecer conteúdo, aprovar layout, liberar acesso) e ele não faz.
Mais de 30% do valor total está previsto para depois da entrega em produção.
O cliente pediu para "acertar tudo no final".

Qualquer um desses merece renegociação imediata, ainda no meio do projeto. Ajustar cronograma com o trabalho andando é desconfortável; descobrir no final que você financiou um projeto inteiro é bem pior.