- Eu era cético em relação à ideia de que SaaS seria substituído por LLMs, mas compartilho aqui a experiência de ter substituído em 20 minutos, com meu próprio código, um serviço de exibição de depoimentos do LinkedIn/X que custava US$ 120 por ano
- O serviço substituído estava com o sistema de pagamento quebrado desde 2023 e abandonado nesse estado, e o suporte ao cliente só chegou ao ponto de enviar um link quebrado
- Usando o Codex, converti a solução para uma abordagem modular que separa os depoimentos em arquivos JSON e gera HTML em build time, mantendo o resultado visual idêntico ao anterior
- Para desenvolvedores, isso pode ser um trabalho rápido e interessante, mas para não desenvolvedores, validar a saída de código de um LLM pode ser uma barreira de entrada
- Micro SaaS de natureza estática que não oferecem valor contínuo correm o maior risco de serem substituídos primeiro na era dos LLMs
Ceticismo anterior em relação à tese de substituição de SaaS por LLMs
- O núcleo da teoria de que SaaS será substituído por LLMs é o seguinte: SaaS é um produto puramente de software, e como os LLMs reduzem drasticamente o custo e o tempo para construir software sob medida, a maioria dos fornecedores de SaaS acabará desaparecendo
- Em resposta, há o contra-argumento de que softwares de RH como o Workday não são apenas software simples, mas serviços que garantem conformidade regulatória em vários países (indenização de férias, holerite etc.) e são continuamente atualizados conforme mudam os ambientes interno e externo
Experiência de uso do Shoutout.io e motivo da saída
- Usei o Shoutout.io por quatro anos, pagando US$ 120 por ano, para exibir uma seção de depoimentos com base em posts do LinkedIn e do X no pragmaticengineer.com
- Eu fazia login cerca de uma vez por ano, e o acesso mais recente foi para conferir a fatura anual por motivo de prestação de contas
- A seção de pagamento estava quebrada e abandonada desde 2023; enviei um e-mail à equipe de suporte e recebi de volta um link quebrado
- O gatilho direto para abandonar o SaaS foi a situação de não conseguir nem verificar qual seria o valor cobrado no ano seguinte
O trabalho de substituição em 20 minutos com o Codex
- A abordagem não foi reconstruir o SaaS inteiro, mas apenas meu caso de uso específico: exibir depoimentos, adicionar novos depoimentos e manter o design
- Pedi ao Codex que elaborasse um plano para remover a dependência de terceiros e hospedar tudo dentro do repositório no GitHub
- Ajustei a solução para um modelo modular, gerenciando os depoimentos em arquivos JSON separados e gerando HTML na etapa de build em tempo de compilação
- Incluindo a adição da etapa de build local, configuração do gatilho de build do Netlify, testes, ajustes de UX, criação do schema e deploy, o processo todo levou 20 minutos
- O resultado final ficou visualmente idêntico ao anterior, com eliminação completa da dependência de terceiros
- Quando a equipe de suporte finalmente enviou um link funcionando (duas horas depois), a migração já estava concluída
Implicações para engenheiros de software
- Desenvolvedores já estão acostumados a, em atualizações futuras, usar linha de comando e agentes de AI para inserir depoimentos no codebase e validar os resultados, mas para não desenvolvedores a validação do código gerado por LLM pode ser uma barreira de entrada
- A velocidade com que desenvolvedores conseguem “portar” um SaaS para código próprio é muito maior do que a de não desenvolvedores
- Na primeira tentativa, o Codex implementou errado usando o modelo flexbox, e foi preciso decidir diretamente qual framework de layout de UI usar
- Mesmo não desenvolvedores poderiam resolver isso, mas provavelmente levariam mais tempo
- Reescrever diretamente uma funcionalidade de terceiros é algo divertido e educativo, além de ser uma oportunidade de experimentar na prática o desempenho real dessas ferramentas
Implicações para o negócio de SaaS
- Reconstruir um SaaS inteiro e reconstruir apenas um caso de uso específico são coisas com níveis de dificuldade muito diferentes
- O Shoutout tem mais de 10 vezes mais funcionalidades, como adicionar citações em mais de 10 plataformas, autenticação e pagamentos
- SaaS estáticos que, após exibir depoimentos, não oferecem valor contínuo são os mais fáceis de substituir
- Em contrapartida, se houver funções de suporte ao negócio em tempo real, como conformidade, análise e alertas, a substituição se torna muito mais difícil
- Pode haver queda na rentabilidade do negócio de compra e venda de SaaS
- O Shoutout foi criado em 2020 por um desenvolvedor independente, vendido em 2022 para um product studio e revendido em 2025 para outro desenvolvedor
- Do ponto de vista do usuário, não houve mudança além do sistema de pagamento quebrado
- Os compradores podem ter esperado crescimento de receita sem investir, mas quando o produto é deixado de lado, os usuários vão embora e chega o momento em que ele pode ser facilmente substituído por LLMs
- Vivemos uma era em que deixar “janelas quebradas (Broken Windows)” sem conserto é muito menos tolerado do que antes
4 comentários
O custo de manutenção também pesa.
A adoção de software sempre deve ser avaliada sob a ótica do
TCOao longo de "5 anos". Caso contrário, você só vai acumulando "bombas" que de fato explodem depois.Parece que você pensou nisso de forma bem simplista mesmo kkk
Se foi um usuário que escreveu isso ou se a pessoa construiu por conta própria, depois disso essa funcionalidade vai precisar continuar sendo gerenciada internamente, em vez de por um fornecedor externo. Isso não consome tempo nem dinheiro e é de graça??