Build vs buy: como pensar a decisão de verdade

O problema

Pouca discussão técnica fica tão ruim tão rápido quanto build vs buy.

Porque ela costuma escorregar para um de dois extremos.

Um lado diz:

• “vamos construir, porque ninguém entende nosso problema como a gente”
• “não podemos depender de fornecedor”
• “comprar é gambiarra cara”

O outro responde:

• “vamos comprar e parar de reinventar roda”
• “isso não é core”
• “engenharia quer brincar de produto interno”

Os dois lados podem ter razão em pedaços.

E os dois podem errar feio no contexto real.

Modelo mental

Pense assim:

build vs buy não é sobre preferência. É sobre qual opção resolve o problema certo com o custo total mais aceitável para este momento.

Essa frase ajuda porque ela obriga a olhar além do custo inicial.

Você passa a comparar:

• tempo para capturar valor
• capacidade interna do time
• custo de manutenção
• dependência futura
• flexibilidade real
• risco operacional

Isso já melhora muito a conversa.

Quebrando o problema

A primeira pergunta não é “construir ou comprar?”

É:

“que problema exato estamos tentando resolver e o que precisa ser protegido aqui?”

Sem isso, a discussão vira abstração.

Porque build vs buy para autenticação, analytics, billing, busca ou feature flag são decisões muito diferentes.

O que precisa ser protegido pode ser:

• velocidade de lançamento
• customização profunda
• custo operacional
• conformidade
• confiabilidade
• foco do time

Se isso não está claro, a decisão fica solta.

Comprar parece rápido até o preço escondido aparecer

Muita compra parece boa porque resolve uma ansiedade imediata.

E às vezes resolve mesmo.

Mas comprar também cobra coisas que aparecem depois:

• integração chata
• limitação de customização
• pricing que cresce com uso
• lock-in
• mudança de roadmap fora do seu controle
• necessidade de contornar o produto comprado

Quando você ignora isso, a conta fica curta demais.

Construir parece controlar tudo até a manutenção chegar

O outro lado também sofre do mesmo problema.

Construir internamente parece atraente porque dá sensação de controle.

Mas esse controle custa:

• tempo do time
• desvio de foco
• operação contínua
• evolução de requisito
• suporte interno
• dívida que vira produto escondido

Às vezes o “vamos construir” na prática significa:

“vamos assumir um produto a mais sem admitir isso claramente.”

Essa é uma boa pergunta para levar para a conversa.

Core business ajuda, mas não resolve sozinho

Muita gente usa essa frase como atalho:

“isso não é core, então compra”

ou

“isso é core, então constrói”

Só que isso sozinho ainda é pouco.

Porque mesmo algo não-core pode exigir:

• customização crítica
• risco regulatório alto
• diferenciação importante na experiência

E algo core pode não merecer ser construído do zero naquele estágio.

Melhor do que perguntar “é core?” é perguntar:

• quanto essa capacidade precisa ser nossa de verdade?
• quanto controle ela exige?
• quanto custo faz sentido bancar agora?

O estágio da empresa muda muito a resposta

Esse ponto é decisivo.

Uma startup pequena pode comprar porque precisa aprender rápido.

Uma empresa maior pode construir porque o custo marginal de fornecedor ficou absurdo.

Um time sem maturidade operacional pode comprar para evitar criar outro sistema crítico.

Um time com necessidade forte de customização pode construir porque o fornecedor vira limite.

A mesma decisão muda bastante com o estágio.

Melhor resposta quase sempre reconhece modelo híbrido

Em muitos casos, a decisão mais madura não é 100% build nem 100% buy.

Pode ser:

• comprar agora e substituir depois
• comprar a base e construir a camada diferenciadora
• construir só a parte que realmente exige controle
• evitar produto próprio completo e fazer integração mais fina

Essa visão costuma soar mais pé no chão.

Porque times bons raramente tratam a escolha como dogma absoluto.

Exemplo simples

Imagine a decisão sobre cobrar recorrência em um produto SaaS.

Resposta fraca:

“Eu compraria, porque billing não é core.”

Ou:

“Eu construiria, porque depender de terceiro é perigoso.”

As duas respostas são rasas.

Resposta melhor:

“Minha primeira pergunta seria o que está em jogo neste momento. Se a prioridade é entrar rápido no mercado e o time ainda não tem capacidade para operar billing com segurança, comprar tende a fazer mais sentido no curto prazo. Mas eu não trataria isso como decisão trivial. Olharia limitação de customização, fee por volume, necessidade de conciliação, requisitos fiscais e quanto disso pode virar gargalo mais à frente. Se a diferenciação do produto depende muito da lógica de cobrança, talvez comprar a base e manter a camada de regra de negócio mais perto da gente seja melhor do que comprar tudo ou construir tudo.”

Essa resposta mostra:

• objetivo do momento
• custo escondido
• risco operacional
• possibilidade híbrida

Erros comuns

• Tratar build vs buy como questão de orgulho técnico.
• Olhar só custo de entrada e ignorar custo contínuo.
• Comprar sem considerar lock-in e limite de customização.
• Construir sem assumir que isso vira um produto interno.
• Responder com regra universal em vez de contexto.

Como um senior pensa

Quem amadureceu costuma pensar assim:

“Se a gente construir, o que exatamente passa a ser responsabilidade nossa por anos? Se a gente comprar, o que exatamente passa a sair do nosso controle?”

Essa pergunta é muito boa.

Porque ela força a conversa a sair do entusiasmo inicial e entrar em responsabilidade real.

É aí que a decisão começa a ficar honesta.

O que o entrevistador quer ver

Ele quer perceber se você:

• compara custo total, não só custo imediato
• pensa em velocidade e manutenção ao mesmo tempo
• entende risco de fornecedor e risco de produto interno
• considera estágio da empresa e capacidade do time
• evita resposta dogmática

Uma resposta forte pode soar assim:

“Quando eu penso em build vs buy, eu tento não tratar a decisão como opinião de engenharia nem como planilha pura. Primeiro eu deixo claro o que precisamos proteger agora. Depois comparo tempo para valor, custo de manutenção, flexibilidade, dependência e risco operacional. Para mim, a pergunta não é qual opção parece mais elegante. É qual opção produz o tipo certo de responsabilidade para o momento da empresa.”

Build vs buy mal pensado troca um problema visível por outro que só aparece depois.

Quando você compara responsabilidade futura, não só velocidade inicial, a decisão começa a ficar madura.