Contrato pra dev freelancer: o que não pode faltar
Perdi R$ 8 mil em um projeto porque não tinha contrato escrito. Cliente desapareceu, reclamou depois de 6 meses, neguei pagamento. Sem documento, era minha palavra contra a dele. Aprendi que contrato não é coisa de grande empresa, é proteção do freelancer.
Não vou ficar aqui recitando lei, porque não sou advogado. Mas vou contar o que todo dev solo precisa documentar antes de sentar na cadeira pra programar.
Contratos salvaram meu negócio. Depois de estruturar bem os termos, meu tempo de resolução de conflitos caiu 80%. Clientes sabem exatamente o que esperar. Eu sei exatamente qual é meu compromisso. Simples assim.
Escopo é tudo
Define exatamente o que você vai fazer. Não “site bonito” ou “sistema funcionando”. Digite: “Desenvolver tela de agendamento com Astro, integrar com Supabase, validar formulário com Zod, deployar em Vercel.”
Isso evita aquele “você não falou que era responsivo” ou “mas eu queria também uma API”. Escopo claro mata 90% das discórdias.
Inclua o que NÃO está no escopo. “Não inclui: alterações de layout após desenvolvimento, hospedagem, suporte pós-entrega, integração com sistemas legados.” Parece óbvio até o cliente pedir.
Prazo e cronograma
Escreva a data de entrega. Se é projeto maior, divida em sprints. Exemplo: “4 de maio entrega primeira versão, 11 de maio segunda versão com feedback, 18 de maio deploy final.”
Deixe claro que atrasos do cliente (fornecer conteúdo, aprovações, acesso) não contam pro prazo. Muita gente acha que pode sumir por 2 semanas e você ainda entrega no prazo.
Especifique horário comercial quando você responde. Tipo: “Suporte disponível terças e quintas, 10h-14h.” Caso contrário seu cliente acha que você tem que responder no domingo.
Pagamento é o chão
Valor total, primeira parcela, segunda parcela. Para projeto até R$ 10 mil recomendo 50% na assinatura, 50% na entrega.
Acima disso, break em 3 vezes: 30% entrada, 35% na metade do caminho, 35% entrega.
Coloque multa por atraso. Juros de 3% ao mês. Não porque você é ganancioso, mas porque deixa claro: esse dinheiro importa.
Se cliente cancelar no meio, ele paga pelo que foi feito. Tipo: “Se projeto é cancelado na metade, cliente paga pela 1ª parcela + 50% da segunda parcela.”
Propriedade intelectual
Seu cliente é dono do código depois que paga. Isso é normal. Mas deixe explícito: você pode usar técnicas, componentes reutilizáveis em outros projetos.
Tipo: “Cliente adquire licença do código. Desenvolvedor mantém direitos sobre arquitetura, componentes base, bibliotecas criadas.”
Isso permite você reusar aquele input mascarado que você codou bem, em outro cliente. Não é copiar o site inteiro, é aproveitar o que aprendeu.
Cancelamento e rescisão
Como termina o contrato se der ruim? Especifique: “Qualquer parte pode cancelar com 5 dias de aviso, pagando apenas o que foi concluído até aquela data.”
Deixe claro que código não entregue não é propriedade do cliente. Se ele cancelar antes de você terminar, você leva seus rascunhos embora.
Como apresentar sem parecer burocrático
Não envie contrato de 10 páginas pra cliente pequeno. Parece que você vai processar ele amanhã.
Formato: mande por email, descontraído. “Ó, antes a gente começar preciso documentar os detalhes do projeto. Mandei um contratinho bem simples aqui.” Imprima, ele assina as duas vias, cada um fica com uma cópia.
Se cliente reclama de contrato, ele tá querendo espaço pra mudar de ideia depois. Aperta lá.
Lições de projetos que deram ruim
Um cliente meu pediu “pequenos ajustes” pra um site já entregue. Levou 6 meses de ajustinhos gratuitos. Depois vi que ele tava vendendo serviço usando meu código sem meu nome.
Outro tentou me processar porque site dele caiu 2 vezes em um ano (problema de infraestrutura, não desenvolvimento).
Um terceiro desapareceu 3 meses após entrega, reapareceu 1 ano depois pedindo mudanças, achando que ainda tinha direito.
Contrato teria evitado tudo isso.
Essas histórias são comuns na comunidade dev. Conversei com 15 devs freelancers em 2025, e 12 deles tiveram experiência de cliente tentando renegociar ou exigir trabalho extra. Contrato é proteção mútua.
Quando o cliente recusa assinar
Tem cliente que nega contrato. “Ah, vamo fazer informal, eu confio em você.” Desculpa, isso é bandeira vermelha. Pessoa que não quer documentar acordo é pessoa que quer deixar em aberto pra reclamar depois.
Responde assim: “Contrato é pra proteger os dois. Se algo der ruim, a gente tem referência. Se tudo correr bem, nem precisamos disso. Mas é necessário pra eu trabalhar tranquilo.”
Se ainda recusar, decida: você quer trabalhar com alguém que não confia em você o suficiente pra assinar contrato?
Adendos e mudanças de escopo
Projeto começou, cliente quer adicionar funcionalidade. Aí rola discussão: “Era pra estar no escopo original?”
Contrato resolve. Você faz um adendo. “Original: site com 5 páginas e 3 formulários. Adendo: adicionar Dashboard com gráficos e integração com Google Analytics. Valor extra: R$ 3 mil, prazo estendido em 2 semanas.”
Cliente assina o adendo. Pronto. Não fica brincadeira depois.
Já fiz isso com 8 projetos. Só em 1 o cliente reclamou. Outros 7? Assinaram tranquilamente. Porque estavam vendo claro o que era novo trabalho.
Rescisão por iniciativa do dev
Tem cliente que é tão ruim que você quer sair do projeto. Contrato deixa isso claro também.
“Se desenvolvedor precisar encerrar contrato por motivo justificado (cliente não pagando, cliente descumprindo termos, etc), desenvolvedor avisa com 10 dias de antecedência. Cliente paga pela metade do trabalho concluído. Código entregue até aquela data é propriedade do cliente.”
Isso protege você. Você não fica preso em projeto eterno com cliente que não paga ou é abusivo.
A importância de guardar cópias
As duas pessoas assinam. Cada uma fica com uma cópia. Não mande digital que depois cliente diz que não recebeu. Imprime mesmo. Lápis em mão, assinatura.
Eu guardo meus contratos em pasta física por 3 anos. Se cliente processa depois disso, prescrição já rodou. Mas enquanto prescrição não roda, tenho documentação de tudo.
Digitalmente: salva em PDF no Google Drive com backup automático. Cloud é seu amigo.
Modelo prático
Se você quer economizar, não precisa pagar advogado. Use um modelo básico, adapte pra seu caso. Inclua:
- Dados de quem tá contratando
- Descrição do escopo
- Cronograma
- Valores e parcelas
- Condições de cancelamento
- Propriedade intelectual
- Assinatura e data
Bem direto, sem juridiquês.
A gente trabalha pra ganhar. Contrato é como aquele backup que você acha chato fazer todo dia até precisar. Depois você agradece.
Leia também: Cobrar por aquele “ajustezinho” | Escopo é a skill mais importante | Onboarding de cliente que funciona
- Definir escopo por escrito, com o que não está incluído
- Estabelecer datas de entrega e sprints se for projeto maior
- Especificar valor total e forma de pagamento
- Proteger propriedade intelectual e direito de reuso
- Documentar processo de cancelamento e rescisão
- Usar modelo simples, descontraído na apresentação
- Guardar as duas vias assinadas
Sem contrato, você tá jogando seu trabalho no vento.
Contrato de dev freelancer não é intimidação. É profissionalismo. É você dizendo: “Eu levo meu trabalho a sério e quero que você também leve.”