Custom Software · Aprofundamento
Sob medida ou plataforma: a grade de decisão build-vs-buy
Quando desenvolver software sob medida e quando comprar uma plataforma: uma grade de decisão baseada no ajuste ao processo, no custo total de propriedade, no lock-in, na propriedade do dado e no time-to-value.
ARQUITETURA · BUILD-VS-BUY
Entra · Capacidades a ativar
Sai · Construir / Comprar / Compor
Core vs commodity (mapa de valor)
Decompõe o sistema em suas capacidades e posiciona cada uma no eixo core/commodity: separa o que diferencia você no mercado — e merece código próprio — do que virou commodity e simplesmente se compra do fornecedor mais barato.
Encaixe no processo
Mede o quanto seu fluxo é proprietário: um processo genérico com padrões de indústria consolidados empurra para a plataforma, enquanto um fluxo que é parte da sua vantagem empurra para o sob medida, porque aqui os contornos que uma plataforma impõe custam mais do que código sob medida.
TCO a 5 anos
Calcula o custo de cinco anos incluindo manutenção, integração e treinamento — não só licença ou orçamento inicial — porque a maior parte do custo do software chega depois do go-live, e é isso que vira o veredito.
Lock-in e direitos de saída
Pesa o custo de saída antes de entrar: contratos, portabilidade do dado e integrações fixadas no código determinam se você terá poder de negociação na renovação ou ficará sem ele, diante de um fornecedor que sabe disso.
Propriedade dos dados
Verifica que o dado que distingue você continue seu, exportável em padrões abertos e independente do fornecedor: um único item não exportável pode virar a decisão, porque um ativo transformado em refém pesa mais do que qualquer economia de preço de tabela.
Time-to-value
Equilibra a urgência do valor com a durabilidade da vantagem: uma solução comprovada já disponível põe você em movimento agora, enquanto um diferenciador estrutural justifica uma implementação mais longa e sustentada.
Os sinais de que sua linha build-vs-buy foi traçada no lugar errado
A pergunta nunca é «sob medida ou plataforma». É: qual capacidade merece código próprio e qual é uma commodity a comprar. Estes sintomas indicam que a linha foi traçada no ponto errado.
- Você está personalizando uma plataforma padrão até ela não se parecer mais consigo mesma: cada versão do fornecedor quebra sua configuração, e o «pronto para uso» virou um projeto de desenvolvimento permanente.
- Você construiu uma commodity do zero — autenticação, pagamentos, notificações — gastando capacidade de engenharia em problemas que o mercado já resolveu, em vez de na sua vantagem competitiva.
- O dado que distingue você vive dentro de um fornecedor em formato proprietário e sem exportação para padrões abertos: já não é um ativo, é um refém.
- Ninguém nunca calculou o número de cinco anos : a decisão foi tomada sobre um preço de licença ou um orçamento de desenvolvimento, ignorando a manutenção, a integração e o treinamento que dominam o ciclo de vida.
- Trocar de fornecedor é impensável : contratos plurianuais, dados não portáveis e integrações fixadas no código elevaram o custo de saída a um nível que tira de você todo o poder de negociação na renovação.
Para CTOs, COOs e direções de operações que precisam decidir onde investir capacidade de engenharia e onde se apoiar no mercado, com critérios que se sustentem diante do conselho.
Compre a commodity, construa o que distingue você
A regra operacional mais sólida não é financeira, é estratégica: posicionar cada capacidade no mapa do valor e decidir pela posição dela, não pelas preferências de quem escreve o código. Uma disciplina formalizada pelo Wardley Mapping.
Core vs commodity, não gosto pessoal
Uma capacidade que diferencia você no mercado e evolui rápido merece código próprio. Uma capacidade que virou commodity — a mesma para você e seus concorrentes — é um centro de custo: compra-se do fornecedor mais barato e segue-se em frente. Construir uma commodity é queimar capacidade de engenharia num problema já resolvido.
O ajuste ao processo é a verdadeira divisão
Se seu fluxo é genérico e a indústria tem padrões consolidados, uma plataforma vence pela velocidade. Se o fluxo é proprietário e parte da sua vantagem, a plataforma impõe contornos que, somados, custam mais do que código sob medida. Uma plataforma dobra você ao modelo dela; o sob medida dobra o software ao seu.
Configurar não é de graça
Entre comprar e construir há uma terceira via — configurar e integrar — mas ela não é neutra. Encaixar uma plataforma complexa num fluxo específico, com migração de dados e treinamento, tem um custo real antes mesmo da primeira transação. A armadilha é a sobrepersonalização: parta da configuração recomendada e itere sobre os dados de uso, não reescreva tudo no primeiro dia.
Compose: o melhor dos dois, com disciplina
A abordagem madura é híbrida: capacidades de mercado para as funções padrão, conectadas por APIs documentadas, e a capacidade de engenharia interna concentrada no que de fato distingue você. É a lógica composable (microsserviços, API-first, cloud-native, headless): componentes substituíveis que mudam sem derrubar tudo o que está conectado a eles.
A decisão deve ser estrutural, não emocional
Mapear as capacidades torna a escolha legível: vê-se onde cada componente está no eixo gênese-commodity, do que depende e para onde empurra a evolução. A linha build-vs-buy deixa de ser uma preferência de departamento e vira uma decisão de arquitetura defensável.
Como traçamos a linha, capacidade por capacidade
Não decidimos «sob medida ou plataforma» para o sistema todo. Decompomos o sistema em capacidades e fazemos cada uma passar pelos mesmos gates. O resultado é um mapa, não uma opinião.
Decompomos o sistema em suas capacidades e posicionamos cada uma no eixo core/commodity: o que diferencia você, o que virou padrão. Isso separa o que vale código próprio do que você simplesmente compra.
Para cada capacidade testamos o quanto seu fluxo é proprietário. 60-70% padrão com exceções administráveis: configurar. Fluxo que é parte da vantagem: construir. Fluxo genérico: comprar.
Calculamos o custo de cinco anos incluindo manutenção, integração e treinamento — não só licença ou orçamento inicial. Em paralelo medimos o custo de saída: portabilidade do dado, direitos de exportação, dependência das integrações.
Cada capacidade recebe um veredito — build, buy ou compose — e seu lugar na arquitetura. As commodities ficam atrás de APIs documentadas; o diferenciador vira código próprio, com o dado sob seu controle.
Do mapa de capacidades a uma grade de decisão defensável em semanas, não em um trimestre de estudos.
Build, Buy ou Compose: os gates de decisão
Cada capacidade passa por cinco alavancas. Não é uma soma de pontos: uma única alavanca pode virar a decisão (um dado proprietário não exportável pesa mais do que qualquer economia de preço de tabela).
| Alavanca de decisão | Empurra para BUY / plataforma | Empurra para BUILD / sob medida |
|---|---|---|
| Posição no mapa | Capacidade commodity, idêntica aos concorrentes | Capacidade core que diferencia você e evolui rápido |
| Ajuste ao processo | Fluxo genérico, padrões de indústria consolidados | Fluxo proprietário; a plataforma impõe contornos caros |
| TCO de 5 anos | Manutenção e risco a cargo do fornecedor | Volume e duração de uso amortizam o custo de desenvolvimento |
| Lock-in e saída | Exportação para padrões abertos, saída por conveniência, integrações por API | O dado crítico deve continuar próprio, independente do fornecedor |
| Time-to-value | Valor necessário já; solução comprovada já disponível | A vantagem justifica uma implementação mais longa e sustentada |
Os quatro ativos que a grade põe a salvo
Uma decisão build-vs-buy bem feita não otimiza só o custo. Protege o que, uma vez perdido, não se compra de volta.
Propriedade do dado
O dado que distingue você continua seu, exportável em formatos padrão e independente do fornecedor. Não um refém num silo proprietário, mas um ativo negociável que dá a você poder na renovação.
Capacidade de engenharia bem gasta
Cada hora de desenvolvimento vai para sua vantagem competitiva, não para uma commodity que o mercado já resolveu. Sob medida onde conta, mercado onde não conta.
Direitos de saída
Portabilidade do dado, integrações por API documentadas e nenhuma amarração proprietária mantêm baixo o custo de troca. A possibilidade de sair é o que mantém você em condições justas.
Arquitetura composable
Capacidades substituíveis conectadas por API: um componente muda sem o resto desabar. O sistema continua vivo ao longo do tempo, não um monólito a refazer.
Construa o que distingue você, compre o que você compartilha com seus concorrentes.
As perguntas que nos fazem antes de decidir
Sob medida é sempre mais caro do que uma plataforma?
Não no ciclo de vida. A maior parte do custo do software chega depois do go-live — manutenção, integração, treinamento. Numa commodity a plataforma vence porque descarrega esse custo no fornecedor. Numa capacidade core com alto volume e longa duração de uso, o sob medida se amortiza enquanto o preço de uma plataforma sobe com o tempo. A resposta está no TCO de cinco anos, não no preço de entrada.
Posso comprar agora e construir depois?
Sim, e muitas vezes é o movimento certo — desde que você não caia na armadilha. Comprar para começar rápido faz sentido se o dado continuar exportável em padrões abertos e as integrações passarem por APIs documentadas. Se o fornecedor retém seu dado em formato proprietário, «depois» vira uma migração cara que você nunca fará. A portabilidade se negocia na assinatura, não no divórcio.
Como evitamos construir algo que o mercado faz melhor?
Mapeando cada capacidade antes de escrever código. Se uma função virou padrão — a mesma para você e seus concorrentes —, construí-la é capacidade de engenharia queimada. O código próprio é reservado ao que diferencia você e evolui; todo o resto se compra ou se compõe por API. Essa disciplina separa um investimento de uma despesa.
Casos
Do problema ao resultado — anônimos.
A plataforma desfigurada
Problema Um varejista havia personalizado uma plataforma de e-commerce padrão até ela não se parecer mais consigo mesma: cada versão do fornecedor quebrava a configuração e o «pronto para uso» tinha virado um projeto de desenvolvimento permanente, com o motor de pricing — seu verdadeiro diferenciador — preso em restrições que não controlavam.
Método Mapeamos as capacidades no eixo core/commodity: catálogo, checkout e pagamentos mantidos na plataforma como commodities atrás de APIs documentadas; o motor de pricing e promoções, parte da vantagem competitiva, extraído como serviço próprio conectado de forma composable.
Resultado As versões do fornecedor pararam de quebrar o sistema, a capacidade de engenharia voltou ao pricing em vez dos contornos, e a lógica que os distingue virou código deles — substituível sem derrubar o resto.
O dado mantido refém
Problema Uma empresa de serviços financeiros mantinha o dado de cliente que a distinguia dentro de um fornecedor, em formato proprietário e sem exportação para padrões abertos: trocar era impensável e na renovação o fornecedor tinha todo o poder de negociação, porque a saída estava de fato bloqueada.
Método Aplicamos os gates de lock-in e propriedade do dado: renegociamos direitos de exportação para formatos padrão no vencimento do contrato, movemos as integrações críticas para APIs documentadas e trouxemos o dado diferenciador de volta ao controle interno, deixando as funções commodity onde estavam.
Resultado O custo de saída caiu a ponto de restaurar o poder de negociação na renovação, o dado voltou a ser um ativo negociável em vez de um refém, e a possibilidade de sair é o que os manteve em condições justas.
A commodity construída do zero
Problema Um operador logístico tinha construído do zero capacidades já commodity — autenticação, notificações, gestão de usuários — queimando capacidade de engenharia em problemas que o mercado já havia resolvido, enquanto o planejamento de rotas, sua verdadeira vantagem, ficava subinvestido.
Método Fizemos cada capacidade passar pelo mapa do valor e pelo TCO de cinco anos: aposentamos o sob medida nas commodities em favor de serviços de mercado atrás de APIs, e concentramos os desenvolvedores na otimização de rotas, onde o volume e a duração de uso amortizam o código sob medida.
Resultado Cada hora de desenvolvimento voltou ao diferenciador, a manutenção das commodities passou aos fornecedores, e a arquitetura virou composable — componentes substituíveis que mudam sem refazer o bloco inteiro.
Aprofunde mais
Arquitetura de produto de IA→
Onde acaba a commodity e começa o código próprio quando o sistema é IA-nativo.
RAG e grounding→
Compre o modelo, construa o grounding sobre o dado que distingue você.
Governança da adoção de IA→
Critérios defensáveis diante do conselho para decidir build, buy ou compose em IA.