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. É 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.
Como referência de planejamento, trate manutenção como orçamento anual, não como favor do fornecedor. Um sistema que custou caro para desenvolver também terá custo recorrente para continuar seguro, atualizado e disponível. 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. Banco de dados, servidor, storage, filas, CDN e e-mail transacional podem começar pequenos e subir quando o volume 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. Certificado SSL. O certificado SSL é o cadeado que aparece no navegador antes do endereço do seu sistema. Em muitos ambientes modernos ele pode ser automatizado, mas isso precisa estar configurado e monitorado. Quando ninguém é responsável por isso, o problema aparece na pior hora.
3. Hora de desenvolvedor por chamado emergencial. Chamado fora de contrato costuma ser cobrado como demanda avulsa. Chamado fora do horário comercial pode ter adicional. Um bug crítico no fim de semana pode custar caro antes mesmo de alguém entender 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 envolve mudanças para manter o software compatível com ambiente, dependências e versões suportadas. Não é opcional: um framework desatualizado é um risco de segurança. E nem sempre está no contrato.
6. Transferência de dados (egress). Algumas plataformas de nuvem cobram transferência de dados de saída. É 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 não são tabela de preço de fornecedor. São faixas de raciocínio para você entender o que precisa aparecer na proposta.
Em um sistema pequeno, a infraestrutura pode envolver:
- servidor de aplicação
- banco de dados
- armazenamento de arquivos
- backup
- domínio e DNS
- e-mail transacional
- monitoramento
Quando o volume cresce, o banco de dados costuma ser um dos primeiros pontos de ajuste. Mais armazenamento, mais memória, mais conexões simultâneas e backup mais robusto aumentam o custo recorrente. 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
Vulnerabilidades em bibliotecas, frameworks e serviços de terceiros aparecem com frequência. Quem tem contrato de sustentação com escopo claro sabe quem avalia, prioriza e aplica o patch. Quem não tem recebe uma proposta avulsa quando o problema já virou urgência.
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.
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 problema não é que upgrades vão acontecer. É que quase nenhum contrato simples prevê como eles serão avaliados, estimados, testados e cobrados.
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 de software costuma misturar categorias diferentes: corretiva, adaptativa, preventiva e evolutiva. Quando você paga uma mensalidade de manutenção e espera que ela cubra tudo, normalmente descobre tarde demais que cada fornecedor usa essas palavras de um jeito.
Disputas sobre escopo de manutenção acontecem porque "bug", "melhoria", "ajuste", "evolução" e "suporte" parecem palavras simples até a fatura chegar. O contrato bem redigido protege as duas partes. O contrato vago protege quem consegue impor a própria interpretação.
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.
Fontes consultadas: AWS sobre transferência de dados e documentação de ciclos de vida de Node.js, Laravel e Python.