Contrato de freelance para dev: as cláusulas que salvam sua pele quando o projeto azeda

Você fechou o projeto por mensagem de WhatsApp. O cliente disse "pode começar", você começou, e o combinado inteiro está espalhado em áudios, prints e uma proposta em PDF que ninguém assinou. Enquanto tudo vai bem, ninguém sente falta de contrato. O problema é que contrato não existe para quando tudo vai bem. Ele existe para o dia em que o cliente some, pede a quinta "alterçãozinha rápida", contesta o pagamento ou aparece três meses depois da entrega cobrando um bug como se você fosse suporte vitalício. Nesse dia, o que você tem por escrito é a diferença entre resolver em uma conversa e engolir o prejuízo.

Vou te falar como funciona do lado de quem já assinou dezenas de contratos, dos dois lados da mesa: a maioria dos devs freelancers ou não usa contrato, ou usa um modelo genérico baixado da internet que não cobre nenhuma das situações que realmente acontecem. Este artigo é sobre as cláusulas que importam de verdade.

Por que dev freelancer trabalha sem contrato (e por que isso é uma armadilha)

Os motivos são sempre os mesmos. Medo de assustar o cliente com formalidade. Pressa de começar logo. A sensação de que contrato é coisa de empresa grande. E a crença de que, se o cliente é gente boa, não precisa.

A verdade desconfortável: contrato não é sinal de desconfiança, é sinal de profissionalismo. Cliente sério não desiste de um projeto porque você mandou um contrato de três páginas. Quem desiste por causa disso estava planejando, consciente ou não, se aproveitar da falta dele. Na OCA, o contrato faz parte do processo de fechamento de todo projeto, e nunca perdemos um cliente bom por causa disso. Já evitamos vários clientes ruins.

E não precisa ser um documento de vinte páginas em juridiquês. Um contrato simples, com as cláusulas certas, assinado digitalmente por plataformas como Clicksign ou D4Sign, resolve a maioria dos casos. O que segue são as cláusulas que, na prática, salvam sua pele.

Garantia de bugs: quanto tempo você cobre depois da entrega

Essa é a cláusula que mais gera conflito depois do projeto encerrado, e quase ninguém escreve. Sem ela, todo defeito que aparecer, para sempre, vira "obrigação sua" na cabeça do cliente.

O que colocar por escrito:

• Prazo de garantia definido. O mercado pratica entre 30 e 90 dias após a entrega final. Na OCA usamos 60 dias como padrão. Depois disso, correção entra como manutenção, cobrada à parte.
• O que é bug e o que não é. Bug é comportamento diferente do que foi especificado no escopo. Funcionalidade nova, mudança de regra de negócio ou "eu achei que ia funcionar assim" não é bug, é mudança de escopo.
• O que anula a garantia. Se o cliente ou outro dev alterar o código, a garantia cai. Parece óbvio, mas se não estiver escrito, você vai debugar código que você não escreveu, de graça.

Essa cláusula ainda abre uma porta comercial: no fim da garantia, você oferece um contrato de manutenção mensal. Vira receita recorrente em vez de discussão.

Prazo de feedback do cliente: a cláusula que protege o seu cronograma

Todo dev já viveu isso: você entrega uma etapa, pede aprovação, e o cliente demora três semanas para responder. Depois cobra o prazo original como se o tempo parado fosse problema seu.

A solução é uma cláusula de dependência: cada entrega parcial tem um prazo de resposta do cliente, tipicamente 5 dias úteis. Se o cliente não responder nesse prazo, duas coisas acontecem, e as duas precisam estar escritas:

1. O cronograma desloca na mesma proporção do atraso. Cliente demorou 15 dias a mais, a data final anda 15 dias.
2. Silêncio prolongado, por exemplo 30 dias sem resposta, é tratado como pausa do projeto, com regra clara de retomada (e, idealmente, custo de retomada, porque recontextualizar um projeto parado custa horas suas).

Sem isso, o cliente controla o seu calendário e você fica com a culpa do atraso. Com isso, a demora dele tem consequência automática, sem briga.

Rescisão: como cada lado sai do contrato sem destruir o outro

Projetos morrem no meio. O cliente perde o orçamento, muda de prioridade, ou simplesmente desiste. Se o contrato não disser o que acontece nesse cenário, você descobre na pior hora que trabalhou semanas por nada.

O que a cláusula de rescisão precisa cobrir:

• Aviso prévio. Qualquer lado pode encerrar, com aviso de 15 ou 30 dias.
• Pagamento proporcional obrigatório. Tudo que foi produzido até a data da rescisão é devido. Se você estruturou o pagamento em marcos de entrega, essa conta fica trivial: marcos entregues são marcos pagos.
• Multa por rescisão imotivada. Comum usar 20% do valor restante do contrato. Isso compensa a agenda que você bloqueou e os projetos que recusou para atender esse cliente.
• Entrega do que foi pago. O cliente recebe o código correspondente ao que quitou. Nem mais, nem menos.

A conta é simples: sem cláusula de rescisão, o custo de desistir do projeto é zero para o cliente e inteiro para você.

Limite de responsabilidade: a cláusula que ninguém lê até precisar

Imagine que um bug no checkout que você construiu derruba as vendas do cliente por um fim de semana. Ele pode tentar te cobrar o "prejuízo" de vendas perdidas, um valor que ele mesmo estima e que pode ser dez vezes o que você recebeu pelo projeto inteiro.

A cláusula de limitação de responsabilidade resolve isso antes de acontecer: sua responsabilidade por danos fica limitada ao valor total pago pelo contrato, e lucros cessantes (aquilo que o cliente "deixou de ganhar") ficam expressamente excluídos. É padrão em contrato de software no mundo inteiro, inclusive nos termos de uso de qualquer SaaS que o seu cliente já assina sem ler. Não é você se eximindo de fazer um bom trabalho, é você impedindo que um defeito vire uma dívida impagável.

Junto dela, vale escrever a divisão de responsabilidades operacionais: de quem é a conta da infraestrutura (AWS, Vercel, Supabase), quem responde pelos dados dos usuários perante a LGPD, quem gerencia as chaves e acessos. Quando isso não está escrito, tudo é "do dev" por padrão.

As cláusulas complementares que fecham as brechas

Mais quatro pontos que cabem em um parágrafo cada e evitam dores específicas:

• Comunicação oficial. Defina um canal formal para aprovações e mudanças (e-mail ou ferramenta de projeto). Áudio de WhatsApp não é aditivo de contrato. Isso protege os dois lados da memória seletiva.
• Mudança de escopo. Referencie o documento de escopo como anexo do contrato e escreva que qualquer alteração exige aditivo com prazo e valor. A cláusula não elimina pedidos novos, ela dá a você uma frase pronta: "claro, faço sim, deixa eu te mandar o aditivo".
• Confidencialidade mútua. Você não expõe dados do negócio do cliente, ele não expõe seus preços e métodos. Mas garanta uma exceção: o direito de citar o projeto no seu portfólio, salvo acordo diferente. Portfólio é o seu ativo comercial mais importante, não abra mão dele por descuido.
• Foro e assinatura. Defina a cidade do foro para disputas e assine digitalmente. Contrato assinado por plataforma com validade jurídica no Brasil resolve; PDF "combinado" por mensagem, não.

Sobre propriedade intelectual e estrutura de pagamento em sinal e marcos, cada um desses temas rende um artigo próprio, e o resumo cabe em uma linha: o código transfere ao cliente somente após a quitação, e nenhum projeto começa sem sinal.

Contrato também é filtro de cliente (e critério para receber projetos repassados)

Tem um efeito colateral do contrato que pouca gente percebe: a reação do cliente ao documento te diz quem ele é. Cliente que lê, pergunta e assina é cliente que respeita processo. Cliente que enrola a assinatura mas pressiona para você começar "enquanto isso" está te mostrando, antes do projeto, como vai ser durante o projeto. Isso não é teoria, é literalmente o padrão que vimos se repetir nos projetos da OCA e no nosso produto próprio, o Revo, onde todo fornecedor e parceiro passa pelo mesmo filtro.

E aqui entra um contexto que talvez te interesse. A OCA aparece no Google e nas respostas das IAs para buscas de desenvolvimento de software no Brasil, e isso gera mais leads de clientes por dia do que o nosso time consegue atender. A nossa resposta foi montar uma rede de parceiros: devs seniores e pequenos times que recebem projetos já vetados, com escopo fechado e, sim, contrato estruturado. Quando avaliamos um dev para a rede, a maturidade comercial pesa tanto quanto a técnica. Quem trabalha com contrato, escopo escrito e marcos de pagamento entrega projeto que termina bem, e projeto que termina bem é o que a gente pode repassar de olhos fechados. Se você quer ver o tipo de projeto que circula por aqui, o portfólio da OCA dá uma boa amostra.

Entre para a rede de parceiros da OCA

O que fazer esta semana

Independente da rede, uma ação concreta: pegue seu último projeto e verifique, por escrito, se você teria resposta para quatro perguntas. Até quando você cobre bug de graça? O que acontece se o cliente demorar um mês para responder? Quanto ele te deve se cancelar no meio? Qual o teto da sua responsabilidade se algo der errado em produção? Cada "não sei" é uma cláusula que falta no seu próximo contrato. Escreva as quatro, valide com um advogado uma única vez, e reuse em todos os projetos daqui para frente. É um investimento de algumas horas que você faz uma vez e que te protege em todos os contratos da sua carreira.