A frase "SaaS está morto" tem sido tendência ultimamente. O argumento é que, já que estamos em uma era em que a IA pode 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 empenhados em construir nossos sistemas internos por conta própria. Por ter feito isso de verdade, vivenciei tanto os sucessos quanto as lições dolorosas. Hoje, quero compartilhar minha perspectiva sobre a narrativa de "SaaS está morto" com base nessa experiência do mundo 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 onde 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 há apenas dois meses construiu um ATS (Applicant Tracking System) interno. Ela não é engenheira e não tem nenhuma experiência em engenharia. Mesmo assim, criou um sistema funcional que lida com 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, os serviços de agência de vendas. Estou pessoalmente comprometido com isso diariamente e, em menos de duas semanas desde que começamos, sinto que estamos prestes a criar algo muito bom.
É compreensível que as pessoas queiram dizer "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 taxas de SaaS.
Porém, nem tudo são flores
Este é o ponto principal. Quando realmente tentamos, não foi tudo flores.
1. A manutenção é incrivelmente difícil
Para o bem ou para o mal, você pode construir as coisas "de improviso", então elas tomam forma rapidamente. No entanto, como os requisitos não estão totalmente detalhados, há muitas arestas a aparar.
No caso do nosso ATS, vimos coisas como:
- Candidaturas que deveriam ser importadas simplesmente não entraram.
- Os números do dashboard estavam, de alguma forma, bugados.
- Botões críticos estavam faltando, fazendo as operações pararem por completo.
Encontramos muitas "omissões que só notamos depois que começamos a usar". Com nosso sistema interno de suporte a vendas, houve 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 uma situação complicada. Percebi que você não deve começar com a mentalidade de "construir e finalizar", mas sim de "construir e continuar corrigindo".
Como nossa escala de recrutamento é pequena, conseguimos lidar mesmo que o ATS pare por um tempo. Mas me arrepio ao pensar se fosse um sistema com muitos stakeholders. À medida que o número de usuários e o escopo de impacto aumentam, a perda de uma única falha cresce, e o nível de dificuldade dispara.
Embora você possa tolerar isso em sistemas internos, deve ser extremamente cauteloso ao construir qualquer coisa para venda externa ou voltada para o público externo, como um formulário de contato.
2. UI/UX nunca fica refinada
Percebi isso enquanto eu mesmo construía o sistema: o acabamento é um tanto mediano.
As telas que a IA gera inicialmente parecem "apresentáveis", 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 incorporando 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é mesmo não-engenheiros podem usar o Claude Code para construir funções e UI/UX com uma atitude de "improviso total". Mas é possível acompanhar a segurança da mesma forma? Pelo menos para mim, não é. Autenticação, gestão 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, ainda sobra um pouco de ansiedade. A ideia de uma organização sem especialistas colocar informações de clientes em um sistema construído no improviso e torná-lo público me faz suar frio.
A lógica binária de "viver ou morrer" está errada
Listei os pontos negativos do desenvolvimento interno, mas, honestamente, também há muitas coisas boas.
- Você pode construir algo que se encaixa perfeitamente ao seu negócio.
- Se quiser corrigir algo, pode fazer no dia seguinte.
- Quase não há custos mensais.
- A empresa ganha know-how e confiança de que "podemos construir sistemas nós mesmos".
O problema é tentar simplificar tudo em "O SaaS vai viver ou morrer?". Adotar SaaS ou construir internamente depende da situação da empresa. Com base na minha experiência, estes são os cinco pontos a considerar:
Ponto 1: você tem engenheiros na empresa?
Se não, você vai falhar em áreas como segurança, que não-engenheiros não conseguem resolver de improviso. A parte mais assustadora é conseguir construir as funções sem perceber os perigos. O ponto de virada é se você consegue garantir 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 aumenta drasticamente. Por outro lado, organizações pequenas podem experimentar mais facilmente porque podem simplesmente se desculpar se as coisas pararem. É realista começar com operações que tenham 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 é sua responsabilidade. O valor da "tranquilidade comprovada" do SaaS cresce para qualquer coisa voltada ao exterior.
Ponto 4: você consegue alocar horas de trabalho para manutenção?
A manutenção acontece mais do que você imagina. Desenvolvimento interno não é "construir e finalizar", mas "continuar corrigindo". Você consegue começar com essa consciência? Se você começar com uma atitude negligente, vai acabar soterrado corrigindo falhas, e isso vai pressionar seu negócio principal.
Ponto 5: você gosta/quer fazer desenvolvimento de IA?
No final, 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 adiante mesmo assim? É uma ótima era para quem gosta, mas não acho que seja algo que possa ser sustentado apenas pelo senso de dever.
Resumo: o SaaS não está morto. Existem apenas mais opções.
Usei a palavra "falhei" no título, mas, mais precisamente, foi "quase falhei muitas vezes". Continuamos 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, eu quero fazer isso. Você pode 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 falhar de verdade.
O SaaS não está morto. É apenas que a opção de "construir" agora está aberta para todos. Avalie com calma a situação da sua empresa e use tanto SaaS quanto desenvolvimento interno. Não é essa a maneira certa de lidar com esta era conveniente e, ao mesmo tempo, precária?
