Manutenção mensal no freelance dev: como transformar projeto entregue em receita recorrente (quanto cobrar e o que incluir no contrato)

Você entregou o projeto. O cliente aprovou, pagou a última parcela, mandou um “ficou ótimo” no WhatsApp e sumiu. Quatro meses depois ele volta. O app parou de enviar notificação, o certificado venceu, ou a Google Play mandou um aviso de que a próxima atualização vai ser bloqueada. Ele quer “só uma ajudinha rápida”. Você para o projeto atual, resolve em uma tarde e fica sem saber se cobra, quanto cobra e como cobra.

Enquanto isso, o seu faturamento zera a cada fim de projeto. Todo mês começa do mesmo lugar: procurando o próximo cliente, aceitando o que aparecer e torcendo para não ter buraco no caixa.

Se esse ciclo parece familiar, o problema não é falta de cliente. É que você trata a entrega como o fim da relação, quando ela é o começo da parte mais previsível do negócio: a manutenção mensal.

Por que software entregue nunca fica pronto (e por que isso é receita, não favor)

Software parado apodrece. Não porque o código piora sozinho, mas porque o mundo em volta dele muda. Na Revo, que roda com mais de 40 mil usuários cadastrados, não existe mês sem manutenção: upgrade de SDK do Expo, dependência com vulnerabilidade, mudança de regra na loja, ajuste no gateway de pagamento. Isso não é teoria, é a rotina de qualquer produto em produção.

O que muda em volta do sistema do seu cliente, mesmo que ninguém encoste no código:

• Exigências das lojas. Apple e Google sobem o SDK mínimo todo ano. App que não acompanha fica impedido de publicar atualização.
• Dependências. Pacotes do npm recebem alertas de segurança toda semana. Ignorar por seis meses vira um upgrade de três dias.
• Certificados e chaves. Push notification, SSL, tokens de API, contas de desenvolvedor. Tudo tem data de validade.
• APIs de terceiros. Gateway de pagamento, WhatsApp, mapas, ERP do cliente. Versão antiga é descontinuada com aviso que só o dev lê.
• Crescimento. O banco que respondia em 50 ms com mil registros responde em 3 segundos com 500 mil. O plano gratuito do serviço estoura.

A verdade desconfortável é que a maioria dos devs não oferece manutenção por medo de parecer que está empurrando algo desnecessário. Só que o cliente vai precisar de qualquer jeito. A única pergunta é se vai ser planejado, com preço combinado, ou emergência, com você largando outro projeto e cobrando no constrangimento.

Outro ponto que confunde muita gente: garantia não é manutenção. A garantia cobre defeito do que você entregou, por um prazo fechado. A manutenção cobre o mundo mudando em volta do software, sem prazo para acabar. Uma é obrigação sua. A outra é um serviço que se paga.

O que entra (e o que não entra) num contrato de manutenção de software

Um plano de manutenção bom é chato de propósito. Ele descreve atividades recorrentes, verificáveis, que o cliente consegue entender sem ser técnico.

O que entra

• Monitoramento de disponibilidade e de erros (UptimeRobot, Sentry, logs do provedor).
• Atualização de dependências e aplicação de patches de segurança.
• Backups verificados, com teste de restauração pelo menos uma vez por trimestre.
• Renovação de certificados, chaves e contas de desenvolvedor.
• Adequação às exigências anuais da App Store e da Google Play.
• Correção de falhas causadas por mudança externa (API que mudou, biblioteca que quebrou).
• Pequenos ajustes dentro de um banco de horas definido.
• Relatório mensal curto com o que foi feito e o que vem pela frente.

O que fica de fora

• Funcionalidade nova acima do banco de horas. Isso é projeto, com proposta própria.
• Redesign, nova integração, novo módulo.
• Custo de infraestrutura. O ideal é o cliente pagar direto, na conta dele.
• Suporte ao usuário final do cliente. Você atende o cliente, não os clientes dele.

Escreva as duas listas no contrato. A segunda evita mais briga que a primeira.

Quanto cobrar por manutenção mensal de software em 2026

Não existe tabela oficial, mas os planos que funcionam no mercado brasileiro caem em três faixas. Os valores abaixo consideram uma hora de dev sênior entre R$ 120 e R$ 250.

O que empurra o preço para cima dentro de cada faixa:

• App mobile custa mais que web. São duas lojas, dois ciclos de revisão e mais dependências nativas.
• Pagamento e dados sensíveis. Checkout quebrado é venda perdida. Criticidade alta pede resposta rápida, e resposta rápida custa.
• Código herdado. Manter código que você não escreveu exige diagnóstico antes e mais tempo depois.
• Fora do horário comercial. Atendimento em fim de semana entra como adicional, nunca como padrão.

Um atalho para checar se o número faz sentido: entre 1,5% e 3% do valor do projeto por mês. Um sistema de R$ 60 mil ficaria entre R$ 900 e R$ 1.800 mensais. Use como teste de sanidade, não como regra.

A conta é simples. Quatro clientes no plano Padrão a R$ 2.000 somam R$ 8.000 por mês antes do primeiro projeto novo. Não é renda garantida, porque cliente cancela, mas é uma base que muda o jeito como você negocia. Quem tem o aluguel coberto consegue recusar projeto ruim.

Só não esqueça o outro lado da conta: quatro contratos de 10 horas são 40 horas por mês, um quarto da sua capacidade. Venda só as horas que cabem na sua agenda. Nem todo mês o cliente usa tudo, e tudo bem. Você também está vendendo disponibilidade.

Banco de horas: acumula ou expira?

Defina que a hora não usada expira no fim do mês, ou acumula por no máximo um mês. Sem esse limite, o cliente junta 60 horas ao longo do ano e pede uma feature grande em dezembro, pelo preço da manutenção. Hora excedente entra com valor fixo no contrato, igual à sua hora avulsa ou até 20% acima dela.

Como oferecer o plano de manutenção sem parecer que está empurrando venda

O erro mais comum é oferecer manutenção só quando algo já quebrou. Aí soa como oportunismo. O momento certo é antes.

1. Coloque na proposta original. Uma linha separada, opcional, com o valor mensal. O cliente fica sabendo desde o primeiro dia que software tem custo de manutenção.
2. Na entrega, entregue a lista do que vai precisar de atenção. Um documento curto com datas: o certificado vence em março, a versão atual do Expo perde suporte no meio do ano, a Google Play exige o novo SDK até agosto. Coisa concreta convence sem pressão.
3. Comece o plano depois da garantia. Garantia de 60 a 90 dias, e o plano entra em seguida. Fica claro que você não está cobrando para corrigir o próprio erro.

Uma mensagem que funciona no momento da entrega:

Oi, Fulano. O sistema está em produção e estável. Separei o que vai precisar de atenção nos próximos meses: [item 1 com data], [item 2 com data], [item 3 com data]. Posso cuidar disso em um plano mensal de R$ X, com até Y horas, resposta em 1 dia útil e um relatório no fim de cada mês. Se preferir, também atendo sob demanda, a R$ Z por hora, sem prazo de resposta garantido. Qual formato faz mais sentido para vocês?

Repare que a opção avulsa existe, mas é mais cara por hora e não tem prazo. Você não esconde a alternativa, só deixa claro o que cada uma entrega.

Os erros que transformam manutenção em trabalho de graça

• “Pequenos ajustes ilimitados.” Essa frase no contrato transforma um plano de R$ 1.500 em um dev contratado em tempo integral. Sempre horas, nunca “ilimitado”.
• Prazo de resposta sem horário. “Resposta em 24 horas” vira mensagem de sábado à noite. Escreva dias úteis, horário comercial e o que conta como falha crítica.
• Assumir código alheio sem diagnóstico. Antes de manter um sistema que você não construiu, cobre um diagnóstico de 8 a 16 horas. Você descobre o tamanho do problema e o cliente entende por que o plano custa o que custa.
• Infraestrutura no seu cartão. Quando o cliente cancela, você fica com a conta da AWS e a dor de cabeça de migrar. Servidor, domínio e lojas ficam na conta do cliente desde o início.
• Valor congelado. Sem cláusula de reajuste anual, pelo IPCA ou por um percentual fixo, você trabalha cada ano mais barato.
• Sem aviso prévio. Peça 30 dias para cancelamento, dos dois lados. Dá tempo de passar a operação adiante sem deixar ninguém na mão.
• Trabalho invisível. Se o cliente não vê o que você fez, acha que paga por nada e cancela no terceiro mês. Um relatório de cinco linhas resolve: o que foi atualizado, o que foi corrigido, o que vem no próximo mês.

Por que a OCA olha para quem mantém, não só para quem entrega

Vou te falar como funciona do lado de quem recebe os leads: uma parte relevante dos contatos que chegam à OCA pelo Google e pelas IAs não é projeto novo. É empresa com sistema parado porque o dev entregou e sumiu. App fora da loja, servidor que ninguém sabe acessar, integração quebrada há meses. Esse cliente chega desconfiado, e com razão.

A OCA aparece no Google e nas IAs, e isso traz mais demanda do que o time consegue atender. Por isso estamos montando uma rede de parceiros: devs e times pequenos seniores que recebem projetos já qualificados, com escopo cercado e cliente que chegou procurando exatamente aquele serviço. Quando a gente avalia para quem repassar um projeto, uma das primeiras perguntas é: quem cuida disso depois da entrega? Parceiro que já trabalha com plano de manutenção, contrato claro e relatório mensal é parceiro em quem o cliente confia por anos.

O que a gente espera de quem entra: experiência real de produção, documentação na entrega, contrato escrito e comunicação sem sumiço. O que o parceiro recebe: projeto vindo de uma demanda que ele não precisou gerar, com o cliente já filtrado. A gente não promete volume nem aceitação automática. Tem conversa, análise de portfólio e um primeiro projeto para os dois lados se conhecerem. Se quiser ver o padrão de entrega que a gente busca, dá uma olhada nos projetos que a OCA opera em produção.

Entre para a rede de parceiros da OCA

O que fazer esta semana, entrando ou não na rede

1. Liste os últimos cinco projetos que você entregou.
2. Para cada um, escreva três coisas que vão precisar de atenção nos próximos seis meses, com data.
3. Defina seus três planos, com horas, prazo de resposta e preço, antes de falar com qualquer cliente.
4. Mande a mensagem acima para os dois clientes cujos sistemas têm usuários ativos.

Se um aceitar, você terminou a semana com a primeira receita que não depende de fechar projeto novo. Se você já entrega bem, o seu problema não é técnico, é o que acontece depois da entrega.