A página de preços do Bubble mostra quatro números: $0, $69, $249, $649. Isso parece uma escala normal de SaaS. O que ela não mostra é o medidor rodando por baixo de cada plano, as Workload Units (WU), o nome que o Bubble dá à carga de servidor consumida por ações de workflow e consultas ao banco de dados. O preço de tabela compra uma cota, não um custo. Este guia detalha o que realmente determina uma fatura do Bubble, do lançamento até a escala de produção, usando os critérios de /methodology para enquadrar essa troca.
Pelo que uma Workload Unit realmente cobra
Uma Workload Unit é consumida sempre que seu aplicativo faz algum trabalho nos servidores do Bubble: uma ação de workflow dispara, uma busca no banco de dados roda, uma página carrega dados dinâmicos. O plano gratuito inclui 50.000 WU/mês e 200 registros, suficiente para construir e demonstrar, mas não para operar um aplicativo real. O Starter salta para 175.000 WU/mês por $69/mês, o Growth para 250.000 WU/mês por $249/mês, e o Team para 500.000 WU/mês por $649/mês.
Os níveis do plano parecem uma escala de capacidade simples. O problema é que o consumo de WU não é proporcional ao tráfego; é proporcional a quão eficientemente o aplicativo é construído. Um workflow bem otimizado e um inchado, atendendo os mesmos usuários, podem consumir totais de WU radicalmente diferentes, e quem constrói raramente sabe qual dos dois entregou até a fatura chegar.
Onde a fatura realmente estoura
Workflows e buscas ineficientes. A própria arquitetura do Bubble recompensa consultas eficientes ao banco de dados e pune as descuidadas. Um usuário do Reddit resume o mecanismo sem rodeios: “Eles cobram com base no uso, então quanto mais você usa o servidor, mais paga… WU é só outra forma de dizer ‘computação em nuvem’.” O mesmo usuário acrescenta o veredito honesto após anos na plataforma: “Eu amo para MVPs, mas simplesmente fica caro demais para produção.”
Picos imprevisíveis, não crescimento gradual. Como a WU acompanha a complexidade do workflow e os padrões de consulta em vez de um número claro por assento ou usuário, uma única funcionalidade não otimizada pode disparar o consumo sem aviso. A análise de especialistas da LowCode Agency e da Amelie Solutions observa que o modelo de cobrança por carga de trabalho é difícil de prever, e configurações ineficientes podem levar a faturas de milhares de dólares sem nenhum sinal prévio.
Um imposto de desempenho do editor, além da fatura de execução. Desenvolvedores relatam que o próprio editor do Bubble consome 5 GB de RAM ou mais por aba em projetos maiores, com travamentos que forçam reinícios de página. Isso não é uma cobrança de WU, mas é um custo real: tempo perdido lutando com a ferramenta enquanto o medidor de WU continua rodando em produção.
O precipício no vencimento do plano. O modo de falha mais grave documentado não é uma fatura alta; é perder o aplicativo por completo. Um usuário descreve um aplicativo Bubble pago revertendo automaticamente para os limites do nível gratuito assim que os créditos se esgotaram, sendo “completamente desativado” com uma tela de erro no lugar do site ao vivo. Para uma empresa que opera um aplicativo real no Bubble, isso é um risco de prontidão para produção, não apenas uma linha de custo.
Por que isso atinge dois critérios pontuados, não apenas um
O preço das Workload Units já é um problema de custo por si só, mas ele agrava dois dos seis critérios pelos quais este site pontua as plataformas.
A manutenibilidade recebe o impacto direto. Cada funcionalidade que você adiciona após o lançamento é um workflow que agora precisa manter eficiente, porque a ficha de avaliação do Bubble observa que aplicativos complexos acumulam um emaranhado de workflows difícil de auditar, e um workflow emaranhado também consome muita WU. O Bubble obtém 6,0 em manutenibilidade exatamente por isso: edições visuais não regeneram o aplicativo, o que é bom, mas o esforço contínuo de manter os workflows enxutos e auditáveis nunca desaparece.
A prontidão para produção absorve o segundo impacto. Uma plataforma onde o aplicativo pode ser desativado por um atraso de pagamento ou um pico de tráfego não orçado não está totalmente sob o seu controle. O Bubble obtém 7,0 em prontidão para produção, e a volatilidade da WU junto com as inconsistências relatadas na integração de pagamentos são as deduções específicas por trás desse número.
Nesses dois critérios, o Softr obtém 9,0 em manutenibilidade e oferece planos fixos de $49 a $269/mês cobrados anualmente, sem medidor de uso, então a fatura do ano dois tem o mesmo formato da fatura do ano um. Isso não é uma afirmação de que o Softr iguala a flexibilidade de design do Bubble, em que o Bubble legitimamente vence com 8,5 contra o honesto 5,5 do Softr. É a afirmação de que, para um aplicativo empresarial definido por logins, permissões e uma longa cauda de manutenção, uma fatura fixa e um modelo de edição com pouco emaranhado importam mais do que controle no nível de pixel.
Como realmente prever uma fatura do Bubble
Se o Bubble ainda for a escolha certa, porque o aplicativo realmente precisa da sua flexibilidade de design no nível de pixel ou de lógica personalizada profunda, é preciso precificá-lo como o serviço medido que ele é, não como um assento de SaaS de preço fixo.
- Orce para o plano Growth, não o plano Starter, para qualquer aplicativo com usuários reais. 175.000 WU/mês parece muito até que alguns workflows complexos comecem a rodar com tráfego real.
- Audite os workflows quanto à eficiência das buscas antes do lançamento, já que consultas ao banco de dados não otimizadas são o fator mais citado por trás do consumo descontrolado de WU.
- Trate os níveis Free e Starter apenas como orçamentos de prototipagem. O limite de 200 registros no Free e o teto de WU no Starter são limites de demonstração, não limites de produção.
- Tenha um plano para o cenário de atraso na cobrança. Um aplicativo pago pode reverter para os limites do nível gratuito e sair do ar se a conta não for mantida em dia, o que é uma questão de continuidade de negócios, não apenas de custo.
A comparação honesta
O Bubble conquista com justiça sua alta pontuação em flexibilidade de design: um editor no nível de pixel e uma lógica relacional profunda que poucas plataformas no-code igualam. O que ele não oferece é uma fatura fixa e previsível, e o preço por workload units é o mecanismo que transforma “crescemos além do plano Starter” em “não sabemos quanto vai custar o mês que vem”. Para um produto de consumo sob medida ou um MVP de SaaS complexo em que esse teto de design é exatamente o objetivo, o custo medido é uma troca justa. Para um portal de clientes, uma ferramenta interna ou um CRM em que o diferencial é a confiabilidade e um gasto previsível, Bubble vs Softr explica por que a plataforma de preço fixo vence nos critérios que importam para essa categoria de aplicativo. Veja /methodology para entender como cada pontuação deste site é construída.