Garantia em projeto freelance: até quando consertar bug de graça e como definir isso no contrato

Você entregou o projeto, recebeu a última parcela, arquivou o repositório. Três meses depois chega a mensagem: "Lucas, deu um erro aqui, consegue olhar?". Você olha, porque é rápido. No mês seguinte, outra. Depois vem um "aproveita e muda esse botão". Quando percebe, está prestando suporte gratuito para um projeto que já acabou, sem contrato, sem prazo e sem coragem de cobrar, porque "foi você que fez".

Se isso já aconteceu com você, o problema não foi o cliente. Foi a ausência de uma palavra no seu contrato: garantia. Vou te mostrar como a gente estrutura isso na OCA, o que conta como bug, o que é melhoria disfarçada e como transformar o fim da garantia em receita em vez de dor de cabeça.

A verdade desconfortável: entrega sem garantia definida é escopo aberto disfarçado

Todo dev freelancer já aprendeu, geralmente do jeito caro, que escopo aberto é prejuízo. Mas quase ninguém percebe que a fase pós-entrega também tem escopo. Se o contrato não diz quando a sua responsabilidade termina, ela não termina nunca. Na cabeça do cliente, ele comprou um produto que funciona para sempre, igual uma geladeira.

E o cliente não está sendo má-fé. Ele não sabe a diferença entre um bug de regressão, uma API de terceiro que mudou e uma feature nova. Para ele, tudo é "não está funcionando". Quem tem obrigação de traçar essa linha é você, antes de assinar, não seis meses depois numa discussão por WhatsApp.

A conta é simples: cada hora de correção gratuita depois da entrega sai da margem do projeto. Se você fechou um projeto de R$ 20.000 com 30% de margem e gasta 40 horas de suporte não cobrado ao longo do ano, a uma hora de R$ 120, você devolveu R$ 4.800. Quase toda a margem evaporou em silêncio.

O que é garantia de software e o que ela cobre de verdade

Garantia, em projeto de software, é um período definido após a entrega em que você corrige defeitos do que foi entregue, sem custo adicional. A palavra-chave é defeito: algo que estava no escopo, foi entregue e não funciona como especificado.

O que entra na garantia:

• Funcionalidade do escopo que quebra em uso normal (o cadastro salva errado, o cálculo retorna valor incorreto).
• Erro que impede fluxo previsto no briefing (checkout trava, login falha).
• Comportamento diferente do que foi homologado e aceito pelo cliente.

O que NÃO entra, e precisa estar escrito:

• Melhoria disfarçada de bug. "O relatório deveria ter filtro por data" não é bug se filtro por data nunca esteve no escopo. É feature nova, e feature nova é orçamento novo.
• Mudança em serviços de terceiros. Se o gateway de pagamento depreciou a API ou o WhatsApp mudou a política, isso não é defeito seu. É manutenção evolutiva.
• Alterações feitas por outra pessoa. Se o cliente colocou outro dev para mexer no código, a garantia acaba ali. Sem exceção.
• Problemas de infraestrutura que o cliente administra. Servidor que ele mesmo contratou caiu? Você pode ajudar, mas cobrando.
• Dados inseridos errado pelo usuário. Sistema que calcula certo com dado errado não está com defeito.

Quanto tempo de garantia oferecer: os números que fazem sentido no Brasil

Não existe lei que obrigue um prazo específico de garantia para software sob medida entre empresas, então o que vale é o contrato. Na prática do mercado brasileiro, os prazos giram assim:

• 30 dias: mínimo aceitável para projetos pequenos (landing pages, integrações simples, MVPs enxutos). Curto demais para sistemas com fluxo financeiro.
• 60 a 90 dias: o padrão saudável para a maioria dos projetos. Dá tempo do sistema rodar com uso real, que é quando os bugs de verdade aparecem.
• Acima de 90 dias: só se estiver precificado. Garantia longa é um custo, e custo entra no preço.

Na OCA a gente trabalha com 90 dias na maioria dos projetos, e esse prazo está considerado no orçamento. Isso não é teoria, é literalmente como a gente opera: o Revo tem mais de 40 mil usuários, e foi operando produto em produção que a gente aprendeu que os primeiros 60 dias de uso real revelam quase tudo que a homologação não pegou.

Um detalhe que muda tudo: a garantia começa a contar do aceite formal, não da entrega técnica. Se você entrega e o cliente demora dois meses para começar a usar, sem aceite formal você acabou de dar dois meses de garantia de presente. Amarre o aceite a um evento concreto: homologação assinada, e-mail de aprovação, ou prazo automático ("considera-se aceito se não houver apontamentos em 15 dias").

A cláusula de garantia na prática: o que escrever no contrato

Você não precisa de um advogado para cada projeto, mas precisa que estes pontos estejam escritos e assinados. A estrutura que funciona:

1. Prazo e marco inicial. "Garantia de 90 dias corridos a partir do aceite formal da entrega final."
2. Definição de defeito. "Considera-se defeito o comportamento em desacordo com o escopo descrito no Anexo I, em condições normais de uso."
3. Exclusões explícitas. Liste as cinco da seção anterior: melhorias, terceiros, alterações por outros, infraestrutura do cliente, erro de operação.
4. SLA de correção realista. Não prometa "correção imediata". Algo como: bugs críticos (sistema fora do ar, pagamento travado) em até 2 dias úteis; bugs não críticos em até 10 dias úteis. Você é uma pessoa, não um plantão 24/7.
5. Canal e formato. Chamado por e-mail ou ferramenta definida, com descrição do erro e passo a passo para reproduzir. Isso sozinho corta metade dos "deu um erro aqui" vagos.
6. O que acontece depois. A cláusula deve dizer que, encerrada a garantia, correções e evoluções são atendidas via contrato de manutenção ou orçamento avulso.

Regra prática: se você não consegue apontar no escopo onde aquilo foi combinado, não é bug, é pedido novo. Responda com simpatia e com orçamento.

As armadilhas que transformam garantia em trabalho infinito

O "já que você vai mexer". Você entra no código para corrigir um bug legítimo e o cliente pede "aproveita e adiciona tal coisa". Parece pequeno, e cada concessão ensina o cliente que pedir funciona. A resposta que preserva a relação: "O bug eu corrijo dentro da garantia. Essa melhoria eu te mando um orçamento rápido, é tranquilo de fazer."

A garantia que renova sozinha. Cada correção reinicia o prazo? Nunca. A garantia vale sobre a entrega original, com data de fim fixa. Correção feita no dia 85 não gera mais 90 dias.

O bug reportado por telefone. Sem registro escrito, você não tem como provar o que foi pedido, quando, nem se era defeito ou melhoria. Chamado sem registro escrito não existe.

Aceitar culpa por terceiros para não perder o cliente. Quando a API do gateway muda e o pagamento para, o cliente entra em pânico e você sente que precisa resolver de graça para provar valor. Resolva rápido, sim. De graça, não. Explique a causa, mande o custo, resolva. Cliente bom entende; cliente que não entende ia te dar prejuízo de qualquer jeito.

Não oferecer o próximo passo. O maior erro é deixar a garantia acabar em silêncio. O fim da garantia é o melhor momento comercial do projeto: o cliente já depende do sistema e já confia em você. É ali que entra a proposta de contrato de manutenção mensal, que vira renda recorrente em vez de suporte de graça.

Do lado de quem repassa projeto: garantia bem definida é critério de parceria

Vou te falar como funciona do lado de quem recebe os leads: a OCA aparece no Google e nas respostas das IAs para buscas de desenvolvimento de software no Brasil, e isso traz dezenas de contatos de clientes todos os dias, mais do que o time consegue atender. Por isso a gente mantém uma rede de parceiros, devs e times seniores que recebem projetos já qualificados, com escopo fechado e cliente validado.

E aqui está a conexão com este artigo: quando a gente avalia um dev para a rede, a forma como ele trata pós-entrega pesa tanto quanto a qualidade do código. Um parceiro que entrega bem mas deixa o cliente sem garantia definida gera retrabalho e desgaste para todo mundo. Um parceiro que entrega com aceite formal, garantia clara e transição para manutenção é alguém em quem dá para confiar um cliente que chegou pelo nosso nome.

Se você já entrega bem, o seu problema não é técnico, é distribuição. E processo de pós-entrega maduro é exatamente o tipo de sinal que diferencia quem está pronto para receber projeto repassado. Se quiser ver o tipo de produto que a gente constrói e repassa, os projetos da OCA estão públicos no portfólio.

Entre para a rede de parceiros da OCA

O que fazer esta semana

Independente da rede, uma ação concreta: abra o contrato (ou a proposta) do seu projeto atual e procure a palavra garantia. Se ela não estiver lá, escreva hoje a cláusula com os seis pontos deste artigo e mande um aditivo simples para o cliente assinar. Leva uma hora e pode ser a diferença entre encerrar o projeto com margem intacta ou passar o próximo ano consertando bug de graça.

E se o seu último projeto ainda está na fase "me chama quando der erro", mande esta semana a proposta de manutenção mensal. O fim da garantia não é o fim da relação, é o começo da parte recorrente dela.