Build vs buy em software: quando construir sai mais caro

Build vs buy em software é a decisão entre desenvolver um sistema internamente ou contratar um pronto. A escolha certa raramente sai da comparação de preço de licença contra horas de desenvolvimento. Ela sai de três contas que a planilha costuma ignorar: quanto custa manter, quanto custa depender e quanto custa sair.

Build vs buy é uma decisão de risco, não de preço

A conversa quase sempre começa errada. Alguém traz a cotação anual da ferramenta, alguém estima as horas do time, os dois números vão para a mesma planilha e vence o menor. O problema é que esses dois números não medem a mesma coisa.

O preço da licença é um número conhecido, contratado e razoavelmente estável. A estimativa de horas é uma previsão, e previsão de esforço em software tem um comportamento estatístico específico que vale conhecer antes de confiar nela.

Comprar transfere risco para o fornecedor e cria dependência. Construir retém o controle e assume o risco inteiro, incluindo o risco de a estimativa estar errada por um fator que ninguém colocou no orçamento. As duas escolhas são legítimas. O que não é legítimo é tratar a segunda como se fosse apenas a soma das horas previstas.

O que os dados dizem sobre construir por conta

Dois estudos ajudam a calibrar, e eles dizem coisas diferentes.

O primeiro é o levantamento da McKinsey com o BT Centre for Major Programme Management da Universidade de Oxford, publicado no outono de 2012, com base em mais de 5.400 projetos de TI acima de 15 milhões de dólares. Os projetos estudados ficaram em média 45% acima do orçamento, 7% acima do prazo e entregaram 56% menos valor do que o previsto. Cerca de 17% deles estouraram o orçamento em mais de 200%.

O segundo é mais recente e mais útil para quem decide. Flyvbjerg e colegas analisaram 5.392 projetos de TI concluídos entre 2002 e 2014 e encontraram um detalhe que muda a leitura: a mediana do estouro de custo foi 1,0, ou seja, metade dos projetos terminou dentro ou abaixo do estimado. A média foi 1,8. Média e mediana só divergem tanto assim quando a distribuição tem uma cauda pesada, e era exatamente o caso. O maior estouro observado chegou a 280 vezes o valor estimado.

Esse achado é mais honesto do que a leitura preguiçosa de que projeto de software sempre atrasa. Projeto de software normalmente fica perto do previsto. Ocasionalmente ele destrói o ano. A decisão de construir não é uma aposta em um custo médio, é uma exposição a uma cauda.

Para uma empresa de 50 a 200 funcionários, com time técnico de 2 a 15 pessoas, essa diferença é decisiva. Uma empresa grande absorve um projeto que custou três vezes o previsto. Uma empresa do seu tamanho, não.

As quatro contas que ficam fora da planilha

A comparação honesta precisa das quatro linhas abaixo. Nenhuma delas aparece na cotação do fornecedor nem na estimativa do time.

• Manutenção: O que o sistema consome depois de pronto, para continuar funcionando. Percentual recorrente da equipe, medido em semanas de trabalho por trimestre.
• Oportunidade: O que o time deixou de fazer enquanto construía. Lista do que saiu do roadmap no período.
• Dependência: Quantas pessoas conseguem mexer no que foi construído. Contagem real de quem fez commit na área nos últimos 12 meses.
• Saída: O que custa abandonar a escolha depois. Dados, integrações e endereços públicos que não migram.

A conta de manutenção é a mais subestimada. A norma ISO/IEC/IEEE 14764:2022, que trata dos processos de manutenção de software, separa a manutenção em quatro tipos, e só um deles é conserto de defeito. Os outros três são adaptação a mudanças de ambiente, melhoria de desempenho ou manutenibilidade, e prevenção de falhas futuras. Quando alguém orça "manutenção" pensando apenas em corrigir bug, está orçando um quarto do trabalho.

A conta de oportunidade é a mais fácil de ignorar porque não sai do caixa. Se três pessoas do time passam quatro meses construindo, o custo não é o salário delas, que a empresa pagaria de qualquer forma. O custo é o que elas não entregaram no período, e isso aparece no roadmap, não na planilha financeira. Vale escrever a lista do que sai antes de começar, porque depois de começado ninguém lembra do que foi adiado, lembra apenas de que o projeto demorou.

A conta de dependência é a que vira crise sem aviso. Um sistema interno construído por uma pessoa fica refém dessa pessoa, e o custo não chega no dia em que ela sai, ele já está sendo pago em entrega serializada e revisão que virou formalidade. Vale medir isso antes de decidir construir, usando o método descrito em bus factor e dependência de desenvolvedor chave.

O custo de saída, medido em 33 endereços quebrados

A quarta conta é a que preferimos ilustrar com erro nosso.

Em 22 de setembro de 2026 auditamos o próprio site da Out Limit antes de publicar o guia de due diligence. Encontramos 33 endereços do site anterior respondendo 404. Eram páginas institucionais, páginas de projeto, páginas de categoria e artigos antigos, todos públicos por anos e todos perdidos na troca de plataforma.

O dano não estava distribuído. Um único endereço, de um artigo antigo sobre call to action, concentrava 22 backlinks, quase 40% de todo o perfil de links do domínio. Outro endereço respondia por cerca de 98% do tráfego orgânico que o site ainda recebia. Nenhum dos dois existia mais.

Esse é o custo de saída na prática, e ele tem três características que vale notar. Ele não aparece no dia da decisão, aparece anos depois. Ele não é proporcional ao tamanho do que foi migrado, é proporcional ao que o tempo acumulou em cima daquilo. E ele é quase sempre recuperável apenas em parte, porque redirecionar um artigo que não existe mais para uma página genérica recupera o sinal do link, não a posição do conteúdo.

Corrigimos os 33 endereços com redirecionamento permanente. Recuperamos o sinal dos backlinks. Não recuperamos o conteúdo, porque ele não existe mais.

Se a decisão de plataforma do nosso site tivesse incluído a pergunta "o que acontece com os endereços públicos quando sairmos daqui", o trabalho de 22 de setembro não teria existido. Ninguém faz essa pergunta porque ela parece pessimista na reunião de compra. É a pergunta que mais economiza dinheiro.

O critério de decisão em cinco perguntas

Antes de montar qualquer planilha, responda as cinco abaixo. Elas decidem a maior parte dos casos sem precisar de número.

1. Isso é o que a empresa vende, ou é o que a empresa usa? Se o sistema é parte do que o cliente paga, construir tende a se justificar, porque é ali que a diferença competitiva mora. Se é folha de pagamento, help desk, CRM ou gestão de documento, comprar quase sempre vence, porque o fornecedor amortiza o custo entre milhares de clientes e você não.
2. Existe fornecedor maduro para isso? Mercado com três ou mais opções estabelecidas significa problema resolvido e preço disciplinado pela concorrência. Mercado com fornecedor único é dependência disfarçada de compra, e precisa ser avaliado como risco de continuidade.
3. Quantas pessoas vão conseguir manter o que for construído? Se a resposta é uma, você não está decidindo entre build e buy, está decidindo entre comprar e criar um ponto único de falha.
4. Qual é o custo de sair, em dados, integrações e endereços públicos? Essa pergunta vale tanto para a compra quanto para a construção. Sistema interno mal documentado também aprisiona.
5. O que sai do roadmap durante a construção? Se a resposta é "nada, vamos encaixar", a estimativa já está errada, porque ninguém encaixa seis meses de trabalho sem tirar outra coisa do lugar.

Três respostas desfavoráveis em cinco e a decisão é comprar, independentemente do que a planilha de custo diga.

Com duas respostas desfavoráveis, a decisão ainda está em aberto e vale montar a planilha completa, com as quatro contas da seção anterior. Com uma ou nenhuma, construir merece ser considerado a sério, desde que alguém além de quem vai construir assine a estimativa.

Quando construir é a resposta certa

Construir se justifica em três situações, e vale nomeá-las para que a regra não vire preconceito contra desenvolvimento interno.

A primeira é quando o sistema é o produto, ou parte indissociável dele. Terceirizar ou comprar o núcleo do que você vende transfere para fora a única coisa que te diferencia.

A segunda é quando o processo é realmente específico e já foi validado. Específico de verdade, não específico porque sempre foi feito assim. O teste é simples: se a adaptação ao fornecedor exige mudar o processo e ninguém consegue explicar por que o processo atual existe, o problema é o processo.

A terceira é quando a integração entre ferramentas compradas já custa mais do que o sistema que ela liga. Esse caso aparece tarde, depois de alguns anos acumulando conectores, e costuma ser diagnosticado como "problema de integração" quando é problema de arquitetura. O caminho para avaliar isso está em reduzir custos com TI a partir da arquitetura.

Fora dessas três, a pergunta honesta é por que a empresa quer construir. Em boa parte dos casos a resposta verdadeira é que o time prefere construir, o que é compreensível e não é critério de decisão de negócio.

Existe ainda um quarto caminho, que não é nem build nem buy: contratar quem constrói para você, mantendo a propriedade do código. Isso tem regras próprias, e os critérios de escolha estão em como escolher terceirização de desenvolvimento de software.

O que fazer na segunda-feira de manhã

Pegue a decisão de build vs buy que está em aberto na sua empresa agora e faça três coisas, nesta ordem.

Primeiro, responda as cinco perguntas da seção anterior por escrito, em um documento que outras pessoas possam ler. Escrever muda a resposta com mais frequência do que se imagina, porque obriga a justificar o "é específico nosso".

Segundo, coloque na planilha as quatro contas que ficam de fora, mesmo que com números grosseiros. Uma estimativa ruim de custo de manutenção é melhor do que a ausência da linha, porque a linha ausente é tratada como zero.

Terceiro, para a opção de comprar, pergunte ao fornecedor por escrito como se faz a saída: em que formato os dados são exportados, o que acontece com as integrações e o que acontece com os endereços públicos. A resposta, ou a falta dela, costuma ser mais informativa do que a demonstração do produto.

Essa avaliação é parte do mesmo conjunto de perguntas que um comprador ou investidor faz quando olha a sua empresa, descrito em due diligence técnica, o que avaliam no seu código.

Pré-diagnóstico técnico

Se a decisão está travada entre construir e comprar, e a planilha não está ajudando, o problema costuma ser de critério e não de número. Peça um pré-diagnóstico técnico da Out Limit. Olhamos o sistema que existe, quem consegue mantê-lo e o que custa cada caminho, e devolvemos a recomendação por escrito.