Na revisão de risco de 8 de novembro, a Mutagex tomou uma decisão que parece ir contra o óbvio: deixar desligado o limite de gastos do banco de dados que vai sustentar o Gottit, o app de agenda e assinatura em produção. Não é sobre gastar mais. É sobre o que acontece no dia em que o limite é alcançado, e quem paga esse dia.

O interruptor que parece proteção

O Supabase, provedor do banco usado pelo Gottit, chama esse recurso de Spend Cap: um interruptor, ligado ou desligado, no plano Pro. A documentação oficial é direta sobre o que cada posição faz.

Com o Spend Cap ligado, nenhuma cobrança extra chega na fatura quando o uso passa da cota do plano. Em troca, o projeto entra na Política de Uso Justo da Supabase, e aí o controle sai das mãos de quem opera: a própria plataforma pode pausar projetos, colocar o banco em modo somente leitura ou responder com erro 402 (pagamento necessário) em toda chamada de API, e isso vale para a organização inteira, não só para o projeto específico que furou o teto.

Com o Spend Cap desligado, o uso extra simplesmente é cobrado como excedente, um valor pequeno e previsível por bloco adicional de armazenamento, não uma suspensão de serviço.

A Política de Uso Justo da Supabase está documentada na FAQ oficial de cobrança, e lista com exatidão quais restrições entram em jogo e por quê.

Não é manha de um fornecedor só

O mesmo padrão aparece na documentação oficial do Google Cloud, em outro contexto: um script que a própria Google recomenda para quem quer parar de gastar no instante em que um orçamento é ultrapassado. O mecanismo desliga a cobrança do projeto inteiro assim que o alerta de orçamento dispara, e isso interrompe todos os serviços pagos, inclusive os que estavam dentro do nível gratuito.

Dois provedores, dois produtos diferentes, a mesma lógica: um limite rígido de gasto não é um amortecedor, é um disjuntor. Ele não aparece lentamente. Ele corta.

Por que a Mutagex escolheu pagar o excedente

O Gottit roda com mais de uma empresa cliente dividindo a mesma infraestrutura. Se o Spend Cap estivesse ligado e uma única empresa subisse muita foto ou vídeo num dia ruim, quem sentiria a pausa, o modo somente leitura ou o erro 402 não seria só essa empresa. Seria todo mundo que está no mesmo projeto, inclusive quem nunca passou de nada.

A conta que o time fez com a própria tabela de preço do plano Pro mostrou que o excedente de armazenamento, desligado o limite, custa poucos dólares a cada bloco extra por mês. Diante disso, a escolha foi clara: manter o Spend Cap desligado e montar um alarme interno bem abaixo do teto real de uso combinado da organização, para alguém olhar antes de o excedente virar dinheiro de verdade, e muito antes de virar motivo de pausa.

A lição que serve para qualquer produto com mais de um cliente na mesma base

Limite de gasto rígido protege a fatura no papel. Na prática, ele cria um ponto único de falha compartilhado por todo cliente que, por acaso, está na mesma infraestrutura na hora em que alguém passa do limite. Quando o produto atende uma empresa só, isso já é um risco. Quando atende várias ao mesmo tempo, o pior dia de uma vira o pior dia de todas.

A alternativa não é ignorar o custo. É trocar o disjuntor automático por um alarme que avisa antes, com uma pessoa decidindo o que fazer, em vez de deixar a própria plataforma decidir por restrição.

Quem está construindo um produto que vai cobrar mensalidade de mais de um cliente sobre a mesma infraestrutura vale a pena parar e checar: esse limite de gasto que parece proteção está configurado para avisar, ou para desligar tudo sem perguntar?