Comprar ou construir virou decisão de design, não só de produto e finanças

Com IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI →, criar uma ferramenta interna ficou tão fácil quanto assinar uma. A diferença real agora está na manutenção, nas emendas entre sistemas e em quem controla os dados, e isso é trabalho de design.

Por anos, a escolha entre comprar uma ferramenta pronta ou construir uma por dentro era assunto de gerente de produto e financeiro. Quem desenhava a experiência chegava depois, herdava o resultado e passava anos lixando as arestas. Um artigo publicado em 21 de outubro de 2026 no UX↳UX33 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025UX, IA e Front-End: quando experiência, inteligência e código se encontram para criar o futuro digitalProduto & UX · jul 2025Novidades em UX/UI para 2025: O futuro do design de experiências digitaisProduto & UX · abr 2025Ver tudo em Produto & UX → Collective, assinado pelo designer Patrick Neeman, argumenta que a inteligência artificial mudou essa conta dos dois lados ao mesmo tempo, e que isso empurra design para dentro da decisão, não para depois dela.

A lógica é simples de enunciar: construir ficou mais barato com agentes de código, comprar ficou mais fácil com a explosão de produtos de IA prontos. Segundo dados da Menlo Ventures citados no texto, 76% dos casos de uso de IA em empresas em 2025 vieram de compra, contra 53% um ano antes. Ao mesmo tempo, uma ferramenta interna funcional pode nascer numa tarde com um agente de código, antes mesmo de o vendedor retornar a ligação.

Em resumo: a pergunta não é mais "o que custa menos", é "onde a complexidade vai parar": no seu código, no roadmap de um fornecedor ou no colo de quem usa o produto todo dia.

Manutenção é o item que falta no orçamento do build

Andrej Karpathy batizou de vibe coding, em 2025, esse estilo solto de programar com IA generativa. Simon Willison fez a ressalva importante: protótipo pode ser solto, mas código que vira produto tem que ser lido como qualquer outro código. A maioria das ferramentas internas que nascem assim acaba virando produto de verdade, com gente dependendo delas, e produto precisa de dono, orçamento e alguém para chamar quando quebra.

Neeman conta que já passou por isso: uma aplicação de workflow interna, construída antes da era da IA, ficou ótima no lançamento e virou pesadelo de manutenção assim que as pessoas passaram a depender dela. Cada novo passo de aprovação exigia mexer em código que poucos entendiam. Daí nasceu a regra dele: reservar 30% do custo inicial de construção, todo ano, só para manutenção.

A conta fica clara num exemplo do próprio artigo: duas pessoas passam duas semanas construindo uma ferramenta, a um custo total de US$ 150 por hora, o que dá US$ 24.000 de investimento inicial mais US$ 7.200 por ano de manutenção. Uma assinatura equivalente, a US$ 20 por assento para 25 pessoas, custa US$ 6.000 por ano.

Só uma das duas colunas vem com equipe de suporte atrás. O relatório de 2026 da Black Duck sobre risco em código aberto↳Open source71 conteúdosComo o Open Source Está Liberando o Poder da Automação para TodosDev (Back & Front) · out 2025Código aberto: programadores criam software da NASA sem saberDev (Back & Front) · abr 2021N8N: O que é a ferramenta open source que está revolucionando a automação em TI?Dev (Back & Front) · dez 2025Ver tudo em Dev (Back & Front) →, citado no artigo, mostra o outro lado do mesmo problema: open source aparece em 98% dos repositórios auditados, e 93% têm componentes sem atividade de desenvolvimento há dois anos. O backdoor encontrado na biblioteca XZ Utils em 2024, resultado de anos de confiança conquistada por um atacante junto ao mantenedor, é o exemplo extremo de código que ninguém pagou para vigiar. O DORA Report de 2025, do Google, por sua vez, encontrou que a adoção de IA ainda prejudica a estabilidade de entrega das equipes.

Comprar importa a estrutura do fornecedor junto

Comprar parece a escolha cautelosa, e com frequência é. Pesquisa do NANDA, iniciativa do MIT citada pela Fortune, encontrou que compras de fornecedores especializados tiveram sucesso em cerca de 67% dos casos, contra um terço disso em construções internas. Há viés de seleção óbvio aqui: empresas tendem a comprar para problemas bem compreendidos e construir para os bagunçados, o que favorece o fornecedor na comparação.

Ainda assim, uma compra nunca é só um conjunto de funcionalidades. Junto vem o modelo de dados do fornecedor, o calendário de lançamentos dele e a teoria dele sobre o que seus usuários estão tentando fazer. Sistemas espelham a estrutura de comunicação das organizações que os projetam, como observou Melvin Conway em 1968: comprar é importar o organograma de outra empresa, ajustado para o cliente mais importante dela, que pode não se parecer em nada com o seu público.

Quem sente a emenda entre ferramentas é o usuário

Ninguém usa "o build" ou "a compra" isoladamente. As pessoas vivem nas emendas entre sistemas, e dá para medir isso como se mede clique em teste de usabilidade: escolha uma tarefa real, acompanhe-a por todos os sistemas e anote cada troca de tela e cada dado redigitado. Um estudo de 2022 com 137 pessoas em 20 times de três empresas da Fortune 500, publicado pela Harvard Business Review, encontrou algo em torno de 1.200 trocas de aplicativo por dia, com um custo de quase quatro horas semanais de reorientação, cerca de 9% do tempo de trabalho.

Ferramentas caseiras pioram essa conta. Nos anos 1990, departamentos inteiros criavam seus próprios bancos de dados↳Banco de dados134 conteúdosSQL ou NoSQL: eis a questão!!Data · mar 2020Banco de dados: como organizar e dar segurança para milhões de dados de loteriasData · mai 20215 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data → em Microsoft Access porque esperar pela área central de tecnologia levava um trimestre; os bancos funcionavam até o autor trocar de emprego, e aí os dados viravam mais um lugar que ninguém mais conseguia acessar. A versão atual disso é o drift: padrões visuais que deixam de bater com o resto do produto e estados de erro que ninguém desenhou.

Toda linha de código gerada é uma linha que alguém vai ter que assumir, e geralmente quem gerou primeiro não quer essa responsabilidade.

Every generated line is a line somebody has to own, and the initial owner usually doesn't want that responsibility.Patrick Neeman, designer e autor do UX Collective

A lei de Larry Tesler ajuda a nomear o fenômeno: a complexidade é conservada, e a única escolha real é quem vai absorvê-la. Construir empurra a complexidade para dentro do seu código; comprar empurra para o roadmap de outra empresa; misturar os dois sem critério empurra para o usuário, um copia e cola de cada vez.

O produto mora dentro do chat de outra empresa

Em muitas organizações, o lugar onde as pessoas encontram seu produto não é mais o seu produto: é o Teams, o Slack, o Claude ou o ChatGPT. A OpenAI trouxe aplicativos para dentro de conversas do ChatGPT em 2025, com o lançamento do Apps SDK. Em janeiro de 2026, a especificação MCP Apps passou a permitir que ferramentas conectadas via Model Context Protocol devolvam interfaces interativas que renderizam direto dentro do Claude e do ChatGPT.

Neeman já viveu essa lógica antes: ele desenhou a documentação para desenvolvedores da plataforma de aplicativos de terceiros do Myspace, lançada em 2008, em que a rede social definia o tamanho da caixa, as permissões e o que um aplicativo podia saber sobre o perfil visitado. As regras de hoje são igualmente específicas e pertencem ao host, não a quem constrói o aplicativo:

• Um cartão inline no ChatGPT tem no máximo duas ações, sem rolagem aninhada, fonte do sistema e logo adicionado pelo próprio host, segundo as diretrizes de interface da OpenAI para o Apps SDK;
• Uma mensagem no Slack suporta até 50 blocos, pelo padrão Block Kit;
• A Microsoft recomenda Adaptive Cards como o tipo de cartão padrão para novo desenvolvimento no Teams.

O host desenha a moldura, e o seu trabalho é decidir o que cabe dentro dela.

The host draws the frame, and your job is deciding what fits inside it.Patrick Neeman, designer e autor do UX Collective

A recomendação prática que sai daí: tratar o cartão como produto próprio, com uma única tarefa, uma ação principal e um caminho de saída claro para a aplicação completa quando a tarefa crescer além do que o host comporta.

Antes de substituir, meça o que já existe

Grande parte dessas decisões não parte do zero: algo já existe, e a pergunta real é se vale substituir. Pesquisa de Michael Norton e coautores, publicada em Harvard, descreve o efeito IKEA: as pessoas valorizam o próprio trabalho amador quase tanto quanto o trabalho de um especialista, o que empurra equipes a preferir manter o que construíram mesmo quando não é a melhor opção.

A síndrome do "não foi inventado aqui" piora o quadro. Um estudo do MIT de 1980, de Ralph Katz e Thomas Allen, acompanhou 50 grupos de pesquisa e desenvolvimento e encontrou que equipes que trabalhavam juntas havia cinco anos ou mais tinham desempenho significativamente pior e conversavam menos com profissionais de fora. Agentes de código baixam o custo de agir nesse reflexo, porque reconstruir uma funcionalidade de um fornecedor agora leva um fim de semana em vez de um ciclo orçamentário inteiro.

E a estimativa também engana. Um ensaio randomizado da METR encontrou que desenvolvedores experientes levaram 19% mais tempo em tarefas reais usando ferramentas de IA, mas estimaram depois que tinham sido 20% mais rápidos. É um estudo pequeno, de 16 desenvolvedores, e a própria METR já o classifica como desatualizado, mas serve de alerta: precifique seu próprio protótipo como precificaria o de um estranho.

Comprar commodity, construir diferencial

O critério mais claro citado no artigo vem de Simon Wardley, que organiza componentes de produto num espectro que vai de genesis a commodity, passando por construção sob medida e produto. Dá para resumir assim: construa onde o seu próprio dado é a vantagem, onde a regulação impede qualquer produto do mercado de servir, e nos momentos em que você de fato compete. Se uma funcionalidade ficaria igual em qualquer produto concorrente, ela provavelmente já é commodity.

Isso pressupõe ter gente capacitada, e a maioria das organizações não tem. Uma pesquisa da IBM com 8.584 profissionais de tecnologia, publicada em janeiro de 2024, encontrou falta de habilidades como a principal barreira à adoção de IA corporativa, citada por 33% dos respondentes, com complexidade de dados em segundo lugar, com 25%. Vibe coding entrega uma demonstração, não as habilidades que uma aplicação de IA em produção exige: busca sobre dados bagunçados, avaliação contínua, permissões e monitoramento.

Quem guarda os dados decide o que a tela consegue mostrar

Um modelo só responde a partir do que consegue enxergar, e a experiência segue para onde os dados estão. Comprar uma ferramenta significa que seus registros ficam no esquema do fornecedor, acessíveis nos termos dele; construir mantém os dados com você, junto com a obrigação de governá-los. A Anthropic, ao apresentar o Model Context Protocol em 2024, descreveu exatamente esse problema: modelos isolados de dados presos atrás de silos e sistemas legados.

A regulação está começando a precificar isso. O Data Act da União Europeia está em vigor desde setembro de 2025, e as tarifas de saída de dados entre provedores terminam por completo em janeiro de 2027. Sair de um fornecedor está ficando mais barato no papel; na prática, uma migração é um projeto de dados com uma conta de UX embutida: campos renomeados, histórico perdido, relatórios que deixam de bater.

Modelos se aposentam, e isso é um redesign não agendado

Seja na compra ou na construção, parte do produto passa a rodar sobre algo que a empresa não controla. A Anthropic promete pelo menos 60 dias de aviso antes de aposentar um modelo lançado publicamente; a página de descontinuações da empresa lista o snapshot do Claude Sonnet 4.5, de setembro de 2025, como descontinuado em 30 de setembro de 2026 e com aposentadoria marcada para 30 de novembro de 2026. Comprar um produto construído sobre um modelo sofre o mesmo efeito, só que uma camada removida e no calendário do fornecedor, que pode nem mencionar a troca de modelo nas notas de versão.

A saída recomendada no artigo é manter um conjunto de tarefas reais de usuário com resultados já conhecidos como corretos, rodar essas tarefas contra cada nova versão de modelo ou fornecedor, e revisar os resultados como se revisa um estudo de usabilidade. Vinte ou trinta tarefas já bastam para começar, desde que cubram os pedidos mais comuns, os erros mais caros e os casos em que a resposta certa é recusar.

O que muda pra quem desenha produto

A decisão de comprar ou construir costumava terminar na assinatura do contrato ou no lançamento. Agora nenhuma das duas opções termina ali, porque as peças continuam se movendo depois. A planilha de produto e financeiro capta o custo de licença e de horas de desenvolvimento, mas deixa de fora o que o usuário sente primeiro: drift em ferramentas sem manutenção, expertise perdida quando um sistema sai de cena, dados presos onde a nova ferramenta não alcança, e cartões de chat cujo layout outra empresa decide.

O teste que o artigo propõe, seguir uma tarefa real por todos os sistemas que ela atravessa, não diz se a resposta é comprar ou construir. Ele diz onde a complexidade vai pousar, para que alguém esteja ali de propósito, e não por acidente. A pergunta que vale levar para a próxima reunião de roadmap não é qual opção custa menos, é: se escolhermos isso, quem vai cuidar da emenda daqui a um ano?

Fonte: UX Collective