Comprar software dá paridade. Só o que constrói o distingue.

A pergunta chega quase sempre da mesa da administração, e vem embrulhada em custo: construir o nosso próprio software ou assinar um SaaS que já existe? Formulada assim, a resposta parece uma folha de cálculo. Não é. É uma pergunta sobre onde vive a sua vantagem. Comprar software resolve o que é comum e entrega-lhe o que o mercado inteiro já tem. Construir à medida é para o núcleo que o distingue. O que é igual não o coloca à frente de ninguém, e é por aí que esta decisão se deve ler antes de se ler pelo preço.

O que está mesmo a ser decidido

O engenheiro Martin Fowler propõe uma divisão simples e útil. Há software utilitário, que toda a gente precisa e que só tem de funcionar, e há software estratégico, aquele em que a forma como faz uma função é parte do que o torna melhor do que a concorrência. A folha de pagamento é o exemplo clássico de utilitário: ninguém ganha clientes por processar salários de maneira mais engenhosa. E é daqui que sai a regra de comprar ou construir.

Since the definition of utility is that there's no differentiator, the obvious thing is to go with the package. [...] For a strategic function you don't want the same software as your competitors because that would cripple your ability to differentiate. Martin Fowler, Utility Vs Strategic Dichotomy, 2019

Não é uma ideia solitária. Geoffrey Moore, em Dealing with Darwin, separa o core, aquilo que cria preferência de compra, do context, tudo o que é preciso fazer para se manter no mercado mas que não distingue, e recomenda minimizar ou externalizar o context para libertar as melhores pessoas para o core. A Gartner arruma o mesmo instinto numa arquitetura de três camadas: sistemas de registo, que duram uma década e só têm de estar certos; sistemas de diferenciação, que codificam o que a empresa faz diferente; e sistemas de inovação, curtos, para testar oportunidades novas. Três linguagens, uma conclusão: compra-se o registo, constrói-se aquilo que diferencia.

Comprar dá-lhe paridade, e às vezes é o que basta

Convém dizer o que o SaaS faz bem, porque faz. Para contabilidade, correio eletrónico, processamento de salários ou um CRM em fase inicial, comprar é a decisão correta e quase sempre a mais barata. Não vale a pena construir aquilo em que a diferença não muda nada para o cliente. Mas há um preço que não está na fatura, e não é o financeiro. Quando o senhor assina a mesma ferramenta que os concorrentes assinam, herda a capacidade e herda também os limites. O sistema foi desenhado para servir mil empresas, não a sua, e a sua acaba por moldar o processo à ferramenta. Em context, isso é aceitável. Em core, é entregar a diferença a um fornecedor que a vende igual ao vizinho do lado.

O preço de tabela não é o custo

O segundo engano é achar que o custo do SaaS é o número da tabela. O gasto mundial em aplicações SaaS deve aproximar-se de 300 mil milhões de dólares em 2025, acima de pouco mais de 250 mil milhões em 2024, segundo a Gartner. Não é o volume do mercado que interessa aqui, é o que ele esconde dentro de cada empresa que soma esse total.

Três custos raramente entram na conta à cabeça. O primeiro é que o preço sobe. O índice da Vertice, uma plataforma que ajuda empresas a negociar compras de software, registou uma subida média dos preços de SaaS na ordem dos 12% num período de doze meses, contra 6% em 2019. É um valor com interesse próprio, e volto a ele já a seguir, mas a direção é conhecida de quem renova contratos: a mensalidade que assinou não é a mensalidade que vai pagar daqui a três anos.

O segundo é que se paga pelo que não se usa. Segundo o índice de gestão de SaaS da Zylo, as empresas usam em média cerca de metade, 49%, das licenças que compram, com um desperdício médio na ordem dos 18 milhões de dólares por ano em licenças paradas. O terceiro é estrutural e é o que menos se vê: o SaaS é uma despesa recorrente que escala com cada posto e com cada integração, e que continua a sair da conta todos os meses enquanto a empresa existir. Construir tem um custo alto à cabeça e depois amortiza. Comprar tem um custo baixo à cabeça e depois compõe, para sempre.

O limite honesto destes números

Aqui é preciso ser rigoroso sobre a força desta prova. A Zylo vende gestão de SaaS e a Vertice vende negociação de software: as duas têm interesse em que o desperdício e a inflação pareçam grandes. A amostra da Zylo são empresas que já contrataram gestão de SaaS, ou seja, quem já tinha excesso a controlar, e pende para grandes organizações, o que puxa a média dos 18 milhões para cima. O desperdício de licenças é uma falha de gestão, não um defeito inerente do modelo, e um aumento de preço anunciado não é o aumento efetivamente pago por quem negoceia. Nada disto prova que comprar é mau. Prova que o custo do SaaS não é o número da tabela, e que quem decide com o número da tabela decide com informação incompleta.

A economia que a inteligência artificial mudou

Há uma razão nova para reabrir esta decisão em 2026, e é do lado de construir. O trabalho de rotina do desenvolvimento, o código repetitivo, os testes, o andaime que se monta antes de começar a parte difícil, ficou mais barato. Num ensaio controlado com 95 programadores, o grupo com acesso ao GitHub Copilot completou uma tarefa 55,8% mais depressa do que o grupo sem a ferramenta.

The treatment group, with access to the AI pair programmer, completed the task 55.8% faster than the control group. Sida Peng, Eirini Kalliamvakou, Peter Cihon e Mert Demirer, The Impact of AI on Developer Productivity, 2023

A tarefa era construir um servidor HTTP em JavaScript, um exercício autónomo e bem definido, exatamente o tipo de trabalho que enche as primeiras semanas de qualquer projeto. Se metade desse trabalho fica mais rápido, o custo fixo de construir o núcleo que o distingue baixa. O que antes só compensava a uma escala grande passa a compensar mais cedo. É esta a mudança concreta: construir à medida deixou de ser um exclusivo de quem tem uma equipa de dezenas de pessoas.

O que isto não prova

Esta é a parte que separa um raciocínio de um argumento de venda, e é a parte que corta contra o entusiasmo fácil. O ganho de 55,8% foi medido numa tarefa isolada, de raiz, feita por profissionais recrutados para o ensaio, num estudo da própria GitHub. O estudo mede a velocidade numa tarefa, não mede a qualidade, a manutenção nem o resultado de um produto. E quando se mede precisamente o outro caso, o de trabalhar dentro de um código grande que já existe, o resultado inverte-se.

When developers are allowed to use AI tools, they take 19% longer to complete issues—a significant slowdown that goes against developer beliefs and expert forecasts. METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, 2025

Neste ensaio de 2025, dezasseis programadores experientes trabalharam em repositórios que conheciam havia anos, em 246 tarefas reais, e permitir a IA fê-los demorar mais 19%. O dado mais desconfortável não é o abrandamento, é a perceção. Os mesmos programadores tinham previsto que a IA os aceleraria 24% e, depois de a experiência os ter atrasado, continuaram convencidos de que os tinha acelerado 20%. A ferramenta faz sentir depressa, e a sensação não coincide com o cronómetro.

E construir carrega risco, mesmo quando fica mais barato. O CHAOS Report de 2020 do Standish Group coloca 31% dos projetos como bem-sucedidos, 50% comprometidos por prazo ou orçamento e 19% falhados. O próprio relatório é criticado por académicos, que apontam que a amostra é proprietária e que as suas definições, assentes só na precisão das estimativas, enviesam os números, e por isso lê-se pela direção e não pelo valor exato: construir de raiz é uma aposta que se orça com margem de erro, não uma poupança garantida. A conclusão honesta não é construir tudo. É que a IA baixou o custo de construir o que interessa, e não a probabilidade de errar quando se constrói o que não interessava.

Onde fica a linha, na prática

Posto isto, a decisão deixa de ser comprar ou construir e passa a ser onde traçar a linha, empresa a empresa. A resposta prática é híbrida, e o teste é uma pergunta só: este sistema codifica aquilo que faz com que o escolham a si? Se a resposta é não, compra-se. A contabilidade, o correio, os salários, o CRM enquanto a empresa é pequena, a videoconferência: é context, e o context compra-se pronto e barato. Se a resposta é sim, constrói-se. O motor operacional que ninguém no mercado faz como o senhor, a lógica de preço ou de logística que é a sua vantagem, o cumprimento de uma regra específica do seu setor que nenhum pacote genérico cobre sem o obrigar a ser igual a todos: é core, e o core não se aluga.

Há um sinal que decide muitas destas linhas. Quando um pacote de prateleira o obriga a mudar o seu processo para caber nele, e esse processo é precisamente o que o distingue, o senhor está a pagar para se tornar igual à concorrência. Em context, moldar-se à ferramenta é sensato e poupa tempo. Em core, é comprar a paridade que devia estar a evitar.

O que fica no balanço

No fim, a diferença entre comprar e construir é a diferença entre uma despesa e um ativo. O software que o senhor compra sai da conta todos os meses e não é seu: é uma capacidade alugada, igual à que o concorrente aluga na porta ao lado. O software que codifica o que o distingue fica, capitaliza-se e trabalha para si depois de pago. Existimos para converter a perceção em ativo financeiro, e a arquitetura tecnológica que sustenta essa perceção obedece à mesma regra. O que é igual não tem autoridade, e o que é igual também não entra no balanço como valor. Entra como custo recorrente.

Fontes

Cada número deste artigo foi verificado na fonte primária. Onde a fonte não sustenta a leitura corrente, dizemo-lo no corpo do texto.

1. Martin Fowler, Utility Vs Strategic Dichotomy, martinfowler.com, 2019. martinfowler.com/bliki/UtilityVsStrategicDichotomy.html
2. Geoffrey A. Moore, Dealing with Darwin (Portfolio, 2005), o modelo core vs context. en.wikipedia.org/wiki/Dealing_with_Darwin
3. Gartner, Pace-Layered Application Strategy (sistemas de registo, diferenciação e inovação). gartner.com/en/documents/3297020
4. Gartner, previsão de gasto mundial em SaaS (~250 mil milhões USD em 2024, ~300 mil milhões em 2025), via CIO Dive, 2024. ciodive.com/news/cloud-spend-growth-forecast-2025-gartner
5. Zylo, 2024 SaaS Management Index (utilização média de 49%; ~18 milhões USD de desperdício médio anual). zylo.com/news/2024-saas-management-index
6. Vertice, SaaS Inflation Index (aumento médio ~12% em doze meses, contra 6% em 2019), via CFO Dive, 2023. cfodive.com/news/saas-prices-jumped-vertice
7. Sida Peng, Eirini Kalliamvakou, Peter Cihon e Mert Demirer, The Impact of AI on Developer Productivity: Evidence from GitHub Copilot, arXiv 2302.06590, 2023. arxiv.org/abs/2302.06590
8. METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, 2025. metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study
9. The Standish Group, CHAOS Report 2020: Beyond Infinity (31% bem-sucedidos, 50% comprometidos, 19% falhados), com a crítica de Eveleens e Verhoef, IEEE Software, 2010. resenha do relatório