Renda recorrente para dev freelancer: como contratos de manutenção pagam o boleto entre um projeto e outro

Você fecha um projeto de R$ 25 mil, entrega bem, o cliente elogia, e no mês seguinte sua receita volta para zero. Aí começa de novo: prospectar, orçar, negociar, torcer. Essa montanha-russa é o motivo número um de dev bom voltar para o CLT. Não é falta de competência técnica, é falta de previsibilidade. E a resposta para isso não é fechar mais projetos, é parar de deixar dinheiro recorrente em cima da mesa toda vez que um projeto termina.

Vou te falar como funciona do lado de quem entrega software há anos: todo sistema em produção precisa de manutenção. Todo. O cliente que acha que não precisa vai descobrir da pior forma, geralmente num sábado. A pergunta é só quem vai receber por esse trabalho: você, que construiu o sistema, ou o próximo dev que o cliente achar no desespero.

A verdade desconfortável: você está vendendo o produto errado

A maioria dos freelancers vende projeto fechado e trata o pós-entrega como favor. Responde dúvida de graça, corrige bugzinho de graça, atualiza dependência de graça, porque tem medo de parecer mercenário. O resultado é o pior dos dois mundos: você trabalha sem receber e o cliente aprende que suporte é gratuito.

Empresas de software não vivem de projeto, vivem de recorrência. SaaS é isso. Consultoria grande é isso. A conta é simples: um cliente de projeto vale o valor do projeto. Um cliente de recorrência vale o valor do projeto mais 12, 24, 36 meses de mensalidade. Na OCA, sistemas que entregamos continuam gerando receita de manutenção anos depois do go-live, e é essa base que segura o caixa quando um projeto grande atrasa para fechar.

O que um contrato de manutenção cobre (e o que não cobre)

Retainer não é "o cliente me liga quando quiser e eu resolvo". Isso é escopo aberto com assinatura mensal, e escopo aberto é prejuízo em qualquer formato. Um contrato de manutenção sério define três camadas:

• Manutenção preventiva: atualização de dependências, monitoramento de erros, backup, renovação de certificados, ajustes de infra. Trabalho que o cliente não vê, mas que evita o incêndio.
• Manutenção corretiva: bugs em funcionalidades existentes, com SLA definido. Por exemplo: bug crítico respondido em 4 horas úteis, bug comum em 2 dias úteis.
• Banco de horas para evolução: um número fixo de horas por mês para pequenas melhorias. Acabaram as horas, novo pedido vira orçamento à parte.

O que fica explicitamente fora: funcionalidade nova de médio ou grande porte, redesign, integração com sistema novo. Isso é projeto, e projeto tem proposta própria. Escrever essa fronteira no contrato é o que impede o retainer de virar um projeto infinito mal pago.

Quanto cobrar: faixas reais em 2026

Os números variam com a criticidade do sistema e o tamanho do banco de horas, mas as faixas que vemos funcionar no mercado brasileiro são estas:

• Site institucional ou landing page: R$ 300 a R$ 800 por mês. Pouca coisa quebra, mas alguém precisa manter plugin, formulário e hospedagem funcionando.
• Sistema web interno (painel, gestão, CRM simples): R$ 1.500 a R$ 4.000 por mês, geralmente com 4 a 10 horas de banco.
• Aplicativo mobile em produção: R$ 2.000 a R$ 6.000 por mês. Loja quebra compatibilidade, OS atualiza, biblioteca deprecia. App parado nas lojas morre.
• Sistema crítico para a operação (e-commerce, checkout, logística): R$ 4.000 a R$ 12.000 por mês, com SLA agressivo e plantão definido.

Uma regra de bolso que ajuda a ancorar: manutenção anual costuma custar entre 15% e 25% do valor do desenvolvimento. Um sistema de R$ 60 mil justifica algo entre R$ 750 e R$ 1.250 por mês só de sustentação básica. Se o cliente acha caro, a comparação honesta é o custo de uma hora de sistema fora do ar, ou de contratar um dev CLT para ficar de olho nisso.

Como vender o retainer sem parecer que está empurrando

O melhor momento para vender manutenção é dentro da proposta do projeto, não depois da entrega. Quando o retainer aparece só no final, soa como taxa surpresa. Quando aparece na proposta, soa como responsabilidade profissional. Na prática:

1. Coloque duas linhas na proposta: o valor do projeto e, logo abaixo, o valor da sustentação mensal pós-entrega. O cliente já decide sabendo o custo total de operar o sistema.
2. Dê uma garantia curta e gratuita: 30 dias de correção de bugs após a entrega, sem custo. Isso separa "defeito de fábrica" de manutenção e elimina a discussão sobre onde termina sua responsabilidade.
3. Mostre o que acontece sem manutenção: dependência com vulnerabilidade conhecida, app removido da loja por API desatualizada, certificado vencido derrubando o site. Exemplos concretos convencem mais do que qualquer argumento abstrato.
4. Ofereça relatório mensal simples: uma página com uptime, erros corrigidos, atualizações feitas e horas do banco consumidas. É isso que faz o cliente renovar sem questionar, porque ele vê o trabalho invisível.

Isso não é teoria, é literalmente como a OCA opera. Sistemas como o de gestão para imobiliárias que mantemos em produção seguem esse formato: escopo de sustentação definido, banco de horas, relatório. O cliente sabe o que paga e nós sabemos o que devemos.

As armadilhas que transformam recorrência em escravidão

Retainer mal estruturado é pior do que não ter retainer. Os erros clássicos:

• SLA de plantão a preço de horário comercial. Se você promete resposta em 4 horas a qualquer momento, está vendendo plantão 24/7. Isso custa caro. Ou o SLA é em horas úteis, ou o preço reflete o plantão.
• Banco de horas que acumula para sempre. Horas não usadas expiram no mês ou acumulam por no máximo 60 dias. Sem isso, o cliente junta 6 meses de horas e pede um projeto inteiro de uma vez.
• Feature nova disfarçada de "ajustezinho". A frase "é só adicionar um campo" já escondeu migração de banco, mudança de API e retrabalho de tela. Se muda comportamento do sistema, é evolução e consome banco de horas ou vira orçamento.
• Não reajustar nunca. Contrato de 12 meses com reajuste anual previsto em cláusula. Cobrar o mesmo valor por três anos é dar desconto silencioso de 20%.
• Aceitar retainer de sistema que você não construiu sem auditoria. Herdar código alheio sem olhar antes é assinar responsabilidade por dívida técnica desconhecida. Cobre uma auditoria paga primeiro, depois precifique a manutenção com base no que encontrou.

O efeito composto: três retainers mudam sua vida de freelancer

Faça a conta com números conservadores. Três contratos de manutenção de R$ 2.000 por mês são R$ 6.000 recorrentes antes de você fechar qualquer projeto novo. Isso não te deixa rico, mas muda completamente a sua posição de negociação: você para de aceitar projeto ruim por desespero, para de dar desconto para fechar logo, e prospecta com calma. Se você já entrega bem, o seu problema não é técnico, é distribuição e previsibilidade. O retainer resolve a segunda parte.

E tem um efeito colateral que pouca gente percebe: cliente de manutenção é a sua melhor fonte de projeto novo. Ele já confia em você, já paga todo mês, e quando a empresa dele precisar do próximo sistema, não vai abrir concorrência. Vai te chamar.

Onde a rede de parceiros da OCA entra nisso

Aqui vai o contexto de quem está do outro lado do balcão: a OCA aparece no Google e nas respostas das IAs para buscas de desenvolvimento de software no Brasil, e isso traz dezenas de leads de clientes por dia, mais do que nosso time consegue atender. Parte desses projetos a gente repassa para uma rede de devs seniores de confiança, já com escopo cercado e cliente qualificado.

Muitos desses projetos geram exatamente o que este artigo descreve: um sistema entregue que precisa de sustentação contínua. Ou seja, o parceiro não recebe só o projeto, recebe a chance de construir a própria base de recorrência com um cliente que chegou validado. O que esperamos em troca é o que você esperaria: entrega no prazo, comunicação de adulto e código que outra pessoa consegue manter. Se quiser ver o tipo de produto que construímos e mantemos, o portfólio da OCA mostra o padrão.

Entre para a rede de parceiros da OCA

E independente da rede, uma ação para esta semana: pegue o último projeto que você entregou, escreva uma proposta de sustentação de uma página com as três camadas deste artigo (preventiva, corretiva, banco de horas) e mande para o cliente. O pior cenário é um não, e você já vive nele hoje.