Quanto custa manter um produto digital no ar por ano

O orçamento de um projeto digital quase sempre se concentra no custo de construção. É o número que aparece na proposta, o que passa pela aprovação e o que fica na memória de todos. Mas manter o produto no ar depois que ele sobe tem um custo próprio, recorrente, e ignorá-lo é uma das causas mais comuns de projetos que “morrem” um ou dois anos depois do lançamento — não por falta de uso, mas por falta de verba prevista para operação.

Este artigo separa esse custo em três blocos — infraestrutura, sustentação e evolução — e dá referências para estimar cada um, além dos custos indiretos que raramente entram na conta. Os valores absolutos variam muito por porte e arquitetura, então o foco aqui é o método de estimativa, não uma tabela de preços.

Bloco 1 — Infraestrutura

É o custo de manter a aplicação rodando, acessível e rápida. Mesmo um site institucional simples tem uma conta aqui. Os itens típicos:

Hospedagem ou cloud — servidores ou serviços gerenciados, dimensionados pelo tráfego e pela carga de processamento.
Banco de dados — armazenamento e capacidade de processamento, muitas vezes contratado como serviço gerenciado à parte.
CDN e armazenamento de mídia — para servir imagens, vídeos e arquivos com velocidade a partir de pontos próximos do usuário.
E-mails transacionais — confirmações de cadastro, recuperação de senha, notificações. Cobrados por volume.
Domínios e certificados — renovações anuais, incluindo domínios defensivos.
Serviços de terceiros — busca, mapas, gateways de pagamento, antifraude, ferramentas de análise, envio de SMS.

Para um site institucional ou portal de conteúdo de porte médio, a infraestrutura costuma ser a menor das três linhas. Para um sistema com muitos usuários simultâneos ou processamento pesado, pode ser a maior. O ponto de atenção é que contas de cloud crescem sozinhas: recursos ficam ligados sem uso, dimensionamentos ficam superestimados “por segurança”, ambientes de teste esquecidos continuam cobrando. Sem um acompanhamento mensal do custo por serviço, a conta incha de forma silenciosa.

Bloco 2 — Sustentação

É o custo de manter a plataforma saudável, segura e funcionando. É a linha mais esquecida no orçamento e a que mais dói quando falta, porque a ausência de sustentação só se revela quando já virou incidente.

Atualização de plataforma e dependências — CMS, frameworks, bibliotecas, sistema operacional. Vulnerabilidades de segurança são descobertas continuamente; deixar de atualizar é acumular risco que um dia é cobrado de uma vez.
Monitoramento e resposta a incidentes — alguém precisa saber quando o site cai, e precisa saber antes do cliente ligar reclamando.
Backups e testes de restauração — ter backup não basta; é preciso testar a restauração periodicamente para saber que ela funciona e quanto tempo leva.
Correções — bugs que aparecem com o uso real, com navegadores novos, com o volume de dados crescendo, com casos que ninguém previu.
Ajustes de conteúdo e configuração — pequenas mudanças que a equipe interna não consegue ou não deve fazer sozinha.
Suporte — um canal para a sua equipe reportar problemas e tirar dúvidas, com prazo de resposta acordado por severidade.

Uma referência prática de mercado: contratos de sustentação costumam ser precificados como uma fração do custo de construção por ano, e essa fração cresce com a criticidade e a complexidade do sistema. Um site institucional exige pouco. Uma plataforma transacional, com dinheiro ou dados sensíveis em jogo, exige acompanhamento próximo e contínuo, e a fração é bem maior.

Bloco 3 — Evolução

Todo produto que continua sendo usado gera pedidos de melhoria: um relatório novo, um campo a mais no cadastro, uma integração com um sistema que a empresa passou a usar, uma tela repensada depois de meses de uso real que mostraram onde as pessoas travam. Evolução não é defeito de escopo; é sinal de que o produto está vivo e atendendo o negócio.

O erro é não reservar verba para isso. Quando não há capacidade contratada para evolução, cada pedido vira um mini-projeto: levantamento, orçamento, aprovação, fila, mobilização de time que estava em outra coisa. O resultado é que melhorias pequenas demoram meses e as mudanças que não podem esperar viram emergência, cobradas com prêmio de urgência.

A alternativa é reservar uma capacidade previsível — um número de horas ou um valor mensal — dedicada a evolução, com a lista priorizada em conjunto a cada ciclo. Isso mantém o produto acompanhando o negócio sem sobressaltos no caixa e sem o desgaste da negociação constante.

Custos indiretos que também contam

Licenças de software — plugins e temas pagos, ferramentas de build, painéis de observabilidade, serviços de erro e de performance.
Conformidade — LGPD, acessibilidade digital, requisitos setoriais. Todos exigem revisão periódica, não só um esforço único no lançamento.
Documentação e onboarding — manter a documentação viva tem custo, mas é muito menor do que o custo da dependência de uma única pessoa que “sabe como funciona”.
Tempo interno — reuniões de acompanhamento, testes de homologação, aprovação de entregas. Não sai da conta do fornecedor, mas sai da sua.

Como montar a estimativa anual

Levante a infraestrutura atual item a item e projete o crescimento esperado de tráfego e de volume de dados para os próximos doze meses.
Defina a criticidade do sistema em duas perguntas: quanto tempo fora do ar o negócio tolera e quanto dado aceita perder num incidente.
A partir da criticidade, dimensione a sustentação: frequência de atualização, nível de monitoramento, prazos de resposta, cobertura de horário.
Reserve uma verba de evolução proporcional ao ritmo de mudança do negócio — quanto mais o negócio muda, mais o produto vai precisar mudar junto.
Some tudo e compare com o custo de construção. Se a operação anual for uma fração muito pequena da construção, provavelmente está subdimensionada e a conta vai chegar depois.

Um exemplo ilustrativo

Imagine um portal de conteúdo de porte médio, construído ao longo de alguns meses. No primeiro ano de operação, os custos tendem a se distribuir assim: infraestrutura é a menor linha, cobrindo hospedagem, banco, CDN, e-mails e alguns serviços de terceiros. Sustentação é a linha do meio, com atualizações mensais, monitoramento, backups testados, um pacote de horas de correção e um canal de suporte. Evolução costuma ser a maior linha nos primeiros dois anos, porque é quando o produto mais aprende com o uso real e mais precisa mudar.

Somadas, essas três linhas raramente ficam abaixo de um quinto do custo de construção por ano para um sistema que é usado de verdade — e para plataformas críticas, transacionais, a proporção é bem maior. Quando alguém apresenta um custo de operação simbólico, quase sempre está deixando de fora a sustentação, a evolução, ou as duas.

Erros comuns na estimativa

Tratar sustentação como opcional. “A gente contrata se precisar” significa, na prática, contratar às pressas depois de um incidente, pagando mais e com o estrago já feito.
Subestimar a evolução. A lista de melhorias que os usuários vão pedir não cabe na sua imaginação hoje; ela nasce do uso.
Esquecer o tempo interno. Reuniões, homologação, aprovação de entregas e testes de aceite consomem horas da sua equipe todo mês.
Ignorar o crescimento. A infraestrutura que serve mil usuários não é a mesma que serve cem mil; o custo escala com o sucesso.
Não revisar contratos de terceiros. Preços de serviços de nuvem, gateways e ferramentas mudam, e planos antigos nem sempre são os mais econômicos.

Internalizar ou terceirizar a operação

Uma decisão que aparece cedo é se a operação deve ser feita por um time interno ou por um parceiro. Não há resposta única. Times internos fazem sentido quando o volume de trabalho justifica uma pessoa dedicada em tempo integral, quando o conhecimento do domínio é muito específico e quando a empresa quer construir capacidade técnica própria.

Parceiros fazem sentido quando o volume de trabalho é intermitente — algumas horas por semana, com picos —, quando a empresa não quer gerir carreira técnica e quando a cobertura precisa ser mais ampla do que uma pessoa consegue dar (férias, doença, horários fora do comercial). Muitas empresas adotam um modelo misto: um responsável interno pela relação e pelas prioridades, e um parceiro executando a sustentação e a evolução.

Como o custo evolui ao longo dos anos

O perfil de custo de um produto digital muda com o tempo. No primeiro ano, a evolução domina: o produto está aprendendo com o uso e recebendo ajustes constantes. Entre o segundo e o terceiro ano, se o produto amadureceu, a evolução tende a diminuir e a sustentação se estabiliza como a linha principal. A infraestrutura cresce de forma mais ou menos proporcional ao uso.

Existe um risco no sentido contrário: produtos que ficam anos sem evolução acumulam dívida de forma silenciosa. As dependências envelhecem, as integrações com terceiros mudam, o navegador evolui. Quando finalmente é preciso mexer, o custo de “colocar em dia” é alto. Um mínimo de evolução contínua é mais barato do que grandes saltos periódicos.

Perguntas para levar à mesa de negociação

O que exatamente está incluído em “manutenção” — só corrigir o que quebra, ou também atualizar plataforma e dependências?
A atualização de segurança é aplicada de forma proativa ou só quando eu peço?
Qual é o prazo de resposta para cada nível de severidade?
O backup é testado? Com que frequência? Quem me avisa se falhar?
A infraestrutura e a conta de cloud estão dentro do contrato ou são repassadas?
Como funciona a evolução: pacote de horas, valor fixo, sob demanda?
Recebo relatório do que foi feito e do custo de infraestrutura?

O custo invisível de não ter operação

Quando não há um plano de operação, o custo não desaparece — ele muda de forma. Vira o tempo da sua equipe tentando resolver um problema técnico que não domina. Vira o prejuízo de um dia fora do ar sem ninguém para acionar. Vira a multa por um vazamento de dados que uma atualização teria evitado. Vira a reconstrução completa daqui a três anos, porque o sistema virou uma caixa-preta que ninguém mantém.

Somados ao longo do tempo, esses custos invisíveis quase sempre superam o valor de um contrato de sustentação bem dimensionado. A diferença é que o contrato é previsível e o resto chega de surpresa, no pior momento.

Como a Jumps organiza esse custo

A sustentação e evolução da Jumps transforma esses três blocos em um plano previsível: infraestrutura acompanhada mês a mês com relatório de custo, sustentação com níveis de serviço definidos por severidade e uma capacidade de evolução priorizada junto com o cliente a cada ciclo. Assim o custo de manter o produto no ar deixa de ser uma sucessão de surpresas e passa a ser uma linha de orçamento tratável.

Se você tem um produto no ar sem um plano de operação claro, fale com a Jumps para um diagnóstico das três linhas.