Garantia pós-entrega no freelance: quanto suporte grátis dar sem virar refém do projeto que você já entregou

Você entregou o projeto, o cliente aprovou, o pagamento caiu. Duas semanas depois chega a mensagem: "apareceu um probleminha aqui, dá pra dar uma olhada?". Você olha, é rápido, resolve. Um mês depois, outra mensagem. Três meses depois, o cliente pede "um ajuste pequeno" que é, na prática, uma funcionalidade nova. E você, que nunca definiu onde o projeto termina, continua trabalhando de graça num contrato que já acabou. Se isso soa familiar, o problema não é o cliente ser abusado. É que ninguém combinou o que acontece depois da entrega.

Vou te falar como funciona do lado de quem recebe os leads: quase nenhum dev que chega pra conversar com a gente tem uma política de garantia definida. E é exatamente essa ausência que transforma projeto lucrativo em prejuízo silencioso.

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

Todo mundo já aprendeu que escopo aberto durante o projeto é prejuízo. Mas pouca gente percebe que o pós-entrega sem regra é o mesmo problema, só que pior: você já recebeu o dinheiro, então cada hora gasta agora sai direto da sua margem. Não tem fatura nova pra compensar.

A conta é simples. Um projeto de R$ 20.000 que consumiu 160 horas te pagou R$ 125 por hora. Se você gastar mais 30 horas ao longo de seis meses respondendo "probleminhas", sua hora real caiu pra R$ 105. Em projetos menores, esse vazamento come 20% ou 30% do que você achou que ganhou.

E tem o custo invisível: essas horas aparecem sempre na pior hora possível, no meio do projeto seguinte, quebrando seu foco e furando o prazo de outro cliente. O projeto antigo vira um passivo que compete com o pipeline novo.

O que uma garantia de verdade cobre (e o que não cobre)

Garantia pós-entrega existe e deve existir. Software tem bug, e o cliente tem razão de esperar que aquilo que foi entregue funcione. A questão é definir a fronteira. A regra que a gente usa na OCA, e que recomendo pra qualquer parceiro da rede, é essa:

Coberto pela garantia (sem custo adicional)

• Bug em funcionalidade que estava no escopo: o botão de checkout que estava no contrato e parou de funcionar. Isso é defeito de fabricação, você conserta.
• Erro que impede o uso do que foi entregue: tela branca, crash, login quebrado. Prioridade máxima, sem discussão.
• Divergência entre o entregue e o especificado: se o contrato dizia X e você entregou Y, o ajuste é seu.

Fora da garantia (orçamento novo)

• Funcionalidade nova, por menor que pareça: "só adicionar um campo" é feature, não bug. Campo novo mexe em formulário, validação, banco e, às vezes, relatório.
• Mudança de comportamento que o cliente decidiu depois: "pensando bem, o fluxo deveria ser diferente". Isso é mudança de escopo pós-entrega.
• Quebra causada por terceiros: a API do gateway de pagamento mudou, o Google atualizou uma política, uma lib foi descontinuada. Você não controla isso, então não paga por isso.
• Problema causado por alteração do próprio cliente: alguém da equipe dele mexeu no código, no servidor ou na configuração. A garantia de qualquer produto morre quando o dono abre a tampa.

Essa lista precisa estar escrita no contrato ou na proposta, antes de o projeto começar. Definir a garantia depois da entrega é negociar com a faca no seu pescoço.

Quanto tempo de garantia dar: os números que funcionam

Não existe número mágico, mas existe faixa razoável. O que funciona no mercado brasileiro de desenvolvimento sob medida:

• Projetos pequenos (até R$ 15.000): 30 dias de garantia contados da entrega aprovada.
• Projetos médios (R$ 15.000 a R$ 60.000): 60 dias. É tempo suficiente pro cliente usar o sistema de verdade e os bugs reais aparecerem.
• Projetos grandes ou com lançamento público: 90 dias, porque o volume de uso real demora a chegar.

Dois detalhes que mudam tudo. Primeiro: o prazo conta a partir da entrega aprovada, não do último commit. Se o cliente demorar dois meses pra homologar, a garantia não pode estar correndo nesse meio tempo. Segundo: defina prazo de resposta, não de plantão. Garantia de 60 dias não significa que você atende no domingo à noite. Algo como "bugs críticos respondidos em até 1 dia útil, demais casos em até 3 dias úteis" protege os dois lados.

Isso não é teoria, é literalmente como a OCA opera. O Revo tem mais de 40 mil usuários e 300 eventos por mês rodando em produção. A gente sabe que bug aparece, e sabe que a diferença entre operação sustentável e caos é ter regra escrita de quem paga o quê e quando.

E depois da garantia? Transforme o fim do projeto em receita recorrente

Aqui está a parte que a maioria dos devs deixa na mesa. O fim da garantia não deveria ser um tchau, deveria ser uma proposta. O cliente que acabou de receber um sistema tem duas opções: ficar sem suporte nenhum ou contratar manutenção. Se você não oferecer a segunda, ele descobre a primeira do pior jeito, e você vira o culpado.

Na entrega, junto com a documentação, mande a proposta de manutenção. Estrutura que funciona:

1. Plano básico: monitoramento, atualização de dependências, correção de bugs fora da garantia, com um teto de horas mensal (4 a 8 horas). Faixa comum no Brasil: R$ 800 a R$ 2.500 por mês, dependendo da complexidade do sistema.
2. Plano evolutivo: tudo do básico mais um banco de horas pra melhorias pequenas (10 a 20 horas mensais). Faixa: R$ 2.500 a R$ 6.000 por mês.
3. Sob demanda: sem contrato mensal, hora avulsa com valor 30% a 50% acima da sua hora de projeto, e prazo de atendimento sem prioridade. O preço maior não é ganância: trabalho avulso e imprevisível custa mais caro de encaixar na agenda, e o cliente precisa sentir essa diferença pra valorizar o plano mensal.

O efeito colateral positivo: quando existe um caminho pago claro, o cliente para de tentar empurrar feature como bug. A conversa muda de "dá uma olhadinha" para "isso entra no banco de horas?". A fronteira que você escreveu no contrato passa a se defender sozinha.

As armadilhas que transformam garantia em sequestro

• Aceitar o "enquanto está mexendo aí": você entra pra corrigir um bug coberto e o cliente aproveita pra pedir três ajustes. Corrija o bug, responda os ajustes com orçamento. Toda vez.
• Garantia sem homologação formal: se não existe um momento documentado de "entregue e aprovado", o cliente pode alegar pra sempre que o projeto "nunca ficou pronto". Um e-mail de aceite resolve.
• Consertar de graça o que o freelancer anterior quebrou: se você assumiu um sistema órfão, deixe explícito que a garantia cobre o que VOCÊ construiu, não o legado inteiro.
• Não versionar nem documentar a entrega: sem tag no repositório e sem registro do que foi entregue, você não consegue provar se o problema é bug seu ou alteração de terceiro. Git é seu contrato técnico.
• Medo de cobrar: o dev que atende tudo de graça "pra manter o relacionamento" ensina o cliente que seu trabalho pós-entrega vale zero. Relacionamento bom se constrói com clareza, não com hora gratuita.

Onde isso encontra a rede de parceiros da OCA

Se você já entrega bem, o seu problema não é técnico, é distribuição. E aqui entra um contexto que talvez te interesse: a OCA aparece no Google e nas respostas das IAs pra buscas de desenvolvimento de software no Brasil, e isso gera mais leads de clientes por dia do que o nosso time consegue atender. A resposta pra isso foi montar uma rede de parceiros: devs seniores e times pequenos que recebem projetos já qualificados, com escopo cercado e cliente validado.

E adivinha o que a gente olha antes de repassar um projeto pra alguém? Exatamente o que este artigo descreveu. Parceiro que não tem política de garantia, não formaliza entrega e não sabe separar bug de feature vira problema nosso, porque o cliente chegou pela OCA. Já o dev que opera com contrato claro, homologação documentada e proposta de manutenção na entrega é o perfil que recebe projeto e recebe de novo. Você pode ver o tipo de produto que a gente constrói e repassa no portfólio de projetos da OCA.

Entre para a rede de parceiros da OCA

O que fazer esta semana, independente de qualquer coisa

Abra o modelo de proposta ou contrato que você usa hoje e adicione uma seção chamada "Garantia e suporte pós-entrega" com quatro linhas: prazo da garantia, o que cobre, o que não cobre e o valor da hora avulsa depois dela. Se você tem cliente ativo agora com projeto perto do fim, mande a proposta de manutenção junto com a entrega, não depois. Quinze minutos de escrita hoje valem dezenas de horas gratuitas que você não vai trabalhar nos próximos seis meses.