Uma equipe de seis engenheiros seniores, custo médio R$ 20.000 mensais cada, passou quatro meses construindo um sistema interno de notificações que fazia aproximadamente o que o Amazon SNS faz por centavos a cada mil mensagens. O custo total, só em salários, chegou a R$ 480.000, sem contar as features não entregues naquele trimestre. Na retrospectiva, a justificativa mais frequente foi que a equipe queria controle total sobre o sistema. Controle total sobre um problema que não era diferencial competitivo.
Pra mim, esse padrão se repete o suficiente pra ser reconhecível. Times técnicos subestimam o custo de construir e superestimam o de integrar. Na minha análise, a decisão entre construir, comprar ou adaptar software raramente é tomada com base em dados, e quase sempre se baseia em preferência, familiaridade ou viés de competência. O Standish Group classifica entre 64 e 69% dos projetos como challenged ou failed, e parte significativa desses fracassos tem origem direta numa decisão errada de build vs. buy.
O framework que aplico opera sobre três eixos: custo total de propriedade num horizonte de três a cinco anos, proximidade com o diferencial competitivo e capacidade técnica de manter a solução em produção.
O primeiro eixo é o mais subestimado. A literatura converge há décadas em que a manutenção responde por 60 a 80% do custo total do ciclo de vida. Quando uma equipe estima o custo de construir, o número apresentado reflete só o desenvolvimento inicial, que representa entre 20 e 40% do custo real. O resto aparece ao longo dos anos em correções, adaptações de infraestrutura e onboarding de gente nova num sistema que só existe dentro da empresa.
Pra comprar, não basta a licença, é preciso somar integração, treinamento, adaptação de processos internos e dependência de roadmap do fornecedor. Na minha experiência com aquisições enterprise, o preço de licença raramente passa de 33 a 40% do custo total, até porque integração e adaptação adicionam entre 150 e 200% sobre esse valor ao longo de cinco anos.
A terceira opção, que chamo de borrow, é adaptar software open source ao contexto interno. Costuma ser tratada como custo zero, o que é simplificação perigosa. Empresas de médio porte gastam entre 40 e 90 mil dólares por ano só em customização e integração. Vira armadilha quando a equipe começa a manter um fork que diverge do upstream a cada release.
O segundo eixo, proximidade com o diferencial competitivo, é o critério que na minha avaliação deveria preceder qualquer análise de custo. O problema que o software resolve faz parte do que torna o produto diferente dos concorrentes, ou é infraestrutura que todo concorrente também precisa resolver da mesma forma. Um sistema de autenticação numa empresa de e-commerce ou um pipeline de CI/CD numa fintech são infraestrutura genérica. Um algoritmo de recomendação personalizada ou um motor de análise de risco de crédito são domínios onde a implementação interna pode gerar diferenciação.
A regra que aplico há anos é simples: software de problema genérico deve ser comprado ou emprestado, e software de problema específico do domínio deve ser construído. A tendência natural de engenheiros é classificar problemas como específicos quando na verdade são genéricos, até porque construir é mais interessante do que integrar. O antídoto pra esse viés é perguntar se o concorrente mais próximo resolve o mesmo problema de forma diferente. Se não, é genérico.
O sistema de notificações do exemplo inicial era infraestrutura genérica. Quatro meses de engenharia sênior pra produzir algo que não diferenciava o produto. O custo de oportunidade, medido em features que teriam impacto direto em revenue, é o mais relevante pra decisão e o mais difícil de calcular.
O terceiro eixo, capacidade de manutenção, é o que transforma decisões corretas no momento da implementação em decisões incorretas ao longo do tempo. Um sistema construído por oito engenheiros vira um sistema mantido por três quando a empresa reestrutura times. O indicador mais confiável que observo é o ratio entre engenheiros dedicados e sistemas sob responsabilidade. Quando cai abaixo de um por sistema, o tempo de resposta a incidentes sobe junto com a taxa de mudanças com falha, padrão consistente com o que as métricas DORA medem em equipes num estado de sobrecarga. A decisão de construir precisa incluir não só se a equipe atual consegue implementar, mas se a equipe futura, possivelmente menor, consegue manter.
Na minha experiência, entre 70 e 80% dos problemas que uma empresa precisa resolver são genéricos o suficiente pra que a resposta correta seja buy ou borrow, e os 20 a 30% restantes ou justificam build ou ficam em zona ambígua.
O efeito de segunda ordem mais relevante de uma decisão errada de build está no custo de reversão. Com o sistema em produção e processos organizacionais dependentes dele, o custo de migrar cresce de forma desproporcional ao tempo de operação. O que seria uma migração de duas semanas no mês um vira três meses no ano dois. Na minha avaliação, o lock-in num sistema interno mal projetado é pior do que num fornecedor externo, até porque o fornecedor tem APIs documentadas e incentivos comerciais pra facilitar migração.
Cada hora de engenharia gasta num problema genérico é uma hora não gasta num problema que diferencia o produto. Uma decisão de build correta com oito engenheiros e um produto pode ser incorreta com quarenta engenheiros e cinco produtos. Daí a disciplina de revisitar o framework periodicamente.