Seu SaaS custa mais do que reconstruir?

Na semana passada, revisando os custos de consumo de tokens de um dos nosso produtos, encontramos um buraco de US$ 654,61. Em cinco dias, 30,7% do que o fornecedor havia cobrado não aparecia nos nossos registros internos.

O fornecedor não estava errado. Nosso sistema é que registrava o custo tarde demais. Quando uma tentativa consumia tokens e falhava antes da entrega, a cobrança existia, mas o rastro interno desaparecia.

A correção mudou a ordem das coisas: registrar uso e custo antes de tentar entregar a resposta. Também passamos a reutilizar instruções estáveis, em vez de pagar para o modelo processar o mesmo contexto repetidamente. O release passou por 1.937 verificações automatizadas e pelo build final.

Parece uma história de FinOps. Para mim, expôs uma pergunta maior:

Se um software não consegue provar a cognição (ou tokens) que economiza, por que alguém deveria continuar pagando por ele?

Essa pergunta ficou mais incômoda porque o concorrente mudou.

Seu produto agora além de disputar orçamento com outros SaaS.

Agora ele também disputa com a possibilidade de um agente construir uma alternativa sob medida.

Seu novo concorrente é a reconstrução

No ensaio Software Survival 3.0, Steve Yegge propõe um critério simples: software tende a sobreviver quando economiza mais cognição do que custa para ser descoberto, entendido e operado.

Cognição, aqui, não é metáfora bonita. São tokens, energia, tempo e dinheiro.

Quando criar software era caro, um produto mediano podia sobreviver porque a alternativa também era cara. Essa proteção está sumindo. A cada salto dos agentes, a alternativa feita em casa fica menos absurda.

Isso não quer dizer que todo SaaS será substituído por um prompt. Quer dizer que interface deixou de ser defesa suficiente. Um formulário elegante sobre uma API comum pode ser útil hoje e dispensável amanhã.

Yegge organiza esse problema em seis alavancas.

Aqui na Olympus, eu reduziria a decisão a um instrumento mais direto para founders e times de produto: o teste da reconstrução.

Ele tem quatro perguntas.

1. Que decisão cara seu produto comprime?

Git não sobrevive porque ninguém consegue programar outro controle de versão. Sobrevive porque seu modelo carrega décadas de decisões sobre histórico, colaboração, reversão e conflito.

O mesmo vale para bancos de dados e motores de workflow. O código pode ser reproduzido. A travessia intelectual que levou àquele desenho é outra história.

Esse é o primeiro teste para o seu produto: qual erro caro o cliente deixa de repetir porque você já o cometeu, entendeu e transformou em sistema?

Se a resposta for apenas "reunimos estas funções numa tela", o produto comprime pouco. Se ele incorpora regras, exceções, dados e decisões que levariam meses ou anos para reaprender, existe densidade ali.

Na Olympus, é assim que pensamos processo. Shape Up não vale pelo template do pitch. Vale pelas decisões acumuladas sobre como limitar aposta, cortar escopo e evitar que uma equipe passe seis meses polindo a pergunta errada. O artefato é pequeno. A cognição comprimida não é.

2. O que ele executa sem gastar inteligência cara?

LLMs conseguem calcular, buscar e transformar informação. Isso não significa que devam fazer tudo no substrato mais caro disponível.

grep continua excelente porque uma CPU encontra padrões em texto de forma barata e previsível. Uma calculadora resolve aritmética melhor do que um modelo improvisando contas token por token. Índices, caches e regras determinísticas continuam valiosos pelo mesmo motivo.

Reutilizar instruções estáveis evita pagar repetidamente pela mesma interpretação. Registrar custo antes da entrega transforma consumo invisível em dado auditável. O modelo fica reservado para o que exige modelo; o resto vira infraestrutura.

Produto "com IA" não deveria significar jogar tudo dentro da IA. Se toda a lógica depende de inferência, o custo sobe, a previsibilidade cai e a reconstrução fica mais atraente conforme os modelos barateiam.

A pergunta prática é: o que no seu produto pode virar código simples, cache, índice, regra ou ferramenta determinística sem perder valor?

3. Um agente consegue usar sem pedir um guia turístico?

Ter uma API não torna um produto legível para agentes.

Um agente precisa descobrir que a ferramenta existe, entender quando usá-la, chamar a operação certa, interpretar erros e confirmar o resultado. Cada dúvida cobra contexto. Cada resposta ambígua abre uma tentativa nova. Cada comando "quase óbvio" que não existe empurra o agente para um desvio.

Uma ideia forte do texto de Yegge são os desire paths: observar o caminho que os agentes tentam seguir e adaptar a interface quando aquele palpite faz sentido. Em vez de exigir que todo agente memorize a taxonomia interna do produto, você aprende com os erros recorrentes de uso.

Agent UX não é escrever documentação infinita. É oferecer nomes previsíveis, estados legíveis por máquina, erros acionáveis e readback claro. A documentação confirma a intuição, não compensa uma interface hostil.

Se o agente precisa carregar vinte páginas de instrução antes de cada chamada, seu produto está cobrando pedágio cognitivo toda vez que é usado.

4. O que alguém precisa confiar a um humano?

Eficiência não decide todo tipo de valor.

Curadoria, gosto e responsabilidade criam outro tipo de defesa. Uma recomendação assinada por alguém em quem você confia vale mais do que uma lista correta e anônima. Um serviço em que alguém assume a consequência da decisão não equivale a um gerador de output.

Um humano usado como carimbo do que a IA fez não cria esse valor. Só adiciona fila.

O coeficiente humano existe quando alguém traz julgamento ou responsabilidade que muda o resultado. Para uma empresa de serviço como a Olympus, isso importa: o cliente não compra linhas de código. Compra decisões de produto, leitura do risco e alguém que responde pelo trabalho quando a realidade contradiz o plano.

Se você não consegue apontar onde o humano melhora a decisão, talvez ele seja custo operacional. Se consegue, torne esse julgamento visível no produto.

O teste da reconstrução

Pegue um produto e responda sem discurso de venda:

1. Compressão: que decisão difícil ou experiência acumulada ele evita que o cliente tenha de redescobrir?

2. Substrato: que trabalho ele executa de forma mais barata e previsível do que inferência pura?

3. Agent UX: um agente consegue descobrir, operar e verificar o resultado com pouco contexto?

4. Confiança: onde curadoria, gosto ou responsabilidade humana mudam a qualidade da decisão?

Quatro respostas fortes indicam um produto difícil de contornar. Duas respostas vagas indicam vulnerabilidade. Nenhuma resposta revela algo mais próximo de uma feature temporária do que de um negócio defensável.

Seu software não precisa ser impossível de copiar. Precisa ser irracional de reconstruir.

Sua missão para os próximos 7 dias

Escolha um produto que você constrói, mantém ou paga. Reserve 30 minutos e aplique o teste da reconstrução.

Escreva quatro linhas: compressão | substrato | Agent UX | confiança.

Se três respostas forem fracas, não abra uma lista de features. Escolha a alavanca com maior chance de tornar o produto mais caro de refazer do que de continuar usando. Essa é a única decisão da semana.

Conteúdo recomendado

• Software Survival 3.0, de Steve Yegge — o ensaio que originou o modelo e as seis alavancas de sobrevivência.

Forte abraço,

Equipe Olympus