Contrato de freelance para dev: as 8 cláusulas que protegem seu pagamento, seu código e seu prazo (com texto-base para adaptar)

Você fechou o projeto numa call de 40 minutos. O cliente gostou e pediu orçamento. Você mandou um PDF com valor e prazo, e ele respondeu: “fechado, manda o Pix da entrada”. Três meses depois, o app está quase pronto. O cliente pede “só mais uma tela de relatório”, segura a última parcela até você entregar e pergunta quando recebe o código-fonte. Nada disso foi combinado por escrito. Está tudo espalhado em áudio de WhatsApp.

Se você já viveu essa cena, o problema não é o cliente ser mau-caráter. É que o acordo de vocês nunca virou documento. Quando o acordo não está escrito, vale a memória de quem está com o dinheiro na mão. Este artigo mostra as cláusulas que eu considero obrigatórias em qualquer contrato de freelance de desenvolvimento, com texto-base para adaptar. Também mostra os erros que mais vejo devs cometerem nessa etapa.

Contrato de freelance não serve para processar cliente, serve para evitar a briga

A verdade desconfortável é que quase nenhum dev freelancer vai à Justiça por causa de uma parcela de R$ 8 mil. Tem o advogado, as custas, os meses de processo e o desgaste de brigar com alguém que poderia te indicar para outros clientes. A conta raramente fecha.

Então para que serve o contrato? Para três coisas bem mais práticas:

• Forçar a conversa difícil antes do início. O que está dentro, o que está fora, quando o cliente paga e quando a entrega é considerada concluída. Discutir isso no dia 1 custa uma call. Descobrir no mês 3 custa o projeto.
• Virar o texto de referência quando o conflito aparece. A frase “pela cláusula 2, o prazo de validação era de 5 dias úteis” encerra uma discussão que, sem documento, vira a sua palavra contra a dele.
• Filtrar cliente. Quem resiste a assinar um contrato simples, com escopo em anexo e pagamento por marco, já te mostrou como vai ser o resto do projeto.

Na OCA, a regra vale para projeto próprio e para projeto repassado: nada começa sem escopo em anexo e contrato assinado. Não é desconfiança do cliente. É que os projetos que mais deram dor de cabeça foram exatamente os que começaram no “depois a gente formaliza”.

Um aviso honesto: eu sou dev, não advogado. O que está aqui é o que aprendi tocando projetos. Pague um advogado uma vez para revisar o seu modelo, algo entre R$ 800 e R$ 2.500 dependendo do profissional e da região, e reutilize por anos. É um dos gastos com melhor retorno que um freelancer pode fazer.

As 8 cláusulas que todo contrato de desenvolvimento de software precisa ter

1. Objeto com escopo em anexo

“Desenvolvimento de aplicativo conforme alinhado entre as partes” é um convite ao escopo infinito. O objeto do contrato deve apontar para um anexo com a lista de funcionalidades e as plataformas (iOS, Android, painel web). Principalmente, o anexo precisa dizer o que não está incluso: publicação nas lojas, criação de conteúdo, integrações não listadas, design de marca.

Texto-base: “O objeto deste contrato limita-se às funcionalidades descritas no Anexo I. Qualquer funcionalidade, alteração ou integração não prevista no Anexo I será orçada à parte, mediante aditivo com valor e prazo próprios.”

2. Critério de aceite com prazo

Essa é a cláusula que destrava a última parcela. Sem ela, o cliente pode passar semanas “testando” sem aprovar nem apontar problema, e você fica com a entrega pronta e o pagamento parado. Defina quantos dias úteis o cliente tem para validar cada entrega e o que acontece se ele não responder.

Texto-base: “O CONTRATANTE terá 5 (cinco) dias úteis, contados da disponibilização de cada entrega, para aprová-la ou apontar por escrito divergências em relação ao Anexo I. Na ausência de manifestação nesse prazo, a entrega será considerada aceita.”

3. Dependências do cliente

Acesso à conta de desenvolvedor da Apple, credenciais de API do ERP, textos, imagens, aprovação de layout: todo projeto depende de coisas que só o cliente pode entregar. A cláusula diz que o atraso do cliente empurra o seu prazo na mesma proporção. Também diz que, se o projeto ficar parado por mais de 30 dias por falta de retorno, a retomada segue a sua agenda.

4. Pagamento por marco, com consequência para atraso

A entrada vem na assinatura, e as parcelas ficam atreladas a entregas, não a datas soltas. O que quase todo mundo esquece é a consequência do atraso. Multa de 2% e juros de 1% ao mês é a prática mais comum. O que protege de verdade é o direito de suspender o trabalho depois de alguns dias de atraso, sem que isso conte como descumprimento seu.

Texto-base: “O atraso superior a 10 (dez) dias no pagamento de qualquer parcela autoriza a CONTRATADA a suspender os serviços até a regularização, com prorrogação automática dos prazos pelo período da suspensão.”

5. Propriedade intelectual transferida na quitação

O código passa a ser do cliente quando o contrato está pago, não na assinatura. Deixe claro também que bibliotecas, componentes genéricos e ferramentas que você já tinha antes do projeto continuam seus, e que o cliente recebe uma licença de uso perpétua sobre eles. Sem essa ressalva, você pode estar entregando de vez o boilerplate de autenticação que usa em todo projeto.

6. Garantia com prazo e definição de bug

Uma garantia de 30 a 90 dias para corrigir defeitos é razoável e passa confiança. O problema aparece quando ninguém definiu o que é defeito. Bug é um comportamento diferente do que foi aprovado no Anexo I. Melhoria, nova regra de negócio, mudança de layout e incompatibilidade com uma versão de sistema operacional lançada depois da entrega não são bug. Acabou a garantia, o caminho é um contrato de manutenção mensal.

7. Rescisão proporcional

Qualquer uma das partes pode encerrar o contrato com aviso prévio de 15 ou 30 dias. O cliente paga o trabalho feito até essa data. A entrada cobre a mobilização e não é devolvida. O código produzido é entregue depois desse acerto. Isso protege os dois lados: o cliente não fica preso a um dev que não funciona para ele, e você não trabalha dois meses para receber zero.

8. Limitação de responsabilidade e contas em nome do cliente

A sua responsabilidade fica limitada ao valor total do contrato, sem lucros cessantes. Toda a infraestrutura (AWS, Vercel, Supabase, contas das lojas, domínio) fica no nome e no cartão do cliente. Servidor no seu cartão vira dívida sua quando o cliente some. Quando a relação azeda, ainda vira acusação de que você sequestrou o sistema.

Se o sistema trata dados pessoais, inclua também uma cláusula de LGPD que defina o cliente como controlador e você como operador. São duas linhas que evitam uma conversa muito ruim no futuro.

Resumo das cláusulas: o que cada uma evita

Os erros de contrato que mais queimam dev freelancer

Baixar um modelo genérico da internet

Muitos modelos prontos foram feitos para prestação de serviço em geral e ignoram aceite, código e garantia. Pior: alguns trazem horário fixo, exclusividade e subordinação a um gestor. Além de não te proteger, esse tipo de cláusula desenha uma relação de emprego, o que é problema para você e para o cliente.

Começar antes de assinar

“Vai adiantando que a gente assina semana que vem.” A semana que vem não chega, porque o cliente já tem o que queria: você trabalhando. A regra é simples: sem contrato assinado e entrada paga, o repositório nem é criado. A assinatura eletrônica resolve isso em minutos e tem validade jurídica. Dá para usar ZapSign, Clicksign, DocuSign ou a assinatura gratuita do gov.br.

Assinar o contrato do cliente sem ler

Empresas maiores costumam mandar o próprio modelo. Tudo bem, desde que você procure quatro coisas. A primeira é multa que só vale para você. A segunda é transferência do código na assinatura, antes do pagamento. A terceira é responsabilidade ilimitada. A quarta é uma cláusula de não concorrência ampla, do tipo “não atender empresas do mesmo setor por dois anos”, que pode inviabilizar o seu negócio se você trabalha com nicho. Tudo isso é negociável, e pedir ajuste não queima ninguém. Cliente sério espera isso de fornecedor sério.

Mudar o combinado sem registrar

O contrato estava perfeito, mas no mês 2 vocês combinaram por áudio trocar um gateway de pagamento por outro. Toda mudança aprovada vira aditivo. No mínimo, vira um e-mail com a descrição, o valor e o novo prazo, respondido com um “de acordo” do cliente. O contrato só protege enquanto reflete o projeto real.

Como a OCA trata contrato nos projetos repassados para a rede de parceiros

Vou te falar como funciona do lado de quem recebe os leads. A OCA aparece no Google e nas IAs quando alguém busca desenvolvimento de software no Brasil, e isso traz mais pedidos de projeto por dia do que o nosso time consegue atender. Isso não é teoria, é literalmente como a OCA cresceu. Parte dessa demanda vai para uma rede de parceiros: devs e pequenos times seniores que recebem projetos já qualificados.

O parceiro recebe justamente o que este artigo tenta te ensinar a montar sozinho: cliente filtrado, escopo desenhado antes do início e contrato com aceite, marcos e dependências claros. Você não começa do zero negociando cláusula com alguém que nunca contratou software.

O que a gente espera de quem entra: entrega de nível sênior, prazo cumprido, comunicação semanal com cliente não técnico e respeito ao escopo, sem cortar o que foi prometido e sem inflar o que não foi. Não existe garantia de entrada nem de volume. Cada dev e cada projeto são avaliados caso a caso. Se quiser entender o tipo de produto que a gente constrói, dá uma olhada no portfólio de projetos da OCA.

Próximo passo: revise o seu contrato esta semana

Abra o último projeto que você fechou. Pode ser o contrato, a proposta ou a conversa de WhatsApp, o que existir. Marque quais das 8 cláusulas estão por escrito. Se forem menos de cinco, reescreva o seu modelo antes de mandar a próxima proposta e leve para um advogado revisar uma vez. Uma tarde de trabalho agora evita o mês de dor de cabeça que todo freelancer conhece.

Se você já entrega bem e quer receber projetos com escopo e contrato já estruturados, a conversa começa aqui:

Entre para a rede de parceiros da OCA