Build vs. buy: quando desenvolver software próprio faz sentido

A decisão entre construir e comprar software costuma ser apresentada como comparação de custo. De um lado, a mensalidade de uma licença. Do outro, a estimativa de um projeto de desenvolvimento.

Colocados lado a lado, os números parecem comparáveis. Não são.

A licença é um custo conhecido e recorrente. O projeto é um investimento inicial seguido de manutenção indefinida. E nenhum dos dois inclui o item que mais pesa na conta real: o custo de operar um processo que não corresponde à forma como a empresa efetivamente trabalha.

Esse custo não aparece em proposta comercial. Aparece no retrabalho, na planilha paralela, na exportação manual que virou rotina e no conhecimento crítico que ficou fora do sistema, na cabeça de quem executa.

Build vs. buy não é uma decisão de custo. É uma decisão de arquitetura — e como toda decisão de arquitetura, fica exponencialmente mais cara de reverter conforme o tempo passa.

O eixo que realmente importa

A pergunta útil não é o que custa menos hoje. É onde está o diferencial competitivo desta operação.

Um processo pode ser classificado em dois grupos:

• Processo commodity. Funciona essencialmente igual em qualquer empresa do setor. Folha de pagamento, contabilidade fiscal, controle de ponto, assinatura de documento. Nenhum cliente escolhe um fornecedor porque a conciliação bancária dele é melhor.
• Processo diferencial. É a forma específica como aquela empresa entrega valor. O modelo de precificação que ninguém copiou, a lógica de roteirização que reduz custo operacional, a regra de crédito construída sobre dez anos de histórico próprio.

Para processo commodity, o mercado já resolveu melhor do que você resolveria. Um produto maduro concentra anos de evolução, conformidade regulatória e casos de borda que nenhum projeto interno vai cobrir no primeiro ano. Comprar é a decisão correta, e insistir em construir é desperdício de capacidade de engenharia.

Para processo diferencial, a lógica se inverte. Adotar uma ferramenta genérica significa adaptar a operação ao que o produto suporta. Na prática, é aposentar o diferencial em troca de conveniência — e descobrir isso tarde, quando o processo já foi nivelado ao do concorrente.

Os custos que ninguém coloca na planilha

Ao comprar

• Adaptação de processo. O produto define o fluxo. A operação se ajusta. O que não cabe vira exceção, e exceção vira planilha.
• Integração. Produto de prateleira integra bem com o que o fornecedor previu. O restante do seu ecossistema — ERP customizado, legado sem interface, sistema de parceiro — vira projeto à parte, frequentemente maior que a implantação.
• Roadmap de terceiro. A funcionalidade crítica para você entra na fila de prioridade de outra empresa. Você pode pedir. Não pode decidir.
• Custo de saída. Dado dentro do fornecedor, processo moldado à ferramenta, time treinado naquele fluxo. Trocar depois de três anos raramente é uma migração — é um novo projeto.

Ao construir

• Manutenção perpétua. Software não é entregue, é sustentado. Dependência atualiza, requisito muda, integração quebra. O custo de manter não é resíduo do projeto; é o projeto em regime permanente.
• Dependência de conhecimento. Se uma pessoa entende a parte crítica, o sistema tem um ponto único de falha que não está em diagrama nenhum.
• Custo de oportunidade. Cada mês de engenharia em algo que o mercado já resolve é um mês que não foi para o diferencial.
• Decisão estrutural não revisada. A arquitetura definida no início raramente é reexaminada. Dois anos depois ela ainda está lá, agora determinando o que é possível fazer.

A terceira opção, que quase ninguém coloca na mesa

A maior parte das decisões de build vs. buy é apresentada como binária. Na prática, a resposta mais madura costuma ser composta:

Compre o núcleo. Construa a borda.

Adote a plataforma consolidada para o que é commodity — o ERP, o CRM, o gateway, o sistema fiscal. Construa, por cima e via integração, apenas a camada fina onde mora o diferencial.

Isso exige uma condição inegociável: a plataforma escolhida precisa ter API e modelo de extensão reais. Não "possui API" na tabela comparativa, mas API documentada, versionada, com limites compatíveis com o seu volume e acesso às entidades que importam.

É por isso que a avaliação de um produto de prateleira deveria incluir uma análise técnica de extensibilidade, e não apenas comparação de funcionalidade. Um produto com 90% das funções e sem extensibilidade costuma sair mais caro que um com 70% e uma boa API.

A quarta opção, mais rara e ainda menos considerada: não construir nada. Parte relevante do que chega como demanda de software é problema de processo, de definição de responsabilidade ou de dado que ninguém mantém. Automatizar um processo quebrado entrega o mesmo problema, mais rápido.

Um critério de decisão

Nenhum framework substitui contexto. Mas decisão sem critério explícito é decisão por hábito — e o hábito, em tecnologia, costuma ser construir o que seria melhor comprar e comprar o que seria melhor construir.

Seis perguntas, na ordem:

1. Este processo é diferencial ou commodity?

   Se um concorrente copiasse exatamente este processo, você perderia vantagem? Se não, é commodity.

2. Quanto custa adaptar a operação à ferramenta?

   Não em licença. Em etapas manuais, exceções e perda de rastreabilidade.

3. Qual a densidade de integração exigida?

   Quantos sistemas precisam operar de forma coerente com este? Quanto mais denso o acoplamento com um ecossistema específico, maior o peso do lado construir — ou da camada de integração própria.

4. Com que frequência a regra muda?

   Regra estável favorece produto maduro. Regra que muda a cada trimestre depende de você conseguir alterá-la sem depender do roadmap de terceiro.

5. Quem mantém isso daqui a três anos?

   Se não houver resposta concreta — time, orçamento, responsável nomeado — construir é decisão incompleta.

6. O que acontece se precisarmos trocar?

   Custo de saída dos dois caminhos. É a pergunta que mais muda decisão e a que menos se faz.

Se as respostas apontarem para commodity, integração simples, regra estável e ausência de time de manutenção: compre, e não olhe para trás.

Se apontarem para diferencial, integração densa e regra em evolução: construa — com arquitetura definida antes da primeira linha de código.

Se ficarem divididas, o que é o caso mais comum: componha. Núcleo comprado, borda construída.

A decisão tem prazo de validade

Build vs. buy não é decisão permanente. É decisão correta para um contexto que muda.

Um processo diferencial hoje pode virar commodity quando o mercado alcançar — e nesse momento manter sistema próprio passa a ser custo sem retorno. O inverso também ocorre: um processo tratado como commodity pode se tornar o eixo da estratégia, e a ferramenta genérica vira o teto.

Uma decisão dessas merece revisão explícita, com data marcada, e não revisão por crise. O gatilho útil não é o calendário — é a mudança de contexto: novo mercado, mudança regulatória, salto de volume, aquisição.

Isso só é possível se a decisão original tiver sido registrada com o critério que a sustentou. Sem esse registro, a revisão vira arqueologia: ninguém lembra por que foi decidido assim, e a discussão recomeça do zero com os mesmos argumentos.

O que fica

Build vs. buy raramente é resolvido por comparação de preço, porque os preços comparados não medem a mesma coisa.

Resolve-se identificando onde está o diferencial da operação, medindo o custo real de adaptar processo à ferramenta, avaliando a densidade de integração exigida e respondendo com honestidade quem sustenta a escolha ao longo do tempo.

A maior parte dos projetos que dão errado não errou na escolha entre construir e comprar. Errou em decidir sem critério explícito — e em nunca revisitar a decisão depois que o contexto mudou.

A RYLVEN atua em consultoria de arquitetura de software e em desenvolvimento de software sob medida, da decisão estrutural à operação.