Como encerrar projeto freelance que deu errado: o distrato que protege seu pagamento e sua reputação (e quando sair vale mais que insistir)

Você está no terceiro mês de um projeto que era para durar dois. O escopo mudou quatro vezes, a segunda parcela está atrasada há 25 dias e o cliente manda áudio de seis minutos às 23h pedindo “só um ajuste rápido”. Você abre o VS Code de manhã e sente o estômago apertar.

Em algum momento passa pela cabeça a saída mais tentadora: parar de responder, arquivar o repositório e seguir a vida. Ou o contrário: continuar até o fim por medo do que acontece se você sair, trabalhando de graça num projeto que já não fecha a conta.

As duas opções custam caro. Este artigo é sobre a terceira: encerrar o projeto freelance de forma organizada, receber pelo que foi entregue, passar o bastão sem rastro de briga e sair com a reputação inteira. Ninguém planeja esse cenário, mas quem pega projeto por tempo suficiente passa por ele pelo menos uma vez.

Sumir do projeto freelance sai mais caro do que sair direito

A verdade desconfortável é que a maioria dos devs não tem plano de saída. O contrato fala de entrega, prazo e pagamento, mas quase nunca fala do que acontece se a relação quebrar no meio. Então, quando quebra, a decisão vira emocional.

O ghosting tem três custos que ninguém calcula na hora:

• Dinheiro. Se você some, perde a força para cobrar o que já entregou e não recebeu. Quem abandona o contrato vira, no papel, a parte que descumpriu.
• Risco jurídico. Dependendo do contrato, o cliente pode pedir devolução do que pagou ou indenização pelo atraso. Uma saída acordada por escrito fecha essa porta.
• Reputação. O mercado de software no Brasil é menor do que parece. O cliente que você abandonou conversa com outros donos de empresa, com contadores, com outras software houses.

Vou te falar como funciona do lado de quem recebe os leads: uma parte relevante dos contatos que chegam na OCA é de empresa com projeto abandonado pelo dev anterior. Uma das primeiras perguntas que a gente faz é como foi o fim. Quando a resposta é “ele sumiu e não temos acesso a nada”, o resgate fica mais caro e a história do dev vem junto na conversa. Quando a resposta é “ele avisou, entregou o código e a documentação”, ninguém fala mal dele.

Fase ruim ou projeto sem conserto? 5 sinais de que é hora de encerrar

Todo projeto tem semana ruim. Antes de sair, separe atrito normal de relação quebrada. Estes sinais, quando aparecem juntos, indicam que insistir só aumenta o prejuízo:

1. Pagamento atrasado mais de 30 dias sem previsão. Atraso com justificativa e nova data é fase. Atraso com silêncio é sinal.
2. O escopo mudou e o cliente se recusa a formalizar. Você propõe um change request e ele responde que “estava implícito”. Toda conversa sobre escopo vira negociação de valor para baixo.
3. Você está faturando menos da metade da sua hora real. A conta é simples: valor total do contrato dividido pelas horas gastas mais as que faltam. Se deu R$ 60 por hora num projeto orçado a R$ 150 por hora, o projeto já deixou de ser negócio.
4. O tom da comunicação mudou. Ameaça, desrespeito, cobrança em grupo na frente de outras pessoas, mensagem em horário que vocês combinaram que não teria.
5. Você está atendendo mal outros clientes por causa deste. O custo de um projeto ruim não fica só nele, vaza para a agenda inteira.

Um sinal isolado pede conversa. Três ou mais pedem plano de saída. Antes de tudo, tente a conversa franca de reajuste: às vezes o cliente nem percebeu o quanto o escopo cresceu. Se não resolver, siga o roteiro abaixo.

Como encerrar um projeto freelance em 5 passos

1. Congele o estado do projeto antes de falar com o cliente

Antes de qualquer mensagem, monte o retrato do que existe hoje. Você vai precisar disso para negociar e para se proteger:

• Lista do que foi entregue e aceito, com data e onde o aceite aconteceu (e-mail, mensagem, ata de reunião).
• O que está em andamento e em que percentual, com link para branch, PR ou ambiente de homologação.
• Valores recebidos e valores em aberto.
• Todas as contas e acessos envolvidos: repositório, cloud, banco, domínio, conta de loja, chaves de API.

Faça push de tudo, crie uma tag no repositório e guarde os prints das aprovações. Isso leva umas duas horas e vale mais que qualquer argumento depois.

2. Faça o acerto de contas pelo que foi entregue

O erro clássico é negociar a saída com base no tempo que você gastou. O cliente não enxerga horas, enxerga entregas. Use os marcos do contrato como régua. Um exemplo com números de um projeto web típico:

Com o número na mão, defina antes da conversa duas coisas: o valor que você pede (R$ 7.000) e o mínimo que aceita para encerrar em paz. Em muitos casos vale dar um desconto em troca de pagamento rápido e distrato assinado. Receber R$ 5.500 em dez dias costuma valer mais do que brigar seis meses por R$ 7.000.

3. Tenha a conversa de saída em call e confirme por escrito

Nada de anunciar a saída por áudio no WhatsApp. Marque uma call de 30 minutos, explique os fatos sem acusar, apresente o acerto de contas e proponha um prazo de transição. Depois, mande um e-mail com o resumo. Um modelo para adaptar:

Oi, Fulano. Obrigado pela conversa de hoje. Como alinhamos, vou encerrar minha participação no projeto. Resumo do que combinamos:

1. Entregas concluídas: Marco 1 completo e Marco 2 com 50% (detalhes no documento anexo).
2. Saldo referente ao entregue: R$ 7.000, com vencimento em DD/MM.
3. Transição: até DD/MM entrego o código, a documentação e transfiro todos os acessos listados no anexo.
4. Depois disso, fico disponível para uma call de 1 hora com o próximo desenvolvedor, sem custo.

Vou te enviar o termo de distrato para assinatura. Se algum ponto não estiver correto, me avisa até amanhã.

A oferta da call com o próximo dev custa uma hora e muda o tom da conversa inteira. Você deixa de ser o dev que está largando o projeto e passa a ser o dev que está entregando o projeto.

4. Formalize com um termo de distrato

O Código Civil (art. 472) diz que o distrato se faz pela mesma forma exigida para o contrato. Se vocês assinaram contrato escrito, encerre por escrito. O termo cabe em uma página e precisa cobrir:

• Data de encerramento e a declaração de que as partes encerram o contrato de comum acordo.
• Lista do que foi entregue e o valor final devido, com data e forma de pagamento.
• Quitação mútua: depois do pagamento, nenhuma das partes cobra mais nada referente a este contrato.
• Propriedade intelectual: o código entregue e pago passa ao cliente.
• Confidencialidade, que continua valendo depois do fim.
• Garantia: deixe explícito se existe ou não período de correção sobre o que foi entregue.

Para valores altos ou relação já hostil, pague uma consulta com advogado para revisar o termo. Costuma ficar entre R$ 300 e R$ 800 e evita muita dor de cabeça.

5. Faça o handoff completo

O handoff é o que transforma a saída em encerramento profissional. O mínimo:

• Repositório transferido para a organização do cliente, ou acesso de owner concedido e o seu removido em seguida.
• README atualizado: como rodar local, quais variáveis de ambiente são necessárias (sem os valores no repositório) e como fazer deploy.
• Lista do que ficou pela metade e onde parou, com os riscos conhecidos.
• Transferência das contas que estão no seu nome: domínio, cloud, Apple Developer, Google Play Console, gateway de pagamento. É o item que mais trava a vida de quem assume depois.
• Rotação de credenciais: troque as chaves que você usava. O cliente fica seguro e você fica livre de responsabilidade sobre qualquer acesso futuro.

As armadilhas que transformam uma saída ruim em um problema maior

Segurar o código como refém

Usar o acesso para pressionar pagamento é tentador. Mas o código que o cliente já pagou é dele, e derrubar sistema em produção pode virar processo contra você. A alavanca legítima é outra: o que não foi pago só é entregue depois do pagamento. Isso precisa estar claro desde a proposta, não inventado na hora da briga.

Aceitar “depois a gente acerta”

Sem valor, data e assinatura, o acerto não existe. O cliente que atrasou durante o projeto não fica mais pontual depois que você saiu.

Desabafar em público

Um post no LinkedIn contando o caso, mesmo sem citar nome, é lido por futuros clientes como “esse dev expõe cliente”. Desabafe com quem você confia, fora da internet.

Não levar a lição para o próximo contrato

Todo projeto que termina mal deixa uma lição para o contrato seguinte. A mais útil: uma cláusula de rescisão com aviso prévio de 15 a 30 dias, pagamento proporcional pelo entregue e regra de transferência de código. Com ela, o próximo encerramento é só seguir o que está assinado.

O que a OCA olha quando um projeto sai do trilho com um parceiro

A OCA aparece no Google e nas IAs para buscas de desenvolvimento de software, e isso traz mais pedidos de projeto do que o time consegue atender. Por isso a gente montou uma rede de parceiros: devs seniores e times pequenos que recebem projetos já filtrados e com escopo desenhado.

Repassar um projeto é colocar o nosso nome junto do seu. Então, além da parte técnica, pesa muito como o dev age quando as coisas apertam. O que a gente espera de um parceiro:

• Avisar cedo quando algo não vai bem, e não na véspera do prazo.
• Escopo e mudanças sempre por escrito.
• Código no repositório do cliente, acessos documentados, nada preso no computador de ninguém.
• Se precisar sair, sair com handoff, nunca com silêncio.

Em troca, o parceiro recebe leads que já passaram por qualificação e chegam com escopo inicial definido. Isso não elimina projeto difícil, mas reduz a chance de você descobrir no mês três que o cliente nunca teve orçamento. Não existe garantia de volume nem de entrada na rede: a gente conversa, entende o seu momento e avalia se faz sentido para os dois lados. Para ter uma ideia do tipo de produto que a gente constrói, veja o portfólio de projetos da OCA.

O próximo passo

Se você quer receber projetos repassados pela OCA, manda uma mensagem contando sua stack, o tipo de projeto que já entregou e quanto de agenda tem livre:

Entre para a rede de parceiros da OCA

E, independente disso, faça uma coisa esta semana: abra cada projeto ativo e liste todas as contas que estão no seu nome e não no do cliente. Domínio, cloud, conta de loja, gateway. Para cada uma, anote como transferir. Se um dia você precisar sair, metade do handoff já estará pronta. Se nunca precisar, o cliente vai agradecer do mesmo jeito.