Custo de manutenção de software: a linha do orçamento que todo fundador não-técnico subestima
Um guia direto para fundador não-técnico sobre o que você de fato paga depois do lançamento, por que “15% do build” é a regra errada para startup em estágio inicial, e o diagnóstico de cinco perguntas para estimar o número real antes que ele chegue.
Um fundador com quem trabalhamos ano passado entregou um MVP limpo de US$ 86 mil. Checkout via Stripe, painel administrativo, um aplicativo mobile pequeno. Fechou a rodada seed no prazo, contou para o board que o risco técnico estava resolvido. Nove meses depois, ele encaminhou uma fatura de US$ 14.200 e perguntou o que tinha acontecido.
O que tinha acontecido era ordinário. A AWS depreciou o runtime do Node 14 em que as Lambdas dele rodavam. O provedor de pagamento mandou aviso de 60 dias sobre uma mudança de assinatura de webhook que ele não conseguia ler. O target SDK do Android estava prestes a cair abaixo do mínimo da Play Store, o que tiraria o app da loja inteiramente. O Sentry, adicionado num plano gratuito no mês 1, tinha cruzado para um tier de US$ 79/mês sem ninguém perceber. E o único developer dele tinha saído três meses antes, então o fundador precisou trazer um contractor de US$ 190/hora para correr atrás de tudo isso.
Nada disso foi surpresa para ninguém que entrega software para viver. Tudo isso foi surpresa para ele.
Custo de manutenção de software é o custo operacional recorrente de manter um sistema vivo rodando, seguro e útil depois do lançamento. Ele é separado do custo de build. Não é 15% de nada de forma significativa. E para startup em estágio inicial, é a linha mais consistentemente subestimada do orçamento nos primeiros dezoito meses de um produto real no ar.
Este texto é um framework de orçamento para fundador não-técnico. Ele nomeia as três coisas que você de fato está pagando, explica por que a regra do percentual padrão falha no seu estágio, lista os custos escondidos que ninguém te cota, e te dá um diagnóstico de cinco perguntas para estimar o número real antes de assinar qualquer coisa.
As três coisas que você de fato está pagando
Toda cotação crível de manutenção de software cobre alguma combinação de três categorias. A maioria das cotações não as separa. A maioria dos fundadores, por consequência, não consegue dizer qual delas está comprando o suficiente.
Manter as luzes acesas
O trabalho que tem que acontecer para o produto continuar vivo, com ou sem feature nova. Patches de segurança. Atualização de dependências. Upgrade de runtime quando o cloud provider deprecia o que você está usando. Renovação de certificado. Verificação de backup. Migração quando Stripe ou o equivalente local muda contrato de webhook. Mudanças de breaking change em browser e mobile OS.
Esse trabalho não é negociável. Se você pular, o produto eventualmente quebra de um jeito que sai mais caro consertar do que o trabalho teria sido. O fundador acima pagou US$ 14.200 num mês em grande parte porque nove meses de manter-as-luzes-acesas pulados estouraram juntos.
Para um produto SaaS ou marketplace típico de pré-A a Série A com um a três serviços em produção, orce 8 a 25 horas por mês de tempo focado de engenharia. Isso mapeia para algo entre US$ 1.500 e US$ 5.000 por mês a taxas razoáveis de contractor.
Pequenos ajustes
Bugs em produção. Edge cases que o beta não pegou. Um cliente específico não consegue logar. Um export gera um CSV malformado. Um off-by-one de timezone quebra um relatório diário. O form de signup rejeita um formato de email real.
A maioria dos fundadores não-técnicos olha para essa categoria e pensa “coisas dando errado”. É mais preciso pensar nela como o ruído irredutível de operar um produto real com usuários reais. Um produto com zero pequenos ajustes é um produto que ninguém está usando.
O volume aqui escala com usuários ativos diários e cadência de release, não com tamanho do código. Um produto B2B com 40 clientes gera de dois a seis pequenos ajustes por mês. Um produto B2C com 5.000 ativos gera vinte. Orce 15 a 40 horas por mês para produto em estágio inicial. Fundador subestima essa categoria pela metade porque o teste que ele fez pessoalmente antes do lançamento surfaceou uma fração pequena do que os usuários reais vão surfacear.
Evoluir
O trabalho que não é bem manutenção e não é bem produto novo. É manter o software com a forma do seu negócio enquanto o negócio muda. A página de pricing que você lançou tinha três tiers; a operação de vendas que você usa de verdade tem quatro. O onboarding assumia self-serve; seus clientes reais são demos guiadas. O painel admin funciona para um operador; agora você tem três e cada um quer filtros diferentes.
Se você não orça para evoluir, toda mudança de negócio vira um debate sobre fazer agora ou esperar o próximo release grande. Esse debate sai mais caro do que o trabalho. Para uma startup iterando no modelo, orce 20 a 60 horas por mês nos primeiros dezoito meses pós-lançamento, caindo conforme o modelo estabiliza.
Essas três categorias somam. Elas não substituem uma à outra. Uma cotação que não as nomeia é uma cotação que você não consegue pressionar.
Por que a regra “15% do custo de build” é errada para fundador
Pergunte à internet quanto custa manutenção de software e você recebe um percentual. Quinze por cento do build. Vinte. Às vezes trinta. Essa regra vem do lifecycle management de software enterprise, onde o escopo é estável, a base de usuários é limitada, e a maior parte do trabalho de manutenção é manter-as-luzes-acesas mais patches menores num horizonte de cinco a dez anos.
Esse mundo não é o seu mundo.
Nos primeiros dezoito meses pós-lançamento, o seu escopo não é estável. Você ainda está achando product-market fit. Seu bucket de evoluir às vezes é maior que o seu custo de build porque cada conversa com cliente refaz a superfície. Sua base de usuários cresce uma ordem de magnitude por trimestre, ou seja, cada bug de pequenos-ajustes aparece para dez vezes mais gente por mês. Seu stack é mais novo e menos estável que um codebase enterprise, então o churn de dependência bate mais forte. E sua equipe é menor, então não tem ninguém para absorver um email de depreciação sem botar na fatura.
Para uma startup típica de seed a Série A, o custo anual real de manutenção de software nos anos um e dois costuma cair entre 40% e 80% do custo original de build, não 15%. No ano três, conforme o escopo se estabiliza, esse número pode cair para 20% a 30% se a engenharia foi bem feita. Se não foi, o número do segundo ano é ainda mais alto porque todo atalho do build veio cobrar.
A regra dos 15% não é mentira. É uma medição de um sistema diferente, aplicada ao seu, e é um dos números emprestados mais caros do software em estágio inicial. Se um fornecedor te cota um pacote de manutenção a 15% do custo de build, pergunte qual das três categorias está sendo coberta. Quase com certeza eles estão cotando só manter-as-luzes-acesas.
As linhas escondidas que ninguém te cota
Quando você pede uma cotação de manutenção a um fornecedor, recebe um número que inclui as horas de engenharia deles. Quase nunca recebe o resto da conta.
Dependências de SaaS terceiros. Sentry, Postmark, Datadog, Auth0, Twilio, Segment, Mixpanel, Stripe Billing, Plaid, seu CDN, seu provedor de email transacional, seu captcha, seu scheduler. A maioria tem um tier gratuito em que você cabe no lançamento e um tier real em que você cresce por volta do mês quatro. O burn mensal acumulado para um produto Série A típico fica entre US$ 400 e US$ 2.000, e quase nada disso aparece na cotação original.
Crescimento de custo de infra. Sua conta da AWS ou GCP no dia 1 é pequena porque o tráfego é pequeno. O crescimento raramente é linear; uma query que funcionava bem em 1.000 linhas vira um timeout diário em 100.000. O fundador que pula uma revisão trimestral de infra é o fundador cuja conta de cloud triplicou de repente em outubro.
Mudanças de preço de API nas suas dependências. A OpenAI sobe preço de modelo. O Stripe pega uma fatia maior em um método de pagamento que você depende. Seu provedor de geocoding aperta o rate limit no plano em que você ficou grandfathered. Nada disso é negociável no momento; tudo isso tem que ser absorvido ou contornado com trabalho de engenharia.
Cobertura de on-call. Se o seu produto precisa estar no ar às 2 da manhã e a única pessoa que conhece o sistema está dormindo, você não tem um produto mantido, tem um produto frágil. On-call é ou uma linha explícita (um fractional CTO com janela de resposta definida, um provedor externo de SRE, um contractor em retainer) ou um custo implícito que aparece como o seu único developer queimando em silêncio.
Resposta a incidente de segurança. A probabilidade por ano de um evento de segurança que demanda trabalho real não é trivial mesmo para produtos pequenos. Uma chave de API exposta no GitHub. Um vazamento de credencial. Uma regra de WAF que bloqueia um cliente real. Um DDoS que custa um fim de semana. A resposta é paga em horas que não existiam no seu plano de manutenção.
Depreciações de terceiros. Foi isso que pegou o fundador acima. Cloud providers depreciam runtime. Provedores de pagamento mudam assinatura de webhook. Provedores de email apertam DMARC. Mobile-OS sobe target-SDK floor. Nenhum disso é emergência no dia em que o email chega; todos viram emergência seis meses depois, quando ninguém deu seguimento.
Um orçamento de manutenção que não tem uma linha explícita para cada um desses itens não é um orçamento. É um chute.
Cinco perguntas para estimar o seu custo real de manutenção
Antes de assinar qualquer acordo de manutenção, ou antes de decidir quanta capacidade de engenharia interna manter disponível, trabalhe nessas cinco perguntas com honestidade junto com o seu developer ou fornecedor. Levam uma tarde. Vão te salvar do choque do segundo ano.
1. Quantos serviços em produção rodamos e qual a cadência de patch de cada um? Dois serviços com atualização semanal de dependência é uma conta diferente de um monolito com atualização anual. Conte, liste a cadência, e pergunte quem é responsável por cada.
2. Qual a conta mensal combinada de todos os SaaS, infra e APIs terceiros que dependemos, e quais têm tiers gratuitos que vamos estourar nos próximos seis meses? Puxe todo recibo. Liste todo serviço. Marque os que escalam com uso. A lista é sempre mais longa do que o fundador acha.
3. Quem está de on-call, qual o compromisso de tempo de resposta, e quanto custa? Se a resposta é “nosso único developer quando ele ver a mensagem”, você tem a sua resposta. Aí estime quanto custaria deixar isso menos frágil.
4. Qual a cadência de release planejada e o roadmap de feature dos próximos dois trimestres, e quanto disso é trabalho de evoluir em superfícies existentes vs. produto genuinamente novo? Se 60% do roadmap é reescrever onboarding, checkout e admin, o seu bucket de evoluir é grande e tem que ser orçado como tal.
5. Qual o cenário pior dos próximos doze meses e quanto custaria recuperar? O único developer sai. Um cliente grande dispara uma feature que toca tudo. Cloud provider deprecia runtime com 90 dias de aviso. Escolha os dois mais prováveis. Estime o custo da recuperação. Adicione um buffer.
O fundador que consegue responder essas cinco perguntas tem um número real de manutenção. O fundador que não consegue tem um desejo.
Como orçar manutenção desde o ano um: o split 30-50-20
Para cada dólar do orçamento anual de manutenção, aloque 30% para manter-as-luzes-acesas, 50% para pequenos-ajustes e evoluir combinados, e 20% para buffer. O buffer não é folga; é a linha que absorve as depreciações de terceiros, o incidente de segurança e a conta de SaaS surpresa. Fundador que não orça buffer paga por ele do mesmo jeito, só que em pânico.
Em valores, para um produto SaaS ou marketplace típico de pré-A a Série A, isso dá um orçamento de manutenção do ano um na faixa de US$ 30.000 a US$ 90.000, em cima do custo original de build. A faixa reflete dois fatores reais: quanto do produto já está no ar (mais superfície viva, mais custo), e quão estável é o modelo de negócio (mais mudança, mais trabalho de evoluir). Se o seu build foi US$ 80.000 e o modelo ainda muda a cada trimestre, espere ficar no extremo alto. Se o build foi US$ 200.000 e o modelo está estável, você pode ficar no extremo baixo como fração.
Esse é um número de partida para testar contra o diagnóstico acima, não uma resposta final. O diagnóstico é que dá a resposta final.
Como negociar manutenção no contrato de desenvolvimento de software
O momento certo de negociar manutenção é antes de assinar o contrato de build, não depois que o primeiro email de depreciação chegou. A gente escreveu sobre estrutura de contrato em fixed price vs time and materials; a cláusula de manutenção é a parte que a maioria dos fundadores pula na primeira leitura.
Três coisas em que você precisa insistir antes de assinar.
Um escopo de manutenção nomeado, com as três categorias separadas. Não “suporte contínuo”. Manter-as-luzes-acesas como uma linha com janela de resposta definida, pequenos-ajustes como uma segunda linha com pool de horas mensais, evoluir como terceira linha com taxa horária separada. Se o fornecedor não separar, você está comprando um balde e recebendo a categoria que ele quiser servir naquele mês.
Código-fonte no seu nome desde o dia 1, e acesso a todo serviço terceiro nas suas contas, não nas dele. Isso não é negociável. Manutenção é impossível de trocar de fornecedor se o código está no GitHub deles e a conta da AWS está no cartão corporativo deles. Nosso texto sobre software house cobre a postura mais ampla sobre responsabilização de fornecedor.
Cláusula de transição de 30 dias. Se você decidir levar manutenção para dentro de casa ou para outro fornecedor, você tem 30 dias de handover pago com documentação, transferência de credencial e um último sprint de atualização de dependência. Sem essa cláusula, trocar de fornecedor te custa um rewrite forçado.
Para a questão mais ampla de quem é responsável pela supervisão de manutenção quando você não tem um CTO, nosso texto sobre fractional CTO nomeia as quatro alternativas. Para a decisão in-house vs outsourcing especificamente em manutenção, nosso texto sobre time interno vs outsourcing dá o framework de três eixos. Versão curta para manutenção: terceirizar manter-as-luzes-acesas quase sempre é a escolha certa em estágio inicial; trazer pequenos-ajustes para dentro começa a fazer sentido quando há volume para justificar uma pessoa dedicada; evoluir é a última categoria a ser internalizada, porque é nela que o conhecimento do negócio se acumula. O texto completo sobre quanto custa desenvolver um app é o complemento pelo lado do custo de build; ler os dois junto dá o quadro completo dos dois primeiros anos.
FAQ
Quanto custa manter um software?
Para um produto SaaS ou marketplace típico de pré-A a Série A, a manutenção anual cai entre US$ 30.000 e US$ 90.000 nos anos um e dois, em cima do custo original de build. Esse número se quebra em três categorias: manter-as-luzes-acesas, pequenos-ajustes e evoluir. A regra de 15 a 20% do build que aparece na maioria dos sites de agência é emprestada do software enterprise e subestima consistentemente o custo real para startup com escopo em movimento.
Como estimar custo de manutenção de software?
Responda cinco perguntas com honestidade junto com o seu developer ou fornecedor: quantos serviços em produção rodam e qual a cadência de patch; qual a conta mensal combinada de todo SaaS, infra e API terceiros que você depende; quem está de on-call e a que custo; sua cadência de release e o split entre trabalho de evoluir e produto genuinamente novo; e o seu cenário pior dos próximos doze meses. Some as cinco respostas, adicione 20% de buffer. Quem te cota um número de manutenção sem trabalhar essas cinco entradas está te cotando um chute.
Qual o percentual típico de custo de manutenção?
A regra de 15 a 20% vem de software enterprise com escopo estável. Para startup em estágio inicial, a manutenção anual real nos anos um e dois fica tipicamente entre 40% e 80% do custo original de build, caindo para 20% a 30% no ano três se a engenharia foi bem feita. O enquadramento por percentual é menos útil que o por categoria; pergunte o que você está pagando, não que fração do build aquilo equivale.
Por que manutenção de software é cara?
Três razões. O mundo ao redor do seu software não para (cloud provider, processador de pagamento, mobile OS vendor e APIs terceiras forçam mudanças que você tem que absorver). Seus usuários surfaceiam bugs e edge cases que nenhum teste interno encontra. E seu negócio muda mais rápido que o seu código, então o software precisa ser remoldado para caber no negócio. A combinação dos três é o que torna manutenção mais cara do que o fundador espera, e o que torna a regra dos 15% consistentemente baixa.
Um produto vivo não é um produto pronto. O custo de operar um com honestidade é uma linha própria, e os fundadores que planejam isso no mês um são os fundadores cujo email do mês nove é sobre um cliente novo, não sobre uma fatura de US$ 14.000.