Garantia de software no freelance dev: quanto tempo dar, o que é bug e o que é pedido novo (e como não trabalhar de graça depois da entrega)

Você entregou o projeto. O cliente aprovou, pagou a última parcela e você arquivou o repositório satisfeito. Três semanas depois chega a mensagem no WhatsApp: “o relatório não está exportando”. Você corrige numa noite, sem cobrar, porque é bug. Uma semana depois: “aproveitando, dá pra colocar um filtro por data nesse relatório?”. Dois meses depois o cliente ainda escreve toda sexta, e você já não sabe se está consertando um erro seu ou construindo um produto novo de graça.

Se isso soa familiar, o problema não é o cliente folgado. É que a sua proposta nunca disse quanto tempo dura a garantia, o que conta como bug e o que acontece depois. Sem essa definição, a garantia não acaba. Ela só fica mais cara.

Garantia sem prazo vira manutenção de graça

A verdade desconfortável é que o cliente não sabe a diferença entre bug e funcionalidade nova. Para ele, “o sistema não faz o que eu preciso” é tudo a mesma coisa. Esperar que ele faça essa distinção sozinho é empurrar para ele um trabalho que é seu.

E tem o outro lado. Muito dev evita falar de garantia na proposta com medo de parecer que está prevendo problema. O efeito é o contrário. Cliente que já foi queimado por fornecedor que sumiu depois da entrega quer ouvir exatamente isso: por quanto tempo você responde pelo que entregou e em quanto tempo você atende.

Garantia bem escrita é argumento de venda. Garantia não escrita é prejuízo com data de início e sem data de fim.

Quanto tempo de garantia dar no projeto freelance

Não existe número mágico, mas existe faixa que funciona. O que move o prazo é o tamanho do projeto, a quantidade de integrações e o tempo que o cliente leva para usar o sistema de verdade.

• Landing page, site institucional, ajuste pontual: 30 dias.
• MVP web ou app de 6 a 12 semanas: 60 dias.
• Sistema com integrações (ERP, gateway de pagamento, APIs de terceiros): 90 dias.

Mais de 90 dias raramente faz sentido. Depois de três meses em produção, o que aparece costuma ser uso novo, dado novo ou regra de negócio que mudou. Isso é manutenção, e manutenção tem contrato próprio.

A garantia começa no aceite, não na entrega

Esse detalhe salva mais margem que o prazo em si. Se a garantia conta a partir do deploy e o cliente leva 40 dias para testar, a sua garantia de 60 dias virou 20 dias de uso real, e o resto é discussão. Amarre o início ao termo de aceite. E defina que, sem contestação por escrito em 5 a 10 dias úteis após a entrega, a entrega é considerada aceita. Sem essa regra, o cliente pode segurar o aceite indefinidamente e a sua garantia nunca começa a contar.

A conta de quanto a garantia custa

Garantia não é de graça. Alguém paga, e se não estiver no preço, quem paga é você. A conta é simples. Nos projetos que a gente acompanha na OCA, a garantia de um sistema bem testado costuma consumir entre 5% e 10% das horas de desenvolvimento.

Um projeto de 300 horas a R$ 150 por hora fecha em R$ 45.000. A garantia vai consumir algo entre 15 e 30 horas, ou seja, R$ 2.250 a R$ 4.500 de trabalho. Esse valor precisa estar embutido no preço desde a proposta. Não como linha separada que o cliente vai pedir para cortar, mas como parte do custo de entregar com responsabilidade.

Se a sua garantia está consumindo mais de 15% das horas, o problema não está na garantia. Está no teste antes da entrega ou no escopo que nasceu aberto.

Bug ou pedido novo: o critério que encerra a discussão

A definição que funciona é uma só: bug é quando o sistema se comporta diferente do que foi especificado e aceito. Todo o resto é pedido novo. Por isso o escopo escrito importa tanto. Sem ele, não existe “especificado”, e qualquer coisa pode virar bug.

Uma tabela como essa, anexada à proposta, evita metade das conversas difíceis. Quando o cliente manda “achei um bug”, você não discute. Você classifica, responde com a categoria e, se for pedido novo, manda o orçamento no mesmo dia.

Prazo de resposta também faz parte da garantia

Defina tempo de resposta por gravidade. Um formato simples:

• Crítico (sistema fora do ar, pagamento parado): início do atendimento em até 1 dia útil.
• Normal (funcionalidade com erro, mas com contorno possível): até 5 dias úteis.
• Cosmético (texto, alinhamento, cor): entra no próximo lote de correções.

Isso não é SLA de empresa grande. É só deixar claro que “urgente” tem definição, e que mensagem às 23h de sábado não é crítica por padrão.

O que fica fora da garantia (e precisa estar escrito)

A lista de exclusões é onde a maioria das garantias falha. Sem ela, você responde por coisas que nem controla.

• Alterações no código feitas pelo cliente ou por outro dev depois da entrega.
• Mudanças em APIs, SDKs ou serviços de terceiros, como gateway de pagamento, provedores de mensageria e lojas de aplicativo.
• Atualizações de sistema operacional ou exigências novas da Apple e do Google publicadas depois do aceite.
• Infraestrutura contratada e gerenciada pelo próprio cliente.
• Dados inseridos incorretamente ou uso fora do fluxo especificado.

Um texto-base para adaptar à sua proposta ou contrato:

O CONTRATADO garante a correção, sem custo adicional, de falhas em que o software se comporte de forma diferente do escopo aprovado, pelo prazo de 60 dias corridos contados da data do termo de aceite. Considera-se aceita a entrega não contestada por escrito em até 7 dias úteis após sua disponibilização. Estão excluídos da garantia: alterações realizadas por terceiros, mudanças em serviços e APIs externas, atualizações de plataformas publicadas após o aceite e novas funcionalidades. Solicitações fora da garantia serão orçadas separadamente.

Isso não substitui um advogado, e para contrato de valor alto vale a revisão. Mas ter esse parágrafo escrito já te coloca à frente da maioria das propostas que chegam para o cliente.

As armadilhas que fazem a garantia comer sua margem

Corrigir sem registrar

Você corrige três bugs pelo WhatsApp, sem issue e sem data. No dia 58 da garantia o cliente diz que “o sistema sempre deu problema”. Você não tem como mostrar o que foi corrigido nem quando. Registre tudo, nem que seja num quadro simples no Trello, no Linear ou no GitHub Issues com acesso compartilhado com o cliente.

O “já que você está mexendo”

O pedido novo quase nunca chega sozinho. Ele vem colado no bug: “já que você vai corrigir o filtro, coloca também a opção de ordenar”. Separe na resposta. Corrige o bug, orça o resto. Se você fizer junto uma vez, na próxima vira expectativa.

Prometer garantia longa para fechar o negócio

“Garantia de um ano” fecha contrato e destrói margem. Em doze meses a stack atualiza, a loja muda regra e o cliente contrata outra pessoa para mexer no código. Prefira garantia curta e bem definida, e ofereça um contrato de manutenção mensal para o período seguinte. É mais honesto, e o cliente entende.

Deixar a garantia acabar em silêncio

O fim da garantia é o melhor momento para propor manutenção. Mande uma mensagem uma semana antes do prazo com o que foi corrigido no período, o que você recomenda monitorar e quanto custa continuar com você. Cliente que teve uma garantia bem atendida é o cliente mais fácil de converter em receita recorrente.

Como a OCA olha para garantia na hora de repassar projetos

Vou te falar como funciona do lado de quem recebe os leads. A OCA aparece no Google e nas IAs quando alguém pesquisa desenvolvimento de software no Brasil, e isso gera mais demanda do que o nosso time consegue atender. Parte desses projetos a gente repassa para uma rede de parceiros: devs seniores e times pequenos que já entregam bem.

Quando um projeto sai daqui, ele sai com escopo fechado, critério de aceite e prazo de garantia já combinados com o cliente. O que a gente espera do parceiro é que honre isso: responda no prazo, classifique bug e pedido novo com clareza e não suma no dia seguinte ao último pagamento. É isso que protege o cliente, o parceiro e o nome da OCA. Dá para ter uma ideia do padrão de entrega que a gente segue olhando os projetos que a OCA já colocou em produção.

Em troca, o parceiro recebe projeto já qualificado, sem gastar semanas prospectando, e com um escopo que não nasce aberto. Não é promessa de volume nem de entrada automática. A gente avalia cada dev pelo histórico de entrega e pela forma como conduz o pós-entrega, justamente pelos motivos deste artigo.

Se você já entrega bem e quer receber projetos com escopo cercado, o próximo passo é conversar com a gente:

Entre para a rede de parceiros da OCA

E, independente disso, fica uma ação para esta semana: abra o modelo da sua última proposta e adicione três coisas. O prazo de garantia contado a partir do aceite, a tabela de bug versus pedido novo e a lista de exclusões. Se você tem um projeto em garantia agora, mande para o cliente um resumo do que já foi corrigido e da data em que a garantia termina. Essa mensagem sozinha já muda o tom da relação.