SaaSpocalypse pode não ser tão ruim quanto se pensava, aponta texto do clemsau.com

O texto do clemsau.com parte de um episódio banal: o autor deixa o computador aberto por dias, e o terminal ghostty chegou a 43 GB de uso de memória numa máquina com 48 GB, com o Zed ocupando outros 16 GB. Se ferramentas maduras, feitas por engenheiros experientes, vazam memória, como uma empresa comum vai substituir todo o seu software escrevendo código por conta própria, como prevê a tese do SaaSpocalypse?

O autor lista cinco razões. Nem todo mundo consegue construir: quem não lê código não sabe se a saída está correta ou segura. Alguém precisa manter, hospedar e proteger: escrever é a parte barata, o custo está em monitoramento, dependências, patches, backups e plantão às 3 da manhã. Muita gente não sabe o que quer: software opinativo traz decisões prontas. Produto maduro é feito de casos de borda acumulados, que uma reescrita joga fora. E ferramentas compartilhadas são padrões compartilhados, com onboarding, integrações e contratação mais simples.

O texto também admite o outro lado. Muitas empresas pagam por produtos grandes e usam um décimo das funções, e um sistema interno pequeno poderia cobrir esse décimo. O ponto de equilíbrio entre construir e comprar se move conforme o desenvolvimento fica mais barato. O autor sugere um modelo com menos plataformas gigantes e mais ferramentas pequenas e descartáveis, com o software profissional concentrado nas partes críticas e compartilhadas.

O argumento conversa com uma discussão que o CEVIU vem acompanhando. Em 20 de fevereiro de 2026, a matéria "A Reinvenção do SaaS: Por que o SaaS está mudando, mas não desaparecendo" apontava que a equação de construir ou comprar tinha se invertido com a queda do custo de criar software. Em 23 de março de 2026, "Realidade ou Exagero?" descrevia empresas trocando assinaturas caras por ferramentas internas. Em 26 de maio de 2026, "O Apocalipse do SaaS É Balela" defendia que plataformas como SAP e Workday seguem protegidas por integrações, lógica de processos e compliance.

O texto de agora fica entre esses polos. Concede que o ponto de equilíbrio se move, como nas primeiras matérias, mas reforça manutenção, casos de borda e padrões compartilhados, argumentos próximos aos de maio. A novidade é o foco no custo de operar e na dificuldade de especificar o que se quer.

Para fundadores de SaaS, a leitura é que o código deixou de ser o diferencial e a operação virou o produto: confiabilidade, segurança, manutenção e conhecimento acumulado de casos de borda. Para quem vende para pequenas e médias empresas, vale perguntar qual décimo das funcionalidades o cliente realmente usa, porque é ali que uma ferramenta interna concorre. Para quem compra, a conta de construir deve incluir quem cuida do sistema daqui a dois anos.