Contrato de manutenção mensal para dev freelancer: como estruturar o retainer, quanto cobrar e o que nunca incluir

Você entregou o projeto, o cliente aprovou, o Pix caiu. Dois meses depois o WhatsApp toca: "o app parou de abrir no iPhone novo". Você resolve em duas horas porque gosta do cliente, e não cobra. Três semanas depois: "o boleto não está gerando". Mais uma tarde. Aí você olha o mês e percebe que trabalhou dez horas de graça em um projeto que já tinha acabado, enquanto corria atrás do próximo cliente para fechar a conta do aluguel.

Esse ciclo tem nome: renda por projeto. Você só ganha quando fecha algo novo, e todo software que entregou vira passivo em vez de ativo. Este artigo é sobre inverter essa lógica com um contrato de manutenção mensal, o famoso retainer. Vou te mostrar o que incluir, o que nunca incluir, quanto cobrar e como oferecer para os clientes que você já tem.

A verdade desconfortável: software não fica pronto

Todo dev sabe disso na teoria. Poucos precificam na prática.

A gente opera o Revo, um app de eventos com mais de 40 mil usuários. Ele nunca esteve "pronto". Todo ano a Apple lança um iOS que quebra alguma coisa. O Expo sobe de SDK e alguma lib para de compilar. O Pagar.me muda um contrato de API. Certificado expira, dependência ganha CVE, política da Play Store muda e exige ação em 30 dias. Nada disso é feature nova. É só o custo de o software continuar existindo.

Quando você entrega um sistema sem contrato de manutenção, esse custo não desaparece. Ele só fica sem dono. E o cliente vai assumir, com toda a boa fé do mundo, que o dono é você. De graça, porque "você fez".

A conta é simples. Se você entregou cinco projetos nos últimos dois anos e cada um consome três horas por mês de "só uma coisinha", são quinze horas mensais sem faturamento. A R$ 150 a hora, você está doando R$ 2.250 por mês. Isso paga um bom plano de saúde.

O que entra em um contrato de manutenção mensal (e o que fica de fora)

O retainer só funciona se as duas partes sabem exatamente o que estão comprando. A estrutura que a OCA usa tem três blocos.

Bloco 1: manter vivo

• Monitoramento de erros e disponibilidade (Sentry, uptime, alertas).
• Atualização de dependências e SDKs, com teste de regressão básico.
• Conformidade com lojas: builds novos quando Apple ou Google exigem, renovação de certificados e perfis.
• Verificação periódica de backup e de restauração.
• Acompanhamento do custo de infra e alerta quando algo foge do padrão.

Bloco 2: banco de horas para correções e ajustes

Um volume fixo de horas por mês, tipicamente entre 5 e 20, para bugs, ajustes de texto, pequenas melhorias e dúvidas. O que não for usado não acumula, ou acumula por no máximo um mês. Esse bloco é o coração do contrato, e é aqui que a maioria dos devs se perde. Volto nisso nas armadilhas.

Bloco 3: SLA de resposta

Prazo para responder e prazo para começar a atuar, separados por severidade. Sistema fora do ar: resposta em até 4 horas em dia útil. Bug que trava uma função: 1 dia útil. Ajuste cosmético: entra na fila do banco de horas. Fim de semana e madrugada só entram se o cliente pagar por isso, e o preço é outro.

O que fica de fora, por escrito

• Funcionalidade nova. Qualquer coisa que altere o escopo original é proposta à parte ou change request com preço próprio.
• Redesign, migração de stack, troca de provedor de pagamento.
• Integração com sistema que não existia na entrega.
• Suporte ao usuário final do cliente. Você atende o cliente, não os clientes dele.

Essa lista de exclusões vale mais do que a lista de inclusões. É ela que te protege quando o cliente diz "mas isso é manutenção".

Quanto cobrar pelo retainer: a conta honesta

Duas referências que se cruzam.

Referência 1: percentual do projeto. O mercado de software trabalha com algo entre 15% e 25% do valor do projeto por ano só para manter o sistema funcionando. Um sistema de R$ 60 mil gera entre R$ 9 mil e R$ 15 mil por ano, ou R$ 750 a R$ 1.250 por mês, apenas no bloco "manter vivo". Se você está cobrando menos que isso, está subsidiando o cliente.

Referência 2: banco de horas com desconto. Pegue sua hora avulsa e aplique um desconto de 10% a 20% pela previsibilidade. Se sua hora avulsa é R$ 180, a hora dentro do retainer fica entre R$ 145 e R$ 160. Dez horas por mês dão R$ 1.450 a R$ 1.600.

Somando os blocos, as faixas que vejo funcionar no Brasil em 2026:

• Site institucional ou sistema interno pequeno: R$ 800 a R$ 2.000 por mês, com 3 a 5 horas de banco.
• App mobile publicado nas duas lojas ou sistema web com pagamento: R$ 2.500 a R$ 6.000 por mês, com 10 a 15 horas.
• Produto com usuários pagantes, integrações e operação que não pode cair: R$ 6.000 a R$ 15.000 por mês, com 20 a 40 horas e SLA mais agressivo.

O que move o número para cima: app nas lojas (a Apple sozinha justifica uns 20% a mais), pagamento embutido, integrações com terceiros instáveis e cliente sem ninguém técnico do lado dele. O que move para baixo: sistema interno, stack enxuta, cliente com TI própria para o primeiro atendimento.

Cobrança sempre adiantada, no início do mês. Você não é banco.

As armadilhas que transformam o retainer em prejuízo

Todas essas eu já vi de perto ou paguei para aprender.

Horas que acumulam para sempre. O cliente não usa nada por seis meses, aí chega com um pedido de 60 horas e o contrato diz que ele tem direito. Você acabou de vender um projeto inteiro pelo preço de retainer. Regra: horas não usadas expiram no mês seguinte, no máximo.

"Manutenção" sem lista de exclusão. Sem o bloco do que fica de fora, toda feature nova vira "só um ajuste". Em três meses você está desenvolvendo um módulo de relatórios dentro de um contrato de R$ 1.500.

Retainer sem prazo mínimo nem aviso prévio. O cliente cancela no dia em que a dependência crítica quebrou e você fica com o problema e sem o pagamento. Prazo mínimo de 6 meses e aviso prévio de 30 dias resolvem isso. Depois do prazo mínimo, o aviso prévio continua valendo.

Não registrar as horas. Sem registro, você não sabe se o contrato dá lucro e não consegue mostrar ao cliente por que o banco acabou. Um relatório mensal simples, com o que foi feito e quanto sobrou, resolve a conversa antes de ela virar conflito.

Preço baixo para "não perder o cliente". Retainer de R$ 400 com atendimento no WhatsApp a qualquer hora não é renda recorrente, é um cliente que comprou o seu telefone. Se a conta não fecha, é melhor cobrar por hora avulsa e ter liberdade para recusar.

Assumir sistema que você não construiu sem auditoria. Retainer de código herdado só depois de uma avaliação paga. Você precisa saber o que está prometendo manter.

Como oferecer manutenção para quem você já entregou

O melhor momento para vender o retainer é na proposta do projeto, como item separado que começa após a entrega. O segundo melhor momento é agora, para todo cliente que você já tem.

O roteiro é curto. Você manda uma mensagem dizendo que, com o sistema em produção, ele passa a depender de atualizações periódicas para continuar funcionando, e que você está oferecendo um plano de manutenção para os clientes ativos. Descreve os três blocos em cinco linhas, dá o preço e explica que, fora do plano, você atende por hora avulsa com agenda sujeita a disponibilidade.

Uma parte dos clientes vai dizer não. Ótimo: você acabou de definir que o próximo "só uma coisinha" tem preço. Outra parte vai aceitar, e cada um que aceita é um mês que começa com dinheiro em caixa antes de você fechar qualquer projeto novo.

Três retainers de R$ 2.500 são R$ 7.500 fixos por mês. Isso muda completamente a pressão da prospecção. Você passa a escolher projeto em vez de aceitar o que aparece. Se você já entrega bem, o seu problema não é técnico, é distribuição, e renda recorrente compra o tempo para resolver isso.

Onde a rede de parceiros da OCA entra nisso

Vou te falar como funciona do lado de quem recebe os leads: a OCA aparece no Google e nas IAs para buscas de desenvolvimento de software no Brasil, e isso traz mais pedidos de projeto por dia do que o time consegue atender. Uma parte desses projetos a gente repassa para uma rede de devs e times pequenos que já mostraram que entregam.

O ponto que conecta com este artigo: praticamente todo projeto repassado vira demanda de manutenção depois. O cliente que teve o app construído por um parceiro quer o mesmo parceiro cuidando dele. Quando a gente avalia quem entra na rede, saber estruturar essa fase conta bastante. Um dev que entrega e some deixa o cliente órfão, e isso volta como problema para a OCA. Um dev que já opera com contrato de manutenção, SLA e relatório mensal é exatamente o perfil que a gente procura.

O que o parceiro recebe é escopo fechado, cliente já qualificado e um processo de handoff que a gente já testou nos projetos que a OCA mantém em produção. O que a OCA espera é código que outro sênior consiga ler, comunicação sem sumiço e postura de dono do sistema depois da entrega. Não tem promessa de volume nem garantia de entrada. Tem uma conversa honesta sobre encaixe.

Entre para a rede de parceiros da OCA

E independente da rede, uma ação para esta semana: abra a lista dos sistemas que você já entregou e que ainda estão rodando. Para cada um, escreva em cinco linhas o que você faria todo mês para mantê-lo saudável e quanto isso custaria pela conta acima. Depois mande a mensagem. O pior cenário é o cliente dizer não e você parar de trabalhar de graça.