A IA não está matando o SaaS e sim desmontando o bundle

Um dado recente da McKinsey me chamou atenção: 32% das organizações pesquisadas disseram ter deixado de comprar pelo menos um produto ou funcionalidade de software porque poderiam construí-lo internamente usando ferramentas de agentic coding.

Entre empresas classificadas como high performers em IA, a proporção se aproxima da metade.

Mas esse número exige cuidado.

Não significa que um terço das empresas esteja abandonando SaaS. Basta ter deixado de comprar um produto ou funcionalidade uma vez. Uma empresa que construiu um único dashboard de relatórios em vez de pagar por uma licença adicional entra no mesmo balde de uma que substituiu toda a plataforma de atendimento ao cliente.

O que o dado mede, portanto, não é quanto as empresas estão construindo. É quantas delas começaram a pronunciar uma frase específica nas reuniões de procurement: a gente poderia construir isso.

Quando essa frase entra na conversa, build versus buy deixa de ser a questão que importa.

Por que o bundle existiu durante tanto tempo?

Durante décadas, compramos software em grandes pacotes. Precisávamos de algumas funcionalidades, mas adquiríamos plataformas com dezenas ou centenas delas. O motivo era simples: desenvolver, integrar, testar e manter software internamente era caro. O que o fornecedor vendia de verdade era a montagem — o trabalho de integração, os engenheiros que você não precisaria contratar, os meses que você não poderia poupar.

A IA começa a alterar essa equação.

Se uma equipe consegue construir determinadas funcionalidades em dias ou semanas, surge a pergunta inevitável: por que pagar por todo o pacote se precisamos apenas de uma parte? As outras noventa funcionalidades do bundle param de parecer valor e começam a parecer overhead.

Talvez a ameaça para determinados modelos de SaaS não seja empresas construindo seus próprios ERPs ou CRMs. Pode ser algo mais gradual — o desmembramento econômico do bundle. A organização continua comprando aquilo que é difícil, arriscado ou economicamente irracional reproduzir, mas começa a questionar funcionalidades periféricas que antes faziam parte obrigatória do pacote.

Build versus Buy virou uma estimativa de engenharia

Siga a lógica um passo adiante e algo se move no organograma.

Se a pergunta deixou de ser qual fornecedor e passou a ser se uma capacidade específica é mais barata para reconstruir do que licenciar, a pessoa que responde a essa pergunta não pode ser um generalista de procurement trabalhando com um quadrante de analista. Precisa ser alguém capaz de olhar para uma funcionalidade e colocar um número credível no que construir e operar aquilo realmente custaria.

E esse número precisa incluir as partes que nenhuma demonstração mostra: o trabalho de segurança, a manutenção contínua, o suporte, o conhecimento acumulado, a responsabilidade pelo código. Build versus buy tornou-se uma estimativa técnica feita antes de virar linha de orçamento.

A IA reduz o custo de construir, mas não necessariamente o de possuir

Aqui está o ponto que mais me importa nessa discussão.

Um agente pode gerar em horas algo que anteriormente levaria semanas. Mas alguém continuará responsável por entender, testar, proteger, operar e manter aquilo durante anos.

A IA reduz o custo de construir software. Não elimina o custo de possuir software.

Por isso, a nova equação não é apenas build or buy e sim "o que realmente vale a pena possuir?".

Funcionalidades facilmente reproduzíveis podem perder diferenciação. Dados proprietários, integrações complexas, confiabilidade, compliance, segurança, conhecimento de domínio e responsabilidade operacional são muito mais difíceis de reproduzir apenas gerando código.

O que ninguém vai querer possuir

Os fornecedores em apuros são aqueles cujo produto era essencialmente a inconveniência de fazer você mesmo. Middleware. Conectores. Ferramentas que convertem um formato em outro. O moat deles era o incômodo e o incômodo está evaporando.

Os fornecedores que se sustentam vendem o que um agente não consegue reproduzir facilmente: dados proprietários que você não tem como coletar por conta própria, compliance em setores regulados onde errar é um evento legal, e transferência direta de responsabilidade — um contrato que move o risco do seu balanço para alguém cujo trabalho inteiro é carregar esse risco.

O verdadeiro moat vai ser não apenas o que o software faz, mas o que o cliente não consegue, não quer ou não deveria assumir sozinho.

O que muda no mercado

Para CIOs, isso exige uma disciplina mais sofisticada sobre o que comprar, construir e assumir como responsabilidade permanente. Não basta perguntar se é mais barato construir. É preciso perguntar se a organização tem capacidade e disposição de possuir aquilo pelos próximos anos.

Para os fornecedores de software, se construir funcionalidades ficar progressivamente mais barato, uma longa lista de features poderá deixar de ser vantagem competitiva. O valor vai se concentrar cada vez mais no que é difícil de reproduzir, no que é arriscado de possuir e no que exige responsabilidade que as empresas preferem terceirizar.

A pergunta que vale levar para o próximo ciclo de avaliação de portfólio não é o que comprar ou construir. É “de tudo que pagamos hoje, o que realmente vale a pena possuir?”.