Unidade Mínima Viável de Software: quando construir ou comprar faz mais sentido

O conceito de 'unidade mínima viável de software comercializável' não é só sobre preço ou esforço, é uma equação de custo total de propriedade (TCO) redefinida pela IA. Em 2026, o custo de construção caiu 60, 80%, mas o custo de supervisão humana não desapareceu: ele se deslocou do código para a curadoria, validação e manutenção contínua de saídas geradas por LLMs. Um projeto LLM típico em produção exige entre US$ 80 mil e US$ 600 mil, não só pelo modelo, mas por inferência, recuperação de contexto, infraestrutura, monitoramento e otimização contínua.

Isso explica por que ferramentas como Jira e Salesforce ainda têm espaço: não porque são tecnicamente insuperáveis, mas porque seu TCO inclui suporte, atualizações regulares, conformidade e integração consolidada, itens que não são automaticamente replicáveis com um prompt. A queda de 50% nas ações da Atlassian e 33% na Salesforce em 2026 não reflete fraqueza operacional, mas sim o pânico de investidores diante de um novo parâmetro: se o custo de reescrever um rastreador de tarefas é menor que o custo de manter um contrato SaaS + o tempo gasto em customizações, o valor do produto muda, mesmo que ele funcione perfeitamente.

A CEVIU já havia identificado em fevereiro de 2026 que a equação 'construir ou comprar' havia invertido, mas a novidade agora é a emergência de uma zona de viabilidade quantificável. Antes, falávamos em tendência; hoje, temos números concretos: para um time de até 20 devs, o River Pro a US$ 125/mês é mais barato que 2 horas/mês de engenheiro supervisionando um clone LLM (US$ 192/mês só em salário). E isso considera apenas o custo humano, sem incluir dívida técnica, risco de compliance ou esforço de integração contínua, temas destacados em nossa cobertura de 2026-06-19 sobre software descartável e 2026-06-17 sobre revisões caras.

Para desenvolvedores, isso redefine o valor profissional: não mais 'quem escreve mais linhas', mas 'quem define melhor os limites da viabilidade'. A habilidade de avaliar se um problema está dentro ou fora da zona de viabilidade, com base em complexidade real (não só funcional), custo de manutenção humana e risco de obsolescência, virou uma competência central. Isso impacta arquitetura, escolha de stack e até contratação: times que apostam em 'software descartável' precisam de engenheiros fortes em testes, observabilidade e modelagem de domínio, não só em prompt engineering.