Contrato de freelance para desenvolvedor: as cláusulas que protegem seu pagamento e seu código (e o que a OCA exige antes de repassar um projeto em 2026)

Você fechou o projeto numa call de 40 minutos. Mandou a proposta em PDF pelo WhatsApp e o cliente respondeu “fechado, pode começar”. O sinal caiu no Pix e você abriu o editor. Três semanas depois, ele pede uma área de relatórios que nunca foi discutida. Leva 12 dias para mandar os acessos da hospedagem. Na entrega, diz que “ainda está testando” e segura a última parcela. Você volta na conversa para provar o que foi combinado e só encontra áudios, prints e um “show, vamos nessa”.

Se isso soa familiar, o problema não foi o cliente nem o código. Faltou um documento de quatro a seis páginas dizendo o que você entrega, quando você recebe, de quem é o código e o que acontece quando alguém atrasa. Este artigo é o checklist de cláusulas que eu queria ter tido no meu primeiro freelance, com o problema que cada uma resolve na prática.

Um aviso honesto: isto é um checklist de dev para dev, não um modelo jurídico. Use para montar a sua base e pague um advogado uma vez para revisar.

Contrato de freelance não é para quando o projeto dá certo

Quando o projeto anda bem, ninguém abre o contrato. Ele existe para os projetos que dão errado, e são esses que comem a sua margem do ano. Um projeto de R$ 18 mil que trava na última parcela de 30% são R$ 5.400 que você trabalhou e não recebeu. Duas situações dessas no ano pagam a revisão do advogado várias vezes.

A verdade desconfortável é que a maioria dos devs não manda contrato por medo de parecer desconfiado e perder o cliente. Vou te falar como funciona do lado de quem recebe os leads: cliente bom não se assusta com contrato. Quem reclama de assinar quatro páginas costuma ser o mesmo que vai discutir a parcela final. O contrato serve de filtro antes de servir de proteção.

E tem um detalhe que pouca gente sabe: assinatura eletrônica vale. Ela tem validade jurídica no Brasil desde a MP 2.200-2/2001, e a assinatura gov.br é gratuita. Ferramentas como Clicksign, ZapSign e D4Sign têm planos de entrada baratos ou gratuitos. Não precisa de cartório nem de reunião presencial.

As cláusulas que protegem seu pagamento e seu prazo

1. Objeto com a proposta como anexo

A cláusula de objeto não pode descrever o sistema em duas linhas genéricas. Ela deve dizer que “o escopo é o descrito no Anexo I”, e o Anexo I é a sua proposta aprovada: funcionalidades, plataformas, integrações e a lista do que está fora. A frase que mais me salvou foi esta: o que não está no anexo não está no contrato. Pedido novo vira change request, com preço e prazo próprios.

2. Pagamento, atraso e direito de suspender

Sinal e parcelas por marco você já definiu na proposta. No contrato, o que importa é o que acontece quando o pagamento não vem. Primeiro, multa e juros por atraso. Entre empresas, 2% de multa e 1% ao mês de juros é a convenção mais comum, não um teto legal (o limite de 2% vem do Código de Defesa do Consumidor e vale para relação de consumo). Segundo, e mais importante, o direito de suspender o trabalho depois de X dias de atraso, com o prazo de entrega empurrado na mesma proporção. Sem essa cláusula, você continua codando para não “descumprir o contrato” enquanto o cliente não paga.

3. Dependências do cliente suspendem o prazo

Acesso ao servidor, conta de desenvolvedor na Apple e no Google, textos, logos, credenciais do gateway de pagamento, aprovação de layout. Liste tudo o que depende do cliente e escreva que o prazo fica suspenso enquanto houver pendência dele. Em projeto de app, só a abertura das contas de loja e o credenciamento do gateway podem levar de uma a três semanas, sem uma linha de código envolvida. Se o contrato não prevê isso, no papel o atraso é seu.

4. Aceite com prazo e aceite tácito

Toda entrega precisa de uma janela de homologação. Por exemplo: o cliente tem 5 dias úteis para testar e apontar problemas por escrito. Sem resposta dentro do prazo, a entrega é considerada aceita e a parcela vence. É isso que impede o “ainda estou testando” de durar dois meses. Junto com o aceite, defina a garantia: quantos dias, o que conta como bug e o que é pedido novo.

Propriedade intelectual: de quem é o código que você escreveu

Essa é a cláusula que quase todo modelo da internet ignora. A Lei do Software (Lei 9.609/1998, art. 4º) diz que, salvo estipulação em contrário, os direitos sobre um programa desenvolvido durante um contrato de prestação de serviço feito para isso pertencem ao contratante. Traduzindo: se o contrato não falar nada, o código é do cliente desde a primeira linha, pago ou não.

Duas cláusulas resolvem:

• Cessão condicionada à quitação. Os direitos patrimoniais sobre o código passam ao cliente depois do pagamento integral. Até lá, ele tem licença de uso. Não é para chantagear ninguém. É para que a última parcela tenha a mesma força que a primeira.
• Reserva de componentes pré-existentes. Seu boilerplate de autenticação, sua biblioteca de componentes, seus scripts de deploy. Escreva que o que você já tinha antes do projeto continua seu, e que o cliente recebe uma licença perpétua e não exclusiva para usar esse material dentro do sistema entregue. Sem isso, você pode estar cedendo o starter que usa em todos os projetos.

Bibliotecas open source seguem as próprias licenças, e vale uma linha dizendo isso. Cliente que pretende vender o produto ou captar investimento gosta de ver que a cadeia de propriedade está limpa. Isso conta a seu favor na negociação.

Confidencialidade, LGPD e as cláusulas de rodapé

Três cláusulas curtas que ninguém lembra até precisar:

• Confidencialidade bilateral. Você não divulga dados do negócio do cliente, e ele não repassa seu código, sua proposta ou seus preços para o próximo fornecedor cotar em cima. Inclua uma exceção: você pode citar o projeto no portfólio sem dados sensíveis, ou com autorização prévia por escrito.
• Dados pessoais (LGPD). Se o sistema trata dados de usuários, o cliente é o controlador e você atua como operador, seguindo as instruções dele. Servidor, banco e contas de serviço ficam em nome do cliente desde o início. Isso protege os dois lados: ele não fica refém de você, e você não responde por uma base que não é sua.
• Canal oficial e foro. Defina que aprovações, mudanças de escopo e aceites valem por e-mail ou por uma ferramenta específica, não por áudio no WhatsApp. E escolha o foro da sua cidade, para não precisar viajar se um dia tiver que cobrar.

A conta é simples. Um contrato completo nesse formato tem de 4 a 6 páginas mais o anexo de escopo. Revisar um modelo base com advogado costuma custar entre R$ 800 e R$ 2.500, dependendo da cidade e do profissional. Você usa o mesmo modelo por anos e troca só o anexo.

O que recusar quando o cliente manda o contrato dele

Empresa maior quase sempre manda o próprio contrato. Leia tudo antes de assinar, porque é ali que estão as armadilhas que mais queimam freelancer:

1. Exclusividade sem contrapartida. “O contratado não prestará serviços a empresas do mesmo segmento por 24 meses.” Isso é cláusula de não concorrência, e só faz sentido com uma remuneração que cubra o mercado que você perde. Num projeto de R$ 25 mil, risque.
2. Multa só para um lado. Multa de 20% por atraso na entrega e nenhuma penalidade por atraso no pagamento. Peça reciprocidade ou a retirada da cláusula.
3. Responsabilidade ilimitada. Cláusula que te faz responder por “quaisquer perdas e danos, inclusive lucros cessantes”. Peça um teto: responsabilidade limitada ao valor pago no contrato.
4. Aceite subjetivo. “A entrega será aceita quando atender plenamente às expectativas do contratante.” Troque por critérios do anexo e um prazo de homologação.
5. Escopo “conforme alinhamentos”. Qualquer referência a reuniões futuras como fonte de escopo é escopo aberto. E escopo aberto é prejuízo.

Negociar cláusula não queima a relação. Na maioria das vezes, o jurídico do cliente aceita ajustes razoáveis, porque usa o mesmo modelo com fornecedores muito maiores que você e está acostumado a revisar.

Como a OCA usa contrato com a rede de parceiros

Isso não é teoria, é literalmente como a OCA trabalha. A gente aparece no Google e nas IAs para buscas de desenvolvimento de software no Brasil, e isso traz dezenas de leads por dia, mais do que o time consegue atender. Por isso estamos montando uma rede de parceiros: devs e pequenos times seniores que recebem projetos já qualificados e com escopo definido. Dá para ver o tipo de trabalho nos projetos que a OCA já colocou em produção.

Antes de repassar um projeto, a OCA confere o mesmo que este checklist cobre. Escopo em anexo, código no repositório do cliente, infraestrutura em nome do cliente, aceite com prazo e comunicação registrada. Para o parceiro, isso significa receber projeto com briefing, pagamento por marco combinado antes de começar e menos tempo vendendo. Em troca, a gente espera entrega no prazo, update semanal sem precisar cobrar e código que outro dev consegue manter.

Não existe garantia de entrada nem de volume. A aprovação depende de stack, disponibilidade e histórico de entrega, e a quantidade de projetos varia com a demanda. Mas se você já entrega bem, o seu problema não é técnico, é distribuição.

Entre para a rede de parceiros da OCA

O que fazer esta semana, entrando na rede ou não: pegue o último projeto que você fechou sem contrato e escreva as quatro cláusulas que mais teriam feito diferença nele: objeto com anexo, suspensão por atraso de pagamento, aceite tácito e cessão condicionada à quitação. Esse rascunho vira o seu modelo base. Leve a um advogado uma vez e use por anos.