Uma pergunta que não cabe mais
Em todo livro de TI, Make-or-Buy aparece como uma das decisões estratégicas centrais. A empresa deve desenvolver uma solução internamente ou comprar de um fornecedor? Classicamente, a resposta dependia de três fatores: competência central, custo, time-to-market. Sem equipe interna de software? Compre. Quer diferenciação? Construa. Não consegue decidir com clareza? Compre, por segurança.
Essa lógica está ruindo. Não porque um lado vence, mas porque a própria pergunta está desatualizada. A resposta honesta para "Make or Buy?" hoje é cada vez mais: "Os dois – em pontos diferentes da pilha."
Como o stack realmente se parece
Olhe a arquitetura de uma empresa moderna. Ela compra Salesforce como plataforma de CRM – mas constrói suas próprias Lightning apps, fluxos e enriquecimento de dados com IA por cima. Compra Snowflake como data warehouse – mas constrói seus próprios pipelines, modelos e camadas semânticas. Compra Microsoft 365 – mas constrói extensões próprias de Copilot com acesso a bases de conhecimento internas. Compra Stripe – mas constrói seus próprios fluxos de checkout, lógica de assinatura e relatórios.
Em cada um desses casos, a plataforma é comprada e o valor está no build. A plataforma entrega o que qualquer um pode ter: infraestrutura, conformidade regulatória, escalabilidade, operação. A camada própria entrega o que diferencia: processos, dados, workflows, experiência.
Isso é "Build the Buy" – não comprar em vez de construir, mas construir em cima do que se compra. É a arquitetura para a qual as empresas vêm migrando há anos sem nome para isso. Com IA, vira o padrão dominante.
Por que a pergunta antiga estava errada
A lógica clássica de Make-or-Buy assumia que uma solução era comprada inteira ou construída inteira. Essa suposição nunca foi totalmente verdadeira – mesmo implementações SAP sempre incluíram customização substancial – mas era uma simplificação útil.
Hoje é uma leitura errada. Plataformas modernas são APIs e pontos de extensão, não soluções fechadas. Salesforce sem customização própria é um CRM genérico. Com camada própria por cima, vira um processo de negócio específico. Snowflake sem modelos próprios é um banco de dados caro. Com modelos próprios, vira vantagem analítica.
Perguntar "Make or Buy?" hoje é perguntar sobre um modelo que não reflete mais a realidade. A pergunta melhor: "O que compramos – e o que construímos por cima?"
O que isso muda economicamente
Três consequências que estão chegando devagar às discussões de orçamento:
Custos de licença da plataforma são metade da conta. Uma empresa que licencia Salesforce por R$ 3 milhões ao ano gasta tipicamente outros R$ 3 a 6 milhões em customização, integração e desenvolvimento próprio. Isso era argumento contra plataformas. Hoje é simplesmente um TCO realista – e a parte do build produz a maior parcela do valor.
Lock-in muda de lugar, mas não desaparece. Construir em cima de Salesforce te amarra ao Salesforce – não só pelo custo de licença, mas pela camada própria que seria inútil sem a plataforma. Isso torna a escolha de plataforma mais estratégica do que antes. Não é mais uma decisão de ferramenta, é uma aposta em um parceiro de ecossistema para a próxima década.
Capacidade interna fica mais cara e mais importante. Construir em cima de uma plataforma exige pessoas que entendam profundamente a plataforma – mais pessoas que dominem desenvolvimento em geral. Esse mix de competências é escasso e caro no mercado. Faz a diferença entre uma plataforma que entrega seu valor e uma que fica só como licença.
Onde "Build the Buy" vence
A força do modelo está na divisão de trabalho. O que a plataforma entrega, ninguém precisa construir. O que o build entrega, ninguém pode comprar.
Concretamente: autenticação, permissões, escala, logs de auditoria, atualizações regulatórias, operação, backups – tudo coisa trabalhosa, importante e não-diferenciadora. Cada centavo gasto na plataforma se paga aqui, porque a alternativa seria ocupar metade de uma equipe de desenvolvimento com coisas que nenhum cliente jamais nota.
Do outro lado: lógica de avaliação de propostas, otimização de rotas, lead scoring, modelos de precificação, negociação automatizada de contrato, avaliação individual de risco – tópicos específicos da empresa onde cada pequena melhoria é mensurável no core. Aqui o build é a alavanca, porque funcionalidades genéricas de plataforma nivelam a competição.
Onde o modelo quebra
"Build the Buy" não funciona em todo lugar. Três configurações em que falha:
Plataformas sem extensibilidade séria. Alguns fornecedores SaaS dizem ser plataforma mas entregam só uma aplicação fechada com poucos webhooks. Construir em cima é construir em areia. Toda decisão "Build the Buy" precisa de uma avaliação honesta da maturidade de API antes.
Plataformas com precificação hostil. Alguns fornecedores cobram por API-call ou por custom-object de forma tão agressiva que qualquer build próprio vira armadilha de custo. Aqui o valor migra do cliente para o fornecedor no momento em que o desenvolvimento próprio dá certo. É economicamente fatal e deveria ser critério claro de exclusão.
Builds próprios que só tapam buracos de plataforma. Quando a equipe própria passa meses construindo o que a plataforma deveria entregar – relatórios, workflows padrão, integrações simples – a escolha de plataforma está errada. Build próprio deve produzir diferenciação, não tapar lacunas.
A pergunta certa em quatro passos
Em vez de tratar Make-or-Buy como decisão sim/não, vale uma análise por camadas:
Qual camada não diferencia? Compre. Padrão da plataforma basta.
Qual camada diferencia mas é resolvível genericamente? Plataforma mais configuração. Sem código próprio, mas com design deliberado.
Qual camada diferencia e é específica da empresa? Build em cima da plataforma. Esta é a camada que produz vantagem competitiva.
Qual camada é tão crítica que risco de plataforma é inaceitável? Build sem plataforma. Raro, mas existe – por exemplo, no núcleo de um produto algoritmicamente diferenciado.
Essas quatro perguntas substituem o antigo Make-or-Buy. São mais exigentes porque pedem uma visão em camadas do próprio stack. Mas estão mais próximas da realidade de como software moderno realmente é construído.
Na nh labs, frequentemente vemos clientes chegando com lógica clássica de Make-or-Buy e terminando com arquitetura "Build the Buy" – simplesmente porque, no detalhe, essa se mostra a solução mais viável econômica e estrategicamente.
Conclusão
A pergunta Make-or-Buy perdeu sua força porque sua premissa não vale mais. Software moderno nasce híbrido: plataformas compradas para o que todos precisam, camadas próprias para o que diferencia. Quem ainda pensa nas categorias antigas otimiza o problema errado. Quem aceita "Build the Buy" como arquitetura consegue desenhar um stack em que plataforma e build juntos produzem mais valor do que cada parte sozinha. Não é o compromisso entre Make e Buy – é o próximo estágio.