A decisão entre assinar uma solução de prateleira e desenvolver o próprio software nunca foi tão barata de errar — nem tão estratégica de acertar. Com a inteligência artificial derrubando o custo de programar, a velha pergunta “construir ou comprar” voltou ao centro da mesa, agora com novas variáveis. Este é um guia com dados, custos reais e os sinais que separam uma boa aposta de um erro de milhões.
A empresa que desligou o Salesforce
No fim de 2024, uma frase do CEO da fintech sueca Klarna sacudiu a indústria de software. Em uma teleconferência com investidores, Sebastian Siemiatkowski anunciou que havia “desligado o Salesforce” e que faria o mesmo, em poucas semanas, com o Workday — dois dos maiores fornecedores de software corporativo do planeta. A justificativa: uma combinação de inteligência artificial, padronização e simplificação que permitiria à empresa consolidar e abandonar “vários fornecedores de SaaS”.
A reação foi imediata. Marc Benioff, fundador e CEO do Salesforce, foi a público questionar como, exatamente, uma empresa em um setor altamente regulado gerenciaria seus dados de clientes, sua governança e seu compliance sem as plataformas que havia descartado. Onde estavam os dados? Qual era, afinal, a “grande coisa nova” que substituiria décadas de desenvolvimento acumulado?
A resposta, quando veio, foi mais sóbria do que a manchete sugeria — e é exatamente aí que mora a lição. Meses depois, Siemiatkowski esclareceu no X que a Klarna não havia trocado SaaS por um modelo de linguagem. A empresa construiu um stack interno próprio, usando o banco de dados de grafos Neo4j para unificar o conhecimento espalhado por dezenas de sistemas, e empregou a ferramenta de IA Cursor para criar rapidamente novas interfaces sobre essa base de dados. Mais revelador ainda: o próprio CEO disse duvidar que outras empresas devam seguir o mesmo caminho, apostando que o mais provável é uma consolidação do mercado — com menos plataformas SaaS, porém maiores.
A saga Klarna condensa, em um único caso, todas as tensões da decisão que praticamente toda empresa em crescimento enfrenta hoje: comprar uma solução pronta, robusta e mantida por terceiros, ou construir um software sob medida, talhado para o próprio jeito de operar. A pergunta é antiga. O que mudou foi tudo ao redor dela.
Por que a pergunta voltou agora
Comprar ou construir software é um dilema tão velho quanto a própria indústria. Por mais de uma década, a resposta padrão pendeu fortemente para “comprar”. O modelo SaaS — software como serviço — entregava implementação imediata, custo previsível na forma de assinatura, atualizações automáticas e manutenção terceirizada. Construir parecia caro, lento e arriscado.
Três forças trouxeram a discussão de volta.
A primeira é a escala que o SaaS atingiu. O mercado global de software como serviço foi avaliado em cerca de US$ 315 bilhões em 2025, segundo a Fortune Business Insights, com projeções que apontam para mais de US$ 1 trilhão até o início da próxima década. A consultoria Gartner estima que 85% de todo o gasto com software corporativo será baseado em SaaS até 2026. Existem mais de 30 mil empresas de SaaS no mundo — cerca de 17 mil só nos Estados Unidos. Para praticamente qualquer função de negócio, de finanças a RH, de marketing a operações, já existe uma ferramenta pronta. A “compra” nunca foi tão viável.
A segunda força é o efeito colateral dessa abundância, e tem nome: SaaS sprawl — a proliferação descontrolada de assinaturas. Aqui os números são desconfortáveis. Segundo o relatório State of SaaS da BetterCloud, a empresa média passou a usar 106 aplicativos SaaS, número que já chegou a 130 em 2022 e que vem recuando à medida que as organizações tentam consolidar. Em grandes corporações, a conta pode passar de 130, chegando a quase 300 aplicativos em alguns levantamentos. O problema é quanto disso se perde: estudos apontam que entre 49% e 51% das licenças de SaaS contratadas não são utilizadas — a maior taxa de desperdício já registrada. A empresa média desperdiça cerca de US$ 18 milhões por ano com licenças ociosas, e a Gartner calcula que aproximadamente 30% de todo o gasto com SaaS é “tóxico”: dinheiro jogado em software subutilizado, redundante ou esquecido. Em escala global, isso equivale a algo perto de US$ 90 bilhões anuais. O gasto médio com SaaS por funcionário ronda os US$ 5.600 ao ano — e há ainda o custo humano: os trabalhadores perdem, em média, 44 horas por ano apenas navegando entre ferramentas que se sobrepõem.
A terceira força — a mais recente e a mais disruptiva — é a inteligência artificial generativa, que está derrubando o custo de programar. Voltaremos a ela em detalhe. Por ora, basta dizer que o lado “construir” da balança ficou mais leve, e isso muda toda a equação.
No Brasil, o pano de fundo é igualmente vigoroso. De acordo com o Estudo Mercado Brasileiro de Software, elaborado pela ABES em parceria com a IDC, o mercado nacional de TI alcançou US$ 67,8 bilhões em 2025 — salto expressivo frente aos US$ 58,6 bilhões de 2024 —, com o país mantendo a décima posição no ranking mundial de investimentos em tecnologia e a liderança na América Latina. O recado para 2026, contudo, é de maturação: a projeção de crescimento recuou para cerca de 5,3%, sinal de que a fase de expansão acelerada deu lugar a um mercado mais exigente quanto a retorno. Especificamente no segmento SaaS, a consultoria IMARC estima que o mercado brasileiro valia US$ 7,9 bilhões em 2025, com expectativa de chegar a US$ 25,5 bilhões até 2034. E há um dado revelador sobre a vocação do ecossistema: segundo mapeamento da ABStartups com a Deloitte, cerca de 41% das novas startups brasileiras nascem como SaaS, num país em que as micro e pequenas empresas, segundo o SEBRAE, representam 99% do total de companhias.
O framework que organiza a decisão: núcleo e contexto
Antes de falar em custo, é preciso falar em estratégia — e o melhor instrumento para isso não é uma planilha, mas um conceito. O consultor Geoffrey Moore popularizou a distinção entre o que é núcleo (core) e o que é contexto (context) em um negócio, e ela continua sendo o filtro mais útil para decidir o que construir.
O núcleo é aquilo que diferencia a empresa — a funcionalidade proprietária pela qual o cliente paga, a razão de a companhia existir no mercado. O contexto é todo o resto: importante, muitas vezes crítico para operar, mas que não diferencia ninguém. O exemplo clássico é a Uber. O algoritmo que conecta passageiros a motoristas e define o preço é núcleo — é o coração do negócio e deve ser construído internamente. Já o sistema de RH que paga os funcionários ou o CRM que registra leads de vendas é contexto: é commodity, e deve ser comprado. A regra de ouro decorre disso: invista o talento de engenharia — que é escasso e caro — no núcleo, e compre SaaS para o contexto. Construir software próprio para folha de pagamento, e-mail marketing ou um sistema interno de chamados costuma ser alocar recursos preciosos em atividades que não geram vantagem competitiva. Nenhum cliente se importa com a qualidade do seu sistema interno de tickets; ele se importa com o seu produto.
Desse princípio nasce uma regra prática repetida por consultores: a regra dos 80%. Se uma ferramenta SaaS já resolve 80% do que você precisa, compre e adapte o seu processo a ela — o custo de construir os 20% restantes raramente compensa. O erro mais comum, segundo a empresa de desenvolvimento Saigon Technology, é deixar a decisão ser ditada por quem está na sala: um diretor de tecnologia que prefere construir porque é mais interessante, ou um time de compras que prefere comprar porque é mais fácil de justificar. Sem um critério estruturado, escolhe-se a preferência — não a prioridade do negócio.
O custo verdadeiro de construir
Se a estratégia favorece construir o núcleo, a execução é onde os sonhos morrem. E aqui os dados são impiedosos.
O relatório CHAOS, da Standish Group, acompanha o destino de projetos de software desde 1994 e analisa dezenas de milhares de iniciativas. Os números mais recentes mostram que apenas cerca de 31% dos projetos são plenamente bem-sucedidos — ou seja, entregues no prazo, dentro do orçamento e com o escopo completo. Metade fica “comprometida” (atrasada, acima do custo ou com menos funcionalidades que o previsto) e cerca de 19% fracassam por completo. O tamanho importa, e muito: projetos pequenos têm taxa de sucesso próxima de 90%, enquanto os grandes ficam abaixo de 10%.
Os grandes números reforçam o alerta. Uma análise conjunta da McKinsey com a Universidade de Oxford constatou que projetos de TI de grande porte — orçamentos acima de US$ 15 milhões — estouram, em média, 45% do orçamento e 7% do prazo, e entregam 56% menos valor do que o prometido. Um em cada seis projetos sofre um estouro de custo de 200% — os chamados “cisnes negros”, capazes de quebrar um departamento inteiro; no caso mais extremo do estudo de Oxford, o desvio chegou perto de 700%. A Gartner, por sua vez, estima que 75% dos projetos de software corporativo não cumprem os objetivos de negócio originais nos três primeiros anos após a implantação.
Para quem duvida que isso aconteça com gente grande, o exemplo mais célebre é público: o site Healthcare.gov, do governo americano, foi orçado em US$ 93,7 milhões e terminou custando cerca de US$ 1,7 bilhão — além de ter saído do ar duas horas após o lançamento.
Há ainda um custo que não aparece na cotação inicial e que poucos contabilizam: a manutenção perpétua. Construir software não é um projeto com fim; é um compromisso de uma década. Servidores, segurança, atualizações, correções, a saída do desenvolvedor original que levava metade do sistema na cabeça. O fornecedor de SaaS está sempre falando em vendor lock-in — a dependência do fornecedor —, mas o software próprio cria sua própria prisão: a dívida técnica, as dependências internas e a perda gradual de documentação. Trocar de direção, em ambos os casos, é caro e doloroso.
O custo verdadeiro de comprar
Comprar, no entanto, está longe de ser gratuito — e o engano clássico é comparar o “preço de licença” com o “orçamento de construção”. Os dois lados escondem custos.
A armadilha mais traiçoeira do SaaS é a economia de escala que trabalha contra o cliente. Uma ferramenta que custa US$ 200 por mês para 10 usuários pode custar US$ 2.000 por mês para 100 usuários, sem nenhum aumento correspondente no valor entregue ao negócio, como observa a consultoria Founding.dev. Os custos de SaaS tendem a crescer de três a cinco vezes conforme a empresa adiciona assentos, armazenamento ou chamadas de API. E o preço de tabela é só a ponta do iceberg: quando se incluem integração entre sistemas e o trabalho administrativo de gerenciar tudo, o custo total de propriedade real do SaaS ao longo de cinco anos chega a ficar de 150% a 200% acima do valor anunciado, segundo levantamento da Tectome.
Some-se a isso o desperdício estrutural. Se metade das licenças não é usada e as organizações utilizam menos de 40% das funcionalidades pelas quais pagam, boa parte do cheque mensal vira gordura. E há o problema do encaixe imperfeito: software de prateleira é construído para o caso de uso mediano. Quando os fluxos de trabalho de uma empresa se tornam específicos demais, o SaaS deixa de ser um acelerador e vira um gargalo. Os sinais clássicos de que se atingiu o teto de uma ferramenta comprada são reconhecíveis: as gambiarras viram rotina, as planilhas paralelas viram o verdadeiro relatório gerencial, e as integrações exigem conserto constante. Cada uma dessas gambiarras tem um custo — medido em horas de trabalho dos funcionários e em dívida técnica que se acumula silenciosamente.
A matemática do ponto de equilíbrio
Entre os dois extremos existe uma conta, e ela tem um ponto de virada. A boa prática, recomendada por diversas consultorias, é modelar um horizonte de 36 meses — longo o bastante para evitar uma decisão ruim sem cair no excesso de premissas. A comparação honesta soma, de um lado, a licença mais integrações mais tempo de administração mais implementação inicial; e, de outro, o custo de construção mais manutenção anual mais infraestrutura mais melhorias planejadas.
Quando se faz essa conta com rigor, alguns limiares aparecem. Para empresas com 20 ou mais usuários e fluxos de trabalho estáveis, segundo a Founding.dev, o software sob medida costuma se tornar competitivo em custo em cerca de 24 meses — e significativamente mais barato a partir do terceiro ano. A Saigon Technology aponta um limiar parecido em número de usuários: acima de 50 a 100 usuários, o custom frequentemente entrega um TCO menor no horizonte de cinco anos. O recado final, porém, não é sobre quem vence a conta, e sim sobre o tamanho do erro: uma decisão equivocada de construir ou comprar pode multiplicar os custos de duas a cinco vezes ao longo de três a cinco anos. É uma das escolhas de tecnologia mais consequentes que uma liderança fará.
A virada da inteligência artificial
Toda essa aritmética foi escrita com uma régua que a inteligência artificial está reescrevendo. O termo vibe coding — cunhado por Andrej Karpathy no início de 2025 e eleito expressão do ano pelo dicionário Collins — descreve uma forma de produzir software em que se descreve em linguagem natural o que se quer, e a IA gera, depura e itera o código. O que era um conceito exótico virou prática corrente em pouco mais de um ano.
A escala é notável. O mercado de ferramentas de vibe coding foi estimado em cerca de US$ 4,7 bilhões em 2026. Segundo análises do setor, 92% dos desenvolvedores americanos já usam ferramentas de IA diariamente, cerca de 41% de todo o código escrito no mundo é gerado por IA e — talvez o dado mais simbólico — 63% dos usuários dessas ferramentas não são programadores. Pesquisa do GitHub indica que desenvolvedores usando o Copilot completam tarefas até 55% mais rápido. A Gartner projeta que 90% dos engenheiros de software corporativo usarão assistentes de IA até 2028.
As ferramentas se dividem em duas famílias. De um lado, os construtores de aplicativos a partir de prompt — como Lovable, Bolt.new, v0 e Replit —, voltados a fundadores e equipes de produto sem conhecimento técnico, capazes de gerar uma aplicação completa (interface, backend e implantação) a partir de uma conversa. De outro, os editores com IA — como Cursor, GitHub Copilot, Claude Code e Windsurf —, que vivem dentro do ambiente de desenvolvimento e potencializam quem já sabe programar. Os preços convergiram para a faixa de US$ 20 a US$ 25 mensais por usuário nos planos individuais (o Copilot fica em US$ 10), e o custo total de manter em produção uma aplicação construída com IA gira, na prática, entre US$ 50 e US$ 100 por mês para um fundador solo e entre US$ 150 e US$ 300 para uma equipe pequena — muito abaixo dos custos de desenvolvimento tradicional.
A tentação de concluir que “agora todo mundo deve construir” é forte — e é precisamente onde a história da Klarna serve de antídoto. Três advertências se impõem.
A primeira é a qualidade do código. Revisores são unânimes em apontar que o resultado dessas ferramentas é adequado para protótipos, mas exige limpeza significativa antes de ir para produção. Há uma observação recorrente entre quem as usa em projetos longos: o quinquagésimo prompt costuma produzir um código pior que o quinto. O fluxo maduro, hoje, é prototipar rápido em um construtor e depois levar o código para um editor com IA ou para a engenharia, a fim de endurecê-lo — o chamado hardening — com versionamento, testes e observabilidade.
A segunda é que o gargalo se deslocou — não desapareceu. Como sintetizou um artigo da publicação Engineering.com a respeito do caso Klarna:
“O custo de codar caiu; o custo de curadoria não.”
A IA não conserta dados fragmentados e ontologias inconsistentes; ela amplifica essas inconsistências. Alimentar um sistema inteligente com informação duplicada ou conflitante não traz clareza — traz ambiguidade plausível, que é pior. Não foi por acaso que o primeiro movimento da Klarna foi unificar o conhecimento em um banco de grafos, antes de acelerar com IA.
A terceira é a sabedoria de quem já se queimou. O investidor Tomasz Tunguz, ao analisar a aposta da Klarna, observou que, ao longo de uma década, o gasto de uma grande empresa com software pode facilmente ultrapassar US$ 100 milhões, e que, com o custo de produção de software em queda, o ponto de equilíbrio para construir internamente está mais baixo do que nunca. Mas ele mesmo fez a ressalva decisiva: muitas companhias construíram seus próprios sistemas apenas para, depois de gastar muito, acabar comprando soluções comerciais. O nervosismo do mercado quanto ao futuro do SaaS é real — a ação da Dassault Systèmes caiu mais de 20% em uma única sessão no início de 2026 após uma projeção de crescimento fraca —, mas a reação foi mais sobre expectativas do que sobre a morte do modelo.
A terceira via: nem construir tudo, nem comprar tudo
Na prática, a decisão deixou de ser binária, e a maioria das empresas bem-sucedidas opera num espectro. O padrão que mais aparece nas análises é o modelo híbrido: comprar a camada commodity e construir a camada de fluxo de trabalho e de dados que mantém o negócio consistente. Compra-se o sistema central pronto e constroem-se extensões sob medida por cima dele, via APIs.
Esse meio-termo ganhou reforços poderosos. As plataformas low-code e no-code borraram a fronteira entre comprar e construir, permitindo que equipes desenvolvam aplicações rapidamente sem grande profundidade técnica, e que usuários de negócio personalizem soluções que antes exigiam desenvolvedores especializados. O resultado é uma personalização acessível, com a velocidade e a manutenção típicas do software comercial. A própria IA empurra nessa direção: vários fornecedores de SaaS estão incorporando recursos de IA aos seus produtos, estreitando a distância de capacidade entre o pronto e o sob medida. Em outras palavras, comprar deixou de significar engessar.
Um roteiro prático de decisão
Reunindo o que dizem os frameworks, os custos e a experiência acumulada, a escolha se resolve menos com ideologia e mais com perguntas honestas. Os sinais abaixo orientam a balança.
Incline-se a construir quando a maioria destes pontos for verdadeira:
- O software em questão é parte do seu núcleo — aquilo que diferencia e pelo qual o cliente paga —, e não uma função administrativa de bastidor.
- Você está resolvendo um problema que nenhum produto de prateleira resolve, ou já passa boa parte do tempo configurando e contornando uma ferramenta para que ela se aproxime do que você realmente precisa.
- A necessidade vai existir por vários anos — não é um projeto de um único ciclo.
- Controle sobre integrações, dados ou compliance é inegociável — caso comum em setores regulados como finanças, saúde e governo.
- A escala torna a conta favorável: muitos usuários e fluxos estáveis, em que o custo recorrente do SaaS cresceria de forma desproporcional ao valor.
Incline-se a comprar quando a maioria destes pontos for verdadeira:
- A função é commodity (CRM, RH, folha, e-mail marketing, chamados); reinventá-la é desperdiçar engenharia escassa.
- Uma ferramenta pronta já cobre cerca de 80% da necessidade, e o tempo até começar a gerar valor importa mais que a personalização absoluta.
- A urgência é alta; um time de desenvolvimento levaria meses só para escrever a primeira linha.
- Estabilidade, segurança e suporte do fornecedor pesam mais, no seu contexto, do que controle total.
- Você não tem, hoje, engenheiros ociosos com a competência específica necessária para construir e — sobretudo — manter o sistema pela próxima década.
Acima de tudo, vale lembrar a recomendação mais subestimada: a decisão não é permanente. O que fazia sentido construir há três anos pode hoje ser melhor atendido por um produto SaaS maduro — e vice-versa. As empresas que revisam essa escolha anualmente, em vez de tratá-la como definitiva, tomam consistentemente decisões de tecnologia melhores.
O veredito
A pergunta “SaaS sob medida ou pronto” não tem — e nunca teve — uma resposta universal. Tem uma boa heurística: construir para diferenciar, comprar para o que é commodity. E uma conta, modelada com honestidade num horizonte de três a cinco anos, que inclua os custos ocultos dos dois lados. A inteligência artificial não revogou essas regras; ela apenas baixou o custo de entrada do “construir” e, com isso, tornou o erro mais barato de cometer e a vantagem mais valiosa de capturar.
A própria Klarna, que virou símbolo da revolta contra o SaaS, acabou ensinando a lição mais equilibrada de todas. Não trocou software por mágica de IA; reorganizou seus dados, escolheu com cuidado onde construir e onde manter parceiros, e, no fim, seu CEO recomendou que ninguém copiasse o movimento sem entender o próprio contexto. Construir o seu software pode ser a melhor decisão estratégica que a sua empresa tomará — ou o buraco de milhões em que ela vai cair. A diferença entre os dois desfechos não está na tecnologia disponível, que nunca foi tão poderosa, mas na clareza com que você responde a uma pergunta anterior a todas: isto aqui é o coração do meu negócio, ou apenas mais uma engrenagem que eu poderia simplesmente alugar?
Fontes e referências
- Gartner, Fortune Business Insights, Colorlib, CloudZero e SellersCommerce (2025–2026): tamanho e projeção do mercado global de SaaS, participação do SaaS no gasto total com software e número de empresas SaaS.
- ABES e IDC — Estudo Mercado Brasileiro de Software 2025 e 2026: tamanho do mercado brasileiro de TI, crescimento e posição no ranking mundial.
- IMARC Group: dimensionamento e projeção do mercado SaaS brasileiro.
- ABStartups e Deloitte; SEBRAE: perfil das startups brasileiras e peso das micro e pequenas empresas.
- BetterCloud (State of SaaS), Okta (Businesses at Work), Zylo (SaaS Management Index) e JumpCloud: número médio de aplicativos por empresa, licenças não utilizadas e desperdício.
- Gartner / Speakwise: estimativa de gasto “tóxico” com SaaS e custo da fadiga de ferramentas.
- Geoffrey Moore / CloudNuro: o framework núcleo versus contexto e o exemplo da Uber.
- Founding.dev, Saigon Technology, Tectome, SDLC Corp, Appinventiv e MadDevs: custo total de propriedade, pontos de equilíbrio e a regra dos 80%.
- Standish Group (relatório CHAOS); McKinsey e Universidade de Oxford; Gartner: taxas de sucesso, fracasso e estouro de orçamento em projetos de software.
- Lovable, Replit, Cursor, vibecoding.app, techcoffeehouse, RTS Labs e AppDirect: panorama, preços e limites das ferramentas de vibe coding e do desenvolvimento assistido por IA.
- Reportagens e análises sobre a Klarna: CX Today, Inc., Salesforce Ben, TechCrunch, Engineering.com, Tomasz Tunguz e Vendelux.
Dados compilados a partir de fontes públicas entre 2024 e 2026. As cifras de mercado variam conforme a metodologia de cada consultoria e devem ser lidas como ordens de grandeza.