A fatura chegou um ano depois da entrega do sistema. R$ 12.000, descrita como "manutenção adaptativa por upgrade obrigatório de framework". O gestor não sabia o que significava "manutenção adaptativa". Não sabia que o framework ficava desatualizado. Não sabia que ficaria desatualizado tão rápido. E, principalmente, não sabia que isso não estava coberto pelo contrato que tinha assinado doze meses antes.
Esse não é um caso isolado. A ABES estima que mais de 60% das empresas brasileiras não têm contrato de manutenção ativo no momento em que precisam de suporte. É o padrão de quem contrata desenvolvimento de software por projeto, recebe o sistema no prazo, paga o saldo final, e só descobre o custo real de manter aquilo funcionando quando a primeira fatura surpresa aparece.
O momento do aceite: o que acontece quando você assina e a software house vai embora
O aceite de entrega é o fim do projeto para a software house. Para você, é o começo de uma operação que vai precisar de cuidado pelo tempo que o sistema existir.
O que muda depois do aceite:
A garantia contratual cobre bugs que existiam no momento da entrega, por um período definido, geralmente 30 a 90 dias. Qualquer coisa que apareça depois disso depende do que está escrito no contrato de manutenção, se é que existe um.
A infraestrutura começa a custar. Servidor, banco de dados, CDN, domínio, certificado SSL. Esses custos ou estão incluídos em um contrato de sustentação ou vão chegar para você como cobranças avulsas.
A equipe que construiu o sistema segue em frente. O desenvolvedor que conhecia a arquitetura do seu sistema começa outro projeto. Quando você precisar de alteração emergencial, vai pagar a hora de alguém que vai precisar de tempo para entender o que foi feito.
A regra de mercado mais citada no Brasil é: reserve de 15% a 20% do valor de desenvolvimento por ano para manutenção. Um sistema que custou R$ 300 mil para desenvolver vai demandar entre R$ 45 mil e R$ 75 mil por ano para ser mantido. O problema é que esse custo raramente aparece como uma linha única no orçamento. Ele chega como cobranças pulverizadas ao longo do ano, cada uma com uma justificativa técnica diferente.
Os 7 custos recorrentes que aparecem nos primeiros 12 meses de operação
Não são todos eles que aparecem em todo projeto. Mas a maioria aparece em algum momento, e nenhum deles costuma estar claro no contrato de desenvolvimento.
1. Hospedagem e infraestrutura em nuvem. O custo cresce com o uso. Uma instância de banco de dados que começou em R$ 180 por mês pode chegar a R$ 900 quando o volume de usuários aumenta. Isso não é erro da software house, é o modelo de cobrança das plataformas de nuvem. O erro é não ter avisado você.
2. Renovação de certificado SSL. O certificado SSL é o cadeado que aparece no navegador antes do endereço do seu sistema. Ele expira todo ano. Software houses costumam cobrar entre R$ 800 e R$ 1.500 pela renovação. A Locaweb renova automaticamente e sem custo adicional para clientes hospedados na plataforma. Isso significa que a tarefa é automatizável. Quando é cobrada como serviço avulso, você está pagando por 15 minutos de trabalho.
3. Hora de desenvolvedor por chamado emergencial. Software houses brasileiras cobram entre R$ 100 e R$ 300 por hora para desenvolvimento por demanda em 2025. Chamados fora do horário comercial costumam ter adicional. Um bug crítico em domingo à tarde pode custar R$ 600 ou mais antes de você descrever o problema.
4. Monitoramento e backup. Se não estão em contrato, não estão acontecendo. Isso significa que você vai descobrir que o backup não funcionava quando precisar do backup.
5. Upgrade de framework ou linguagem. É a manutenção que gera as maiores surpresas. Classificada no mercado como "manutenção adaptativa", ela responde por cerca de 25% do esforço total de manutenção de software. Não é opcional: um framework desatualizado é um risco de segurança. E não estava no seu contrato.
6. Transferência de dados (egress). Na AWS São Paulo, a transferência de dados de saída custa a partir de US$ 0,138 por GB. É um custo que cresce silenciosamente com o aumento de usuários e que raramente aparece nas estimativas iniciais.
7. Novas funcionalidades classificadas como manutenção. Ou o inverso: manutenção cobrada como desenvolvimento. Sem definição clara no contrato, o escopo de cada tipo de serviço é interpretado por quem emite a fatura.
Hospedagem e infraestrutura: de quanto a quanto você vai pagar por mês no Brasil
Os valores abaixo são de referência para quem usa AWS na região de São Paulo, que é 30% a 60% mais cara que a região de Virginia nos Estados Unidos.
Amazon RDS para PostgreSQL ou MySQL em configuração básica (Single-AZ):
- db.t3.micro, 2 vCPUs e 1 GB de RAM: aproximadamente R$ 114 por mês
- db.t3.small: aproximadamente R$ 229 por mês
- db.t3.medium, 4 GB de RAM: aproximadamente R$ 457 por mês
Uma instância que começa no db.t3.micro e precisa subir para db.t3.medium quando o volume de dados cresce representa uma variação de 4x no custo de banco de dados. Isso não é falha técnica. É o crescimento do sistema funcionando. O problema é que esse crescimento raramente foi projetado na proposta comercial que você recebeu.
Além do banco de dados, existem outros componentes com custo mensal: servidor de aplicação, balanceador de carga, CDN, storage de arquivos, serviço de e-mail transacional, monitoramento. Em projetos que não têm um arquiteto de infraestrutura bem envolvido desde o início, esses custos chegam sem aviso e sem contexto.
Atualizações de segurança: quem cobre quando aparece uma vulnerabilidade no seu sistema
Em outubro de 2023, uma vulnerabilidade crítica foi descoberta no pacote vm2, amplamente usado em sistemas Node.js para isolamento de código. Quem tinha contrato de sustentação recebeu o patch aplicado em 48 horas. Quem não tinha recebeu uma proposta com valor de hora avulsa e prazo de 5 dias úteis para início.
O que define quem cobre: o contrato de sustentação, se existir, e o que está escrito nele sobre "manutenção corretiva" versus "manutenção preventiva".
Manutenção corretiva cobre bugs que você reporta. Manutenção preventiva cobre problemas antes de eles chegarem até você, incluindo patches de segurança. São coisas diferentes. Contratos baratos costumam cobrir só a corretiva.
O Gartner alerta que, até 2025, cerca de 40% do budget médio de TI das empresas é consumido apenas para sustentar a dívida técnica acumulada em sistemas existentes. Uma parte significativa dessa dívida técnica começa em patches de segurança que foram adiados porque não havia contrato ou orçamento para aplicá-los.
Se o seu contrato atual não especifica quem aplica patches de segurança e em qual prazo, você está correndo o risco de manter um sistema vulnerável sem saber.
O que acontece quando o framework ou a linguagem fica desatualizado
Frameworks de desenvolvimento têm ciclos de vida. O Laravel 8 entrou em end-of-life em janeiro de 2023. O Node.js 14 em abril do mesmo ano. O Python 2 em 2020. Quando uma versão chega ao fim do suporte, ela para de receber patches de segurança.
O que acontece na prática: sua software house entrega o sistema em uma versão estável do framework na época da entrega. Dois ou três anos depois, essa versão está fora de suporte. Migrar para a versão atual pode exigir reescrita de partes do código, testes completos e um período de homologação.
Esse trabalho tem nome técnico: manutenção adaptativa. E raramente está previsto em contrato de manutenção padrão.
O Gartner prevê que 80% da dívida técnica será de natureza arquitetural até 2026, o que torna upgrades de framework e migração de infraestrutura não apenas previsíveis, mas inevitáveis. O problema não é que eles vão acontecer. É que quase nenhum contrato os prevê.
Quando esse custo aparece como uma fatura avulsa de R$ 12.000, não é necessariamente um golpe. Pode ser um trabalho real sendo cobrado. O problema é que você não sabia que ia acontecer, não sabia quanto ia custar e não tinha orçamento reservado.
Banco de dados, backup e monitoramento: quem é dono disso no seu contrato
Essa é a parte que mais frequentemente fica em zona cinzenta.
O sistema foi entregue rodando. O banco de dados está lá, com os dados. Alguém criou o ambiente de produção. Mas quem é responsável por:
- Garantir que o backup está sendo feito e funcionando
- Monitorar se o servidor caiu ou está com lentidão
- Escalar a infraestrutura quando o volume de dados crescer
- Receber o alerta quando o disco de armazenamento estiver a 90% da capacidade
Se isso não está escrito no contrato, a resposta é: ninguém. Ou melhor, a responsabilidade vai aparecer quando o problema aparecer, e junto com ela vai vir uma fatura que você não esperava.
Um cliente chegou com uma fatura de R$ 3.800 por restauração de banco de dados. O backup estava configurado no ambiente, mas nunca havia sido testado. A última cópia utilizável tinha 11 dias. Tudo que aconteceu nesse intervalo precisou ser reinserido manualmente. O contrato de manutenção não citava responsabilidade por backup, então o chamado foi cobrado como hora avulsa.
Bugs pós-garantia: o que está no contrato e o que você vai pagar à parte
O período de garantia cobre bugs que existiam no momento da entrega e não foram detectados nos testes de homologação. Quando esse período termina, qualquer bug que aparecer é cobrado como serviço avulso.
O que a maioria dos gestores não sabe: em contratos padrão brasileiros, alterações feitas no software a pedido do contratante e fornecimento de novas versões tipicamente não são considerados manutenção e devem ser cobrados separadamente. Isso significa que uma mudança de regra de negócio que gera um comportamento diferente do esperado pode não ser tratada como bug, mesmo que seja um problema do seu ponto de vista.
A manutenção corretiva responde por cerca de 20% do esforço total de manutenção de um software. Os outros 80% são adaptativa (mudanças de ambiente e frameworks, 25%) e evolutiva (novas funcionalidades, 50%). Quando você paga uma mensalidade de manutenção e espera que ela cubra tudo, normalmente está coberta apenas a parte corretiva.
Houve um caso documentado no Tribunal de Justiça de Santa Catarina em que uma empresa de software teve o contrato rescindido judicialmente por não cumprir o serviço prometido. Disputas sobre escopo de manutenção chegam ao Judiciário. O Código de Defesa do Consumidor, artigo 42, determina restituição em dobro de valores cobrados indevidamente em contratos de serviço. O contrato bem redigido protege as duas partes. O contrato vago protege quem tem mais advogado.
As 12 perguntas que você deve fazer antes de assinar qualquer contrato de desenvolvimento
Essas perguntas servem para contrato novo e para aditivo de manutenção em sistema que já existe. Leve por escrito e peça resposta por escrito.
Sobre infraestrutura:
- Quem paga a conta de nuvem mensalmente, e em qual conta (minha ou da software house) os serviços estão provisionados?
- Qual é a estimativa de custo de infraestrutura por mês no lançamento, e qual a projeção para quando o volume dobrar?
- O contrato de hospedagem é em meu nome ou no nome da software house? O que acontece com os dados se eu rescindir o contrato?
Sobre segurança:
- Quem aplica patches de segurança quando uma vulnerabilidade é descoberta em uma biblioteca usada no sistema? Em quanto tempo?
- O certificado SSL é renovado automaticamente? Quem cobre o custo?
Sobre banco de dados e backup:
- Como o backup é feito, com que frequência e onde fica armazenado? Quando foi o último teste de restauração?
- Quem monitora o ambiente em produção? Como recebo alerta se o sistema cair?
Sobre manutenção e upgrades:
- O que está incluído na mensalidade de manutenção? Manutenção corretiva, adaptativa e evolutiva estão todas inclusas, ou somente a corretiva?
- Quando o framework ou a linguagem usada no sistema ficar fora de suporte, quem paga pela migração? Tem estimativa de custo?
Sobre chamados e atendimento:
- Qual é o custo de um chamado avulso fora da mensalidade? E fora do horário comercial?
- Qual é o SLA para chamados críticos (sistema fora) versus chamados normais (bug não crítico)?
Sobre encerramento de contrato:
- Se eu quiser migrar o sistema para outra empresa no futuro, o que recebo: código-fonte, documentação técnica, acesso ao banco de dados, credenciais de infraestrutura?
Nenhuma dessas perguntas é agressiva. Qualquer software house séria vai responder sem hesitar. A que hesitar provavelmente não tem resposta documentada para pelo menos uma dessas perguntas, e isso já é o que você precisa saber antes de assinar.
Como mapear o que você realmente tem antes do próximo aditivo
Se o sistema já foi entregue e você não tem respostas claras para as perguntas acima, o primeiro passo é mapear o que você tem.
Comece verificando em que nome os serviços de nuvem estão provisionados, porque se estiverem no CNPJ da software house, você não tem acesso direto a nada. Depois leia o contrato de manutenção como se fosse pela primeira vez, sem presumir o que está coberto. A maioria dos gestores se surpreende com o que não está lá.
Com esse mapeamento em mãos, você pode ter uma conversa técnica produtiva com sua software house atual, ou com uma nova, sem depender da boa vontade de quem tem as credenciais de acesso.
Comece pelas perguntas 1, 6 e 9. São as três com maior impacto financeiro imediato e as mais difíceis de recuperar depois que o problema aparece.
Se você não sabe responder de cabeça quem paga o backup, quem aplica patch de segurança e o que acontece com o framework quando ele sair de suporte, essas lacunas vão aparecer como fatura avulsa mais cedo ou mais tarde. A Coffe&Code Labs faz diagnóstico técnico de sistemas entregues por outras empresas: mapeia infraestrutura, estado das tecnologias usadas, cobertura real do contrato atual e projeta os custos de sustentação por linha. Se você está renovando contrato de manutenção ou acabou de receber uma cobrança de manutenção adaptativa que não esperava, veja nosso serviço de desenvolvimento de sistemas para empresas ou agende um diagnóstico.