A frase "SaaS está morto" tem sido tendência ultimamente. O argumento é que, como estamos em uma era em que a IA consegue escrever código, deveríamos parar de pagar mensalidades de SaaS e simplesmente construir o que precisamos internamente.
Na minha empresa, a Emooove, passamos os últimos meses totalmente dedicados a construir nossos sistemas internos. Por ter feito isso de verdade, vivi tanto os sucessos quanto as lições dolorosas. Hoje, quero compartilhar minha perspectiva sobre a narrativa de que "SaaS está morto" com base nessa experiência real.
Para deixar claro, escrevo isto da perspectiva de um usuário/construtor de sistemas, não de um provedor de SaaS.
Uma Era Incrível em que Qualquer Um Pode Construir Sistemas
Primeiro, como premissa, a chegada do Claude Code realmente trouxe uma era em que "qualquer um pode construir um sistema". Isso não é exagero.
Na Emooove, uma líder de recrutamento que estava conosco havia apenas dois meses construiu um ATS (Sistema de Rastreamento de Candidatos) interno. Ela não é engenheira e tem zero experiência em engenharia. Apesar disso, ela criou um sistema funcional que cuida de tudo, desde a importação de candidatos até a gestão de seleção e dashboards.
Além disso, estamos desenvolvendo atualmente um sistema interno para melhorar a eficiência operacional e a qualidade do nosso negócio principal, que são os serviços de agência de vendas. Estou pessoalmente empenhado nisso diariamente e, em menos de duas semanas desde o início, sinto que estamos prestes a criar algo muito bom.
É compreensível que as pessoas queiram dizer que "SaaS está morto" quando você pode construir internamente algo que, de outra forma, custaria dezenas ou centenas de milhares de ienes por mês em mensalidades de SaaS.
Porém, Nem Tudo São Flores
Este é o ponto principal. Quando realmente tentamos fazer isso, não foi nenhum mar de rosas.
1. A Manutenção é Incrivelmente Difícil
Para o bem ou para o mal, você consegue construir as coisas "no improviso", então elas tomam forma rapidamente. No entanto, como os requisitos não estão totalmente definidos, há muitas arestas.
No caso do nosso ATS, vimos coisas como:
- Entradas que deveriam ser importadas não foram.
- Os números dos dashboards estavam, de alguma forma, bugados.
- Botões críticos estavam faltando, e as operações acabavam travando.
Encontramos muitas "omissões que só notamos depois de começar a usar o sistema". Com nosso sistema interno de apoio a vendas, teve até uma manhã em que, de repente, não conseguimos acessá-lo e a tela não abria.
Claro, isso pode ser corrigido até certo ponto definindo os requisitos com mais cuidado ou fazendo melhorias ao longo do caminho. No entanto, durante esse tempo, as operações normais do negócio são interrompidas. Se você começar a construir com a expectativa de que será "fácil e rápido", vai acabar em apuros. Percebi que você não deve começar com a mentalidade de "construir e terminar", mas sim de "construir e continuar corrigindo".
Como nosso volume de recrutamento é pequeno, conseguimos administrar mesmo que o ATS pare por um tempo. Mas me arrepio só de pensar se fosse um sistema com muitos stakeholders. À medida que o número de usuários e o alcance do impacto aumentam, a perda com uma única falha cresce, e o nível de dificuldade dispara.
Embora você possa tolerar isso em sistemas internos, deve ter extrema cautela ao construir qualquer coisa para venda externa ou qualquer coisa que fique exposta ao mundo externo, como um formulário de contato.
2. UI/UX Nunca Fica Polida
Percebi isso enquanto construía o sistema eu mesmo: o acabamento é um tanto mediano.
As telas que a IA gera inicialmente parecem "decentes", mas quando você realmente as usa, os detalhes são toscos. Embora você consiga deixá-las bonitas eventualmente, dando instruções repetidas vezes, isso exige uma obsessão intensa e tempo. A maioria das pessoas provavelmente vai se contentar com algo pela metade.
As interfaces de SaaS são polidas porque designers profissionais passaram anos refletindo o feedback dos usuários; isso não é algo que você ganha de graça.
3. A Questão da Segurança
Esta é a parte mais assustadora.
Até quem não é engenheiro consegue usar o Claude Code para construir funções e UI/UX com uma atitude de "vai no improviso". Mas será que dá para acompanhar a segurança do mesmo jeito? Pelo menos para mim, não dá. Autenticação, gerenciamento de permissões, resposta a vulnerabilidades — "funcionar" e "ser seguro" são duas coisas completamente diferentes.
No nosso caso, felizmente temos alguém com experiência como engenheiro de segurança, então fazemos questão de que essa pessoa cuide dessa parte. Mesmo assim, resta um pouco de ansiedade. Só de pensar em uma organização sem especialistas colocando informações de clientes em um sistema construído no improviso e o deixando público, me dá um suor frio.
A Lógica Binária de "Viver ou Morrer" Está Errada
Listei os pontos negativos do desenvolvimento interno, mas, honestamente, há muitas coisas boas também.
- Você pode construir algo que se encaixa perfeitamente no seu negócio.
- Se quiser corrigir algo, dá para fazer no dia seguinte.
- Quase não há custos mensais.
- A empresa ganha know-how e confiança de que "nós mesmos conseguimos construir sistemas".
O problema é tentar simplificar tudo em "O SaaS vai viver ou morrer?" Adotar SaaS ou construir internamente depende da situação de cada empresa. Com base na minha experiência, estes são os cinco pontos a considerar:
Ponto 1: Você tem engenheiros na equipe?
Se não tiver, você vai falhar em áreas como segurança, que quem não é engenheiro não consegue resolver no improviso. A parte mais assustadora é conseguir construir as funções sem perceber os perigos. O ponto de virada é se você consegue contar com uma pessoa experiente para revisar as áreas críticas.
Ponto 2: Número de stakeholders
Se houver muitos, a perda quando uma falha ocorre é enorme, e o nível de dificuldade sobe drasticamente. Por outro lado, organizações pequenas conseguem experimentar com mais facilidade, porque basta pedir desculpas se algo parar. É realista começar por operações com um escopo de impacto pequeno.
Ponto 3: Sistemas externos vs. internos
Com sistemas internos, o risco é limitado se algo acontecer. No entanto, para qualquer coisa externa, um único vazamento de informações pode ser irreversível. Enquanto o SaaS permite que você transfira parte da responsabilidade para o fornecedor, no desenvolvimento interno, tudo é responsabilidade sua. O valor da "tranquilidade comprovada" do SaaS aumenta para qualquer coisa exposta ao mundo externo.
Ponto 4: Você consegue alocar horas de trabalho para a manutenção?
A manutenção acontece mais do que você imagina. Desenvolvimento interno não é "construir e terminar", mas "continuar corrigindo". Você consegue começar com essa previsão? Se começar com uma atitude pela metade, vai acabar soterrado corrigindo falhas, e isso vai pressionar seu negócio principal.
Ponto 5: Você gosta/quer desenvolver com IA?
No final das contas, tudo se resume a isso. É mais tedioso e difícil do que você imagina, e é frustrante quando a IA não obedece (risos). Você consegue levar isso até o fim mesmo assim? É uma era incrível para quem gosta disso, mas não acho que seja algo que se sustente apenas no senso de dever.
Resumo: O SaaS Não Está Morto. Apenas Existem Mais Opções.
Usei a palavra "falhei" no título, mas, para ser mais preciso, foi "quase falhei muitas vezes". Continuamos com o desenvolvimento interno porque temos engenheiros experientes, nossa organização ainda é pequena, é principalmente para uso interno, estamos preparados para nos comprometer com a manutenção e, acima de tudo, porque eu quero fazer isso. Pode-se dizer que estamos fazendo isso porque estamos em um ambiente privilegiado, onde todos os cinco pontos são atendidos.
Por outro lado, se uma empresa que não atende a essas condições levar "SaaS está morto" ao pé da letra e tentar construir suas operações principais internamente, ela vai fracassar de verdade.
O SaaS não está morto. É só que a opção de "construir" agora está aberta para todos. Avalie com calma a situação da sua empresa e use tanto o SaaS quanto o desenvolvimento interno. Não é essa a maneira certa de lidar com essa era conveniente e, ao mesmo tempo, precária?
