- Dizem que a integração com SaaS permite que desenvolvedores foquem apenas no produto, mas na prática sempre existem 5 custos ocultos (impostos)
- Antes da adoção, nas etapas de descoberta, cadastro, integração, desenvolvimento local e operação, surgem continuamente tempo gasto, complexidade e carga mental
- Ao escolher uma plataforma integrada (Cloudflare, Supabase etc.) em vez de SaaS isolados, é possível reduzir bastante esses custos e complexidades recorrentes
- Como o vendor lock-in é uma realidade inevitável, o melhor é preservar o fluxo de desenvolvimento (Flow) em uma única plataforma integrada, em vez de misturar vários serviços
- No fim, o mais importante não é o framework ou serviço em si, mas o software que quero criar
SaaS é apenas vendor lock-in com branding melhor
- Desenvolvedores ouvem que devem “focar apenas em construir o produto”, mas na prática a adoção de fornecedores SaaS para auth, filas, armazenamento de arquivos, otimização de imagem e afins traz vários pesos junto
- Não existe apenas custo financeiro, mas também consumo de tempo, atrito e desgaste mental.
1. Imposto da descoberta (Discovery Tax)
- Antes de adotar um serviço SaaS, é preciso entender o que ele realmente vende em termos de funcionalidade e valor
- É necessário avaliar detalhes como escopo de resolução do problema, compatibilidade com a stack existente, preço razoável para a escala, clareza da documentação e formas de implementação peculiares
- Esse processo de pesquisa não é algo facilmente compartilhável ou reaproveitável com base em experiências anteriores, e em grande parte envolve decisões subjetivas
- Há o peso de ter que julgar por conta própria se a mensagem de marketing combina com você e se o serviço realmente vai ajudar
2. Imposto do cadastro (Sign-Up Tax)
- Depois de escolher o serviço, é preciso fornecer e-mail e dados do cartão
- É necessário verificar se existe cobrança por uso ou se só há lock-in por assinatura
- Estruturas de preço pouco transparentes são um problema, como custos extras para que membros da equipe tenham acesso ao dashboard
- Também é preciso checar se dá para testar sem trial gratuito e se já exigem pagamento logo no começo
- Antes mesmo de escrever uma linha de código, você já entra em uma relação contratual com o fornecedor
3. Imposto da integração (Integration Tax)
- No processo real de adoção, é indispensável consultar a documentação, instalar bibliotecas, conectar ao framework e resolver problemas extras fora da documentação
- Com frequência surgem conflitos com ferramentas ou problemas inesperados
- Quando o SaaS atende apenas ao mínimo denominador comum, stacks mais modernas ou ambientes especializados exigem ainda mais trabalho
4. Imposto do desenvolvimento local (Local Development Tax)
- Nem sempre fica claro se o serviço SaaS dá suporte ao ambiente local
- É preciso considerar a existência de emulador local e a possibilidade de usar stubs para testes
- Para validar alguns recursos, às vezes é necessário usar tunneling para a nuvem e afins, o que complica a configuração do ambiente
- Acaba sendo inevitável manter ramificações de configuração para produção, staging e local
5. Imposto de produção (Production Tax)
- Depois da integração do serviço, surgem novos pesos no ambiente de produção
- Mesmo em staging e em ambientes de preview de PR, é preciso gerenciar uso, chaves de API, monitoramento, logging e alertas
- É preciso se preparar para erros ou inconsistências que não aparecem no ambiente de desenvolvimento, mas só no ambiente real de operação
- A responsabilidade de manter a estabilidade do serviço acaba sendo repassada ao desenvolvedor
Conclusão
- O slogan do SaaS moderno é “não reinvente a roda”, mas cada novo serviço adicionado vem com atrito
- Adotar um serviço não é uma simples integração, e sim um contrato, acompanhado de mais dependências e mudanças de arquitetura. O vendor lock-in é inevitável e, ao trocar de serviço, o peso de reescrever bastante código vem junto.
- Por isso, em vez de repetir esse tipo de decisão várias vezes, é mais eficiente escolher desde o início uma plataforma tudo-em-um
- O importante é o software que o desenvolvedor realmente quer construir
- Plataformas integradas como Cloudflare, Supabase oferecem banco de dados, filas, imagens e storage no mesmo ambiente, reduzindo drasticamente os impostos citados acima.
- Não há necessidade de ficar alternando entre vários fornecedores (context switching)
- Os problemas ao lidar com chaves de API acontecem com menos frequência
- A necessidade de gerenciar compatibilidade e ramificações por ambiente é minimizada
- Oferecem uma experiência de integração consistente entre desenvolvimento e produção
- Essas plataformas passam a sensação de que tudo roda na mesma máquina e minimizam a distância entre código e serviços, devolvendo a imersão no desenvolvimento ("Flow") que nenhum SaaS consegue oferecer.
> O importante não é a escolha do framework ou do serviço, mas proteger o software que quero construir e o fluxo (Flow)
2 comentários
O Supabase está sendo apresentado como um bom exemplo; então, quais serviços SaaS seriam os que devemos evitar?
Opiniões do Hacker News
Isso é visto como uma versão moderna e enormemente ampliada do “rent seeking” de Adam Smith
Acho que esse tipo de atividade econômica é socialmente nociva, então deveria ser evitada e até criminalizada
Por outro lado, o extremo do software livre também é problemático do ponto de vista econômico, porque o esforço do criador do software não fica proporcional ao valor obtido pelo usuário
Defende-se que a compra do software e o contrato de serviço sejam separados, de modo que cada um ofereça valor real de forma independente
O problema do SaaS é que tudo isso fica empacotado junto, e na prática a embalagem acaba se tornando excessivamente distorcida em relação ao próprio serviço
Se eu tivesse tanta convicção assim, deveria montar meu próprio SaaS e abrir uma empresa para distribuir e operar on-premises, oferecendo isso por um preço parecido com o do SaaS atual
Se fosse possível dar às empresas o mesmo nível de qualidade, garantia e preço do SaaS, ao mesmo tempo preservando o controle dos dados e evitando vendor lock-in, isso poderia dominar o mercado
Sempre fico pensando nisso: e se eu entregasse só o binário e deixasse o usuário rodar em AWS, GCP ou Cloudflare Workers?
Do meu ponto de vista, SaaS é atraente como desenvolvedor, mas desagradável como consumidor, então acabo num dilema ético
Se eu vendesse software, o que aconteceria se o usuário simplesmente redistribuísse sem autorização? Eu não conseguiria controlar a distribuição como no SaaS
Sou defensor de FOSS, mas, como você disse, esse modelo também tem problemas econômicos
Também penso em algo como emitir licenças via GitHub Sponsors, e em alguns projetos considero um modelo em que a autenticação fica sob SSPL, ou então muda para BSD/MIT com a compra da licença, parecido com o antigo Redis
Ainda assim, fico na dúvida se as pessoas realmente comprariam caso eu aplicasse esse modelo, e também considero oferecer os dois caminhos, mas não tenho uma resposta clara e peço conselhos
Como referência, alguns projetos que criei incluem uma ferramenta para qualquer pessoa criar criptomoeda de graça, um recurso para trazer um blog do YouTube e um armazenamento ilimitado usando a comunidade e os vídeos do YouTube como alternativa ao Google Photos; também estou pensando em reforços de privacidade. Se tiver ideias de monetização, gostaria de ouvir
A maior parte do SaaS implica custos contínuos para o fornecedor, como hospedagem, suporte e P&D
Por isso, é difícil concordar com a lógica de que essa estrutura seria “rent seeking”
Nem todo SaaS pode ser visto como rent seeking; o ponto é que a própria “stickiness” do software já se parece, por natureza, com rent-seeking
A maioria das empresas de SaaS busca stickiness, mas isso não é uma característica exclusiva do SaaS
Eu vendo meu produto SaaS para clientes que querem comprá-lo no mercado por um preço razoável
Vendor lock-in costuma ser aquilo que você sente quando pergunta internamente “por que não adotamos a ferramenta NEWTHING?” e ouve como resposta que já existe um contrato de 5 anos com Oracle, MS, IBM ou Salesforce, então não tem jeito
Aí, depois de uns 10 anos, você realmente acaba totalmente preso àquele fornecedor e cria-se uma estrutura em que já não dá mais para trocar
Se o negócio dura 10 anos, isso pode até ser uma bênção ou um problema entediante, mas eu daria o conselho de não gastar tempo escolhendo várias ferramentas no início da startup e sim escolher rapidamente uma plataforma e focar nela
Mesmo nesses casos, há quem defenda abstrair os serviços por meio de interfaces padronizadas
Se isso estiver abstraído, mais tarde, ao migrar para outro serviço, basta fornecer uma implementação alternativa
Essa abordagem é voltada para o futuro, mas muita empresa hoje ainda está despreparada nesse aspecto
Acho que minimizar dependências é um dos fatores mais importantes para melhorar a sustentabilidade do produto e do negócio
No meu emprego anterior, fui responsável por integrar ao nosso produto uma experiência de assinatura eletrônica no estilo DocuSign
Conversamos com grandes fornecedores como DocuSign e Adobe, mas sentimos que, por causa das limitações das APIs, aquilo não se encaixava bem nas necessidades do produto e dos clientes, então decidimos implementar internamente
Em geral, recriar uma ferramenta como DocuSign é uma má ideia, mas nosso produto já tinha a confiança dos clientes, então a barreira de adoção era baixa
No começo, implementar por conta própria deu bastante trabalho, mas quando surgia a necessidade de pequenos ajustes sob medida para clientes reais, conseguíamos responder rapidamente, e ficou claro que, se tivéssemos usado um fornecedor, isso teria virado uma grande reforma muito mais trabalhosa; por isso, a escolha de fazer internamente foi acertada
Entendo que o autor está dizendo que SaaS é vendor lock-in, então não deveria ser comprado
Mas, ao mesmo tempo, no texto ele recomenda apostar tudo numa plataforma específica, a Cloudflare
No fim, qualquer escolha é lock-in, e até open source e self-hosting exigem reescrever muito código quando você troca
Usar funcionalidades dependentes de fornecedor não é a mesma coisa que “lock-in de verdade”; o lock-in acontece quando mudar passa a custar mais tempo e dinheiro do que continuar com a solução atual
Se o software for fracamente acoplado e coeso, fica mais fácil substituir partes específicas
Isso porque, quando a interface é simples, a troca também é simples
Portanto, a escolha de “já que tudo é lock-in, então vamos nos prender de vez a uma única plataforma” pode ser cômoda para o desenvolvedor, mas é uma estratégia ruim do ponto de vista da gestão, e o foco deveria estar na flexibilidade e na capacidade de mudança da empresa
Do ponto de vista empresarial, é preciso escolher soluções que deem flexibilidade e capacidade de adaptação à empresa, e se amarrar a um SaaS sem alternativas é algo tolo
No começo, ou quando ainda não há receita, é mais vantajoso usar uma plataforma do que SaaS; quando a empresa cresce e entra em fase de escala, faz sentido pensar também em mudanças tecnológicas de longo prazo
Eu uso Cloudflare Workers com frequência e escrevo o código para ser portável para qualquer lugar
Dá para rodar localmente com
wrangler dev, e de fato funciona em pure node/bun/deno sem grandes mudançasO autor não é contra SaaS em si (afinal, recomenda soluções as a service como Cloudflare ou Supabase), mas o ponto central é o custo operacional e a carga de gerenciar relacionamentos ao contratar e administrar fornecedores demais
Quanto menor o número de fornecedores e de dependências, mais fácil é operar
Implementar tudo com bibliotecas padrão é uma ideia bonita, mas na prática é muito difícil
A proposta principal é: em vez de misturar vários serviços logo no início, tente usar uma única plataforma
Eu prefiro a Cloudflare porque ela padroniza bindings de forma parecida com
fetch, efetchme parece os pipes do Unix no mundo webHá quem veja ironia em tentar evitar vendor lock-in colocando tudo em uma única plataforma e, assim, se amarrando ainda mais a uma única empresa
SaaS também tem um custo de dispersão (“imposto”)
Na verdade, essa discussão parece mais uma defesa do open source
Com open source e self-hosting, a maioria desses “impostos” mencionados no texto (descoberta, cadastro, integração e custos ligados ao desenvolvimento local) desaparece
Acho que o production tax do open source pode ser resolvido com um ecossistema ativo, plugins e um ecossistema de módulos
Fazendo uma analogia com a diferença entre religião e culto: se você consegue extrair seus dados em um formato padrão e ir embora, então não é vendor lock-in
Menciona-se também a preocupação de que o cliente se sente menos lesado quando consegue obter seus próprios dados, mas muitos serviços SaaS tornam isso impossível
Atualmente, opero mais no estilo de publicar e distribuir em MIT e manter em privado o que é importante
A limitação do SaaS é que ele impede o cliente de aproveitar os benefícios do “custo marginal quase zero” do software
O operador de SaaS até reduz o preço em certa medida para refletir esse ganho, mas quando o número de usuários cresce bastante e o ticket unitário fica alto, no fim quem usa SaaS acaba saindo em desvantagem
Ainda assim, no começo de uma startup, construir tudo por conta própria é uma escolha imprudente, e na fase de “sobrevivência” e “minimização do custo inicial”, o SaaS é uma estratégia muito inteligente
Só depois que o negócio cresce e o SaaS se torna profundamente incorporado ao dia a dia é que surgem os problemas de lock-in, migração e custo de mudança
Acho que os problemas do SaaS são, no fim, um efeito colateral do sucesso
É por isso que existem tantos negócios nesse modelo de SaaS
É um modelo atraente demais: gera receita recorrente como uma anuidade e ainda dá poder de precificação