A grande SaaS-Lighting — como usuários de TI foram "gaslighted"

• O modelo SaaS já convenceu o setor de TI com a promessa de “pagar só pelo que usar e focar no negócio, não na tecnologia”, mas na prática se transformou em uma estrutura de lock-in dos clientes
• Os principais fornecedores passaram a priorizar manter pagamentos recorrentes e coletar dados em vez da satisfação do cliente, e até o chamado gerente de sucesso do cliente serve apenas para evitar churn
• O setor como um todo evita mudanças e inovação sob o nome de “best practice”, produzindo no fim um ecossistema de software padronizado e mediano
• O mercado de SaaS passou a se parecer com um shopping center americano dos anos 1980: excessivamente controlado e previsível, com grandes plataformas atuando ao mesmo tempo como locador e loja
• A solução real não é usar o mesmo sistema que todo mundo, mas sim construir um sistema de informação adequado à organização, algo viável com abordagens alternativas como self-hosting

---

A promessa e a realidade do modelo SaaS

• No início, o SaaS prometia eficiência na operação de TI com ideais como “pay as you go” e “focar no negócio em vez da tecnologia”
  • Os usuários eram convencidos pela mensagem de que poderiam economizar capital e tempo e reduzir a carga de gerenciar tecnologia
• Na prática, porém, grandes fornecedores como Microsoft, Google e Intuit evoluíram para uma estrutura que prioriza a dependência do cliente, não o foco no cliente
  • Eles aplicam pesquisas de satisfação após toda interação, mas isso não passa de mais um meio de coleta de big data
  • Os resultados da pesquisa são secundários; o que realmente importa é que o cliente permaneça e continue pagando
  • Os dados coletados são usados apenas para melhorias incrementais nas margens

O paradoxo do gerente de sucesso do cliente

• Quase toda empresa de SaaS criou o papel de Customer Success Manager
• Essas pessoas são atribuídas às contas para ajudar no onboarding e evitar churn
• O “sucesso” aqui não é o sucesso real da organização, mas apenas fazer com que ela use o produto o suficiente
• Não há nada de errado em criar produtos que os clientes considerem úteis, mas o modelo de negócios de SaaS, com o tempo, virou uma estrutura baseada não em sucesso do cliente, e sim em submissão e inércia
• Em certo ponto, a base de clientes e o produto ficam grandes demais para mudar

Safety in Numbers — a ilusão da segurança nos números

• Muitas empresas adotam SaaS pela lógica de “todo mundo está fazendo” e pelos efeitos de rede
  • Se todo mundo está usando, isso vira o caminho de menor resistência: bom, ou pelo menos bom o suficiente
  • Há valor nos efeitos de rede, mas os números só são segurança até certo ponto
• Os números escondem riscos invisíveis, especialmente riscos do tipo cisne negro
  • Riscos raros, mas catastróficos, são tão incomuns e potencialmente devastadores que ninguém realmente pensa neles
• Sistemas de backup, recuperação de desastres e continuidade de negócios podem proteger contra a falha de um único sistema, mas não contra a perda de contexto e know-how
• O problema real não é a perda, e sim o acúmulo
  • Programas demais, APIs demais, integrações demais e complexidade excessiva disfarçada de sistemas sofisticados
  • Não existe sistema de recuperação de contexto, mas organizações bem-sucedidas dependem de contexto, não de dados
  • Terabytes de dados não significam nada se você não souber por que os possui, o que significam e como usá-los

Excesso de informação e a armadilha da tomada de decisão

• Informação e conteúdo são infinitos e probabilísticos, e não necessariamente previsíveis
• Mais informação não leva automaticamente a decisões melhores; leva apenas a mais dados
• Isso alimenta o medo e o risco do desconhecido
• Não é possível saber tudo antes de tomar uma decisão, mas ao enfrentar o desconhecido e a incerteza, adotar best practices oferece uma confortável sensação de segurança

Undifferentiated Best Practices — boas práticas sem diferenciação

• Existe uma confiança cega em templates de “best practices” por todo o setor
• O problema das best practices é que elas assumem que o mundo parou de mudar
  • Na realidade, o mundo não é estático; ele continua mudando e exige melhoria contínua e evolução
• Adotar cegamente best practices padronizadas não é o caminho para a excelência, mas para uma média comum e sem brilho
• A lógica de “não reinventar a roda” é usada de forma abusiva
  • A alegação é que não vale gastar tempo e esforço resolvendo problemas que já foram resolvidos
• Na prática, isso só torna as empresas boas em alcançar paridade com a concorrência
• Essa abordagem produz mediocridade sem graça e funciona como uma estrutura que bloqueia diferenciação real e avanço

Bland and Generic Applications — um ecossistema de software padronizado

• No ambiente de software comercial, há milhares de aplicações em milhares de categorias, mas no fim ainda recebemos apenas novas variações de apps de notas ou calendário
  • Alguns programas podem parecer mais bonitos ou mais intuitivos, mas a definição do problema e a abordagem são parecidas
• Se o software continua resolvendo repetidamente os mesmos problemas solucionáveis, é porque os desafios que restam são realmente difíceis de resolver com tecnologia
  • Comunicação e colaboração são cheias de nuances e sutilezas que resistem à digitalização
• Isso não se limita às empresas de SaaS; a maioria das empresas de software entrou no bonde do SaaS para facilitar marketing e vendas dos produtos
  • Uma versão gratuita com recursos apenas suficientes para atrair para a assinatura paga
  • E depois vêm as três opções padrão de assinatura no estilo good, better, best
• Adicionar mais ferramentas de comunicação não melhora a qualidade da comunicação; apenas aumenta muito a quantidade, gerando mais ruído e fadiga

Let’s Go to the Mall — SaaS e a semelhança com os shoppings dos anos 1980

• SaaS virou uma tecnologia parecida com os shopping centers americanos dos anos 1980
  • Caros demais, previsíveis demais, e com produtos quase iguais em todo shopping
• Isso não é um mercado dinâmico, mas um mercado altamente controlado
  • O landlord monta a plataforma, os varejistas correm para esse excelente ponto e colhem lucros enormes e vantagens de escala
  • Os varejistas que conseguem pagar o aluguel do shopping oferecem uma experiência altamente controlada
• Os shoppings dos anos 1980 não eram lugares de experimentação ousada nem de assumir riscos; o risco estava em assinar o contrato de locação
• Google e Microsoft são ao mesmo tempo lojas do shopping e landlords que controlam a experiência do shopping
• A Apple opera seu próprio shopping, mais brilhante, mas não diferente
  • Hoje, muitos shoppings físicos virariam cidades fantasmas se a Apple Store não atraísse tráfego
• Em algum momento, a cultura se cansou da experiência de shopping, e os Estados Unidos ficaram cheios de shoppings abandonados
  • Esse modelo funciona até certo ponto, mas as modas mudam
• Pequenas lojas com mercadorias cuidadosamente curadas começaram a atrair o público
• O futuro da tecnologia da informação será muito parecido
  • O importante não é ter o mesmo sistema que todo mundo tem
  • O importante é ter um sistema de informação adequado para você

[GN⁺]

Opiniões no Hacker News

• Discute-se o fenômeno de os consumidores relutarem em pagar o "preço real" do software, assim como não querem pagar o preço real de comida ou roupas
  Antes, era possível comprar uma ferramenta como o Postman por US$ 40 de uma vez; agora, a estrutura é pagar US$ 30/mês em assinatura
  O SaaS tem a vantagem de permitir manter sempre a versão mais recente
  Mas o desenvolvimento de software é, em essência, um trabalho economicamente caro, e seu valor vem sendo subestimado graças ao trabalho não remunerado de contribuidores de código aberto

  • Apresenta-se o contra-argumento: "se a versão 4 já basta, por que continuar atualizando?"
    Houve uma quantidade enorme de software produzido nos últimos 20 anos, mas parece que quase não houve avanços realmente inovadores
    Aponta-se que o desempenho dos computadores melhorou de 10 a 20 vezes, mas, ainda assim, tudo ficou mais lento e mais complexo
  • Enfatiza-se que software, ao contrário de comida, não é um bem essencial
    O software de hoje muitas vezes é imposto ao consumidor e criticado por funcionar como um cavalo de Troia para coleta de dados e vigilância
    O consumidor paga por comida, água e moradia, mas não quer pagar por software
  • Argumenta-se que o Postman é caro não por causa do custo de desenvolvimento, mas por causa da estrutura de retorno ao capital de risco (VC)
    Com um investimento e uma equipe em escala razoável, não haveria necessidade de cobrar preço de Adobe por uma GUI simples para curl
  • Lembra-se que o software empacotado do passado tinha desconto para upgrade e até permitia revenda
    Também se aponta que o SaaS não faz com que contribuidores de código aberto recebam mais compensação
  • Diz-se que o problema do Postman não é simplesmente a sobrevivência dos desenvolvedores, mas o fato de o produto ter ficado complexo e perdido sua simplicidade original para maximizar a receita da empresa
    A empresa já passou por vários clientes diferentes, e afirma-se que o Postman está seguindo o mesmo caminho

• Espera-se que desapareçam as postagens alarmistas do tipo "a AWS caiu" e que se volte a uma discussão normal
  Recorda-se que antes era perfeitamente possível operar só com servidores on-premises, e de forma muito mais eficiente do que hoje
  Agora até desenvolvedores precisam entender AWS e ainda se preocupar com riscos de segurança e vazamento de conhecimento por meio de LLMs
  Há o sentimento de que o avanço tecnológico acabou criando um ambiente de desenvolvimento distópico, e existe saudade de uma UX simples e intuitiva

• Argumenta-se que, para a maioria das empresas, faz sentido usar um "SaaS bom o suficiente" para e-mail, calendário, VPN, CRM etc.
  Ferramentas como Google Workspace, HubSpot e Power BI parecem muito melhores do que produtos offline do passado

  • Em resposta, contesta-se que é injusto pagar aluguel por usuário por um software de escritório que já estava essencialmente pronto há 30 anos
  • Compartilha-se uma experiência pessoal de que o app móvel do HubSpot tem muitos bugs e é desconfortável de usar
    Entende-se que é difícil colocar muita informação numa tela pequena, mas ainda assim ele parece desajeitado

• Critica-se a estrutura de vender as funções de segurança do SaaS por camadas, como se fossem reféns

  • Usa-se o SSO (single sign-on) como exemplo e argumenta-se que um login comum já pode ser seguro o suficiente
    Cair em phishing seria um problema da empresa, não responsabilidade do fornecedor

• Levanta-se a questão da "pirataria", inevitável em qualquer discussão sobre SaaS

  • Explica-se que o SaaS permitiu às empresas controlar completamente o usuário e também se expandir naturalmente de indivíduo → equipe → organização, como na estratégia de disseminação da Salesforce
    O fato de não exigir instalação facilitou a adoção
  • Ironicamente, o mundo defendido por apoiadores de FOSS — lucrar com contratos de serviço — virou realidade, mas o resultado foi um ambiente ainda mais fechado
  • Compartilha-se a experiência de um sistema criado numa startup que foi copiado junto com o código-fonte por uma empresa chinesa de SaaS
    Acrescenta-se que roubo de propriedade intelectual é comum, mas que os dados acabam tendo uma tendência natural à liberdade
  • Analisa-se que, no ambiente corporativo, quase não havia pirataria, então o SaaS não surgiu como modelo para resolver esse problema
  • Menciona-se que, ao ler Fundamentals of Data Engineering, percebeu-se que o web scraping é a nova forma de "cópia" na era do SaaS

• Explica-se que o SaaS em si não é um conceito ruim e pode ser razoável como estrutura de pagar apenas pelo necessário
  O problema é que o modelo de assinatura ficou excessivo e que o vendor lock-in torna impossível mover os dados
  Como na estratégia de "moat" da AWS, o usuário acaba incapaz de sair por causa das dependências que criou
  Por isso, aconselha-se a não depender de SaaS para funções essenciais

  • Critica-se fortemente o AWS Amplify como o pior caso de lock-in

• Aponta-se que enfatizar apenas o lado negativo do SaaS é desequilibrado
  O SaaS B2B pode trazer grandes vantagens ao cliente, desde que a concorrência continue existindo
  O fornecedor tem incentivo para melhorar continuamente o produto e oferecer novos recursos gratuitamente para evitar churn
  Em contrapartida, recorda-se que softwares on-premises antigos tinham contratos de manutenção caros e baixa qualidade
  No fim, cabe ao comprador escolher seu ponto de compromisso

• Diz-se que produtos como Photoshop e AutoCAD teriam sido úteis para freelancers se houvesse opções de assinatura de curto prazo
  Mas, na prática, é difícil ligar e desligar assinaturas com liberdade

  • Compartilha-se que a versão Photoshop 6.0, comprada em 2000, ainda está em uso num PC moderno e funciona perfeitamente sem DRM
    Reforça-se que uma compra única já basta

• Analisa-se que o lock-in fundamental do SaaS vem da combinação de dois elementos

  1. interfaces declarativas e estáveis, 2) suporte de uma equipe operacional especializada
     Defende-se que esses dois pontos devem ser separados (unbundled), e explica-se que o primeiro talvez já possa ser resolvido pelo Nix
     O desafio restante é criar um modelo de negócios de suporte baseado em self-hosting
     Acredita-se que isso seja tecnicamente solucionável, embora ainda não tenha sido implementado