La página de precios de Bubble muestra cuatro cifras: 0 $, 69 $, 249 $, 649 $. Eso parece una escala SaaS normal. Lo que no muestra es el contador que corre bajo cada plan, las Workload Units (WU), el nombre que da Bubble a la carga del servidor consumida por las acciones de flujo de trabajo y las consultas a la base de datos. El precio de venta compra una asignación, no un coste. Esta guía desglosa qué determina realmente una factura de Bubble desde el lanzamiento hasta la escala de producción, usando los criterios de /methodology para enmarcar la disyuntiva.
Por qué se cobra realmente una Workload Unit
Se consume una Workload Unit cada vez que su aplicación hace un trabajo en los servidores de Bubble: se dispara una acción de flujo de trabajo, se ejecuta una búsqueda en la base de datos, una página carga datos dinámicos. El plan gratuito incluye 50.000 WU/mes y 200 registros, suficiente para construir y hacer una demo, pero no para operar una aplicación real. Starter salta a 175.000 WU/mes por 69 $/mes, Growth a 250.000 WU/mes por 249 $/mes, y Team a 500.000 WU/mes por 649 $/mes.
Los niveles del plan parecen una escala de capacidad sencilla. El problema es que el consumo de WU no es proporcional al tráfico; es proporcional a la eficiencia con la que está construida la aplicación. Un flujo de trabajo bien optimizado y uno inflado que atienden a los mismos usuarios pueden consumir totales de WU radicalmente distintos, y quien lo construye rara vez sabe cuál de los dos ha entregado hasta que llega la factura.
Dónde se dispara realmente la factura
Flujos de trabajo y búsquedas ineficientes. La propia arquitectura de Bubble recompensa las consultas eficientes a la base de datos y penaliza las descuidadas. Un usuario de Reddit resume el mecanismo sin rodeos: «Cobran según el uso, así que cuanto más uses el servidor, más pagas… WU no es más que otra forma de decir ‘computación en la nube’». El mismo usuario añade el veredicto honesto tras años en la plataforma: «Me encanta para MVP, pero simplemente se vuelve demasiado caro para producción».
Picos impredecibles, no un crecimiento gradual. Como las WU siguen la complejidad del flujo de trabajo y los patrones de consulta en lugar de una cifra clara por asiento o usuario, una sola función no optimizada puede disparar el consumo sin previo aviso. El análisis de expertos de LowCode Agency y Amelie Solutions señala que el modelo de facturación por carga de trabajo es difícil de prever, y que configuraciones ineficientes pueden llevar la factura a miles de dólares sin ninguna señal previa.
Un impuesto de rendimiento del editor, además de la factura de ejecución. Los creadores informan de que el propio editor de Bubble consume 5 GB de RAM o más por pestaña en proyectos grandes, con retrasos que obligan a reiniciar la página. Eso no es un cargo de WU, pero sí un coste real: tiempo perdido peleando con la herramienta mientras el contador de WU sigue corriendo en producción.
El precipicio al expirar el plan. El modo de fallo más grave documentado no es una factura elevada; es perder la aplicación por completo. Un usuario describe una aplicación de pago de Bubble que revirtió automáticamente a los límites del nivel gratuito al agotarse los créditos, y que quedó «completamente desactivada» con una pantalla de error en lugar del sitio en directo. Para una empresa que opera una aplicación real en Bubble, eso es un riesgo de preparación para producción, no solo una línea de coste.
Por qué esto afecta a dos criterios puntuados, no a uno
El precio de las Workload Units es, de por sí, un problema de coste, pero agrava dos de los seis criterios con los que este sitio puntúa las plataformas.
La mantenibilidad recibe el impacto directo. Cada función que añada tras el lanzamiento es un flujo de trabajo que ahora debe mantener eficiente, porque la ficha de puntuación de Bubble señala que las aplicaciones complejas acumulan una maraña de flujos de trabajo difícil de auditar, y una maraña de flujos de trabajo también consume muchas WU. Bubble obtiene 6,0 en mantenibilidad precisamente por esto: las ediciones visuales no regeneran la aplicación, lo cual es positivo, pero la carga continua de mantener los flujos de trabajo esbeltos y auditables nunca desaparece.
La preparación para producción absorbe el segundo golpe. Una plataforma en la que la aplicación puede quedar desactivada por un impago o un pico de tráfico no presupuestado no está totalmente bajo su control. Bubble obtiene 7,0 en preparación para producción, y la volatilidad de las WU junto con las incoherencias reportadas en la integración de pagos son las deducciones concretas detrás de esa cifra.
En esos dos criterios, Softr obtiene 9,0 en mantenibilidad y ofrece planes fijos de 49 $ a 269 $/mes facturados anualmente sin contador de uso, de modo que la factura del año dos tiene la misma forma que la del año uno. No es una afirmación de que Softr iguale la flexibilidad de diseño de Bubble, donde Bubble gana legítimamente con 8,5 frente al honesto 5,5 de Softr. Es la afirmación de que, para una aplicación empresarial definida por inicios de sesión, permisos y una larga cola de mantenimiento, una factura fija y un modelo de edición con poca maraña importan más que el control al píxel.
Cómo prever de verdad una factura de Bubble
Si Bubble sigue siendo la opción correcta, porque la aplicación realmente necesita su flexibilidad de diseño al píxel o una lógica personalizada profunda, hay que presupuestarlo como el servicio medido que es, no como un asiento SaaS de precio fijo.
- Presupueste el plan Growth, no el plan Starter, para cualquier aplicación con usuarios reales. 175.000 WU/mes parece mucho hasta que un puñado de flujos de trabajo complejos empiezan a operar con tráfico real.
- Audite la eficiencia de las búsquedas en los flujos de trabajo antes del lanzamiento, ya que las consultas a la base de datos no optimizadas son el factor más citado detrás de un consumo de WU descontrolado.
- Trate los niveles gratuito y Starter solo como presupuestos de prototipado. El límite de 200 registros en Free y el techo de WU en Starter son límites de demostración, no límites de producción.
- Tenga un plan para el escenario de impago. Una aplicación de pago puede revertir a los límites del nivel gratuito y caer si la cuenta no se mantiene al día, lo cual es una cuestión de continuidad del negocio, no solo de coste.
La comparación honesta
Bubble se gana con justicia su alta puntuación en flexibilidad de diseño: un editor al píxel y una lógica relacional profunda que pocas plataformas no-code igualan. Lo que no ofrece es una factura fija y predecible, y el precio por workload units es el mecanismo que convierte «hemos superado el plan Starter» en «no sabemos cuánto costará el próximo mes». Para un producto de consumo a medida o un MVP SaaS complejo donde ese techo de diseño es precisamente el objetivo, el coste medido es un intercambio justo. Para un portal de clientes, una herramienta interna o un CRM donde el diferenciador es la fiabilidad y un gasto predecible, Bubble vs Softr explica por qué la plataforma de precio fijo gana en los criterios que importan para esa clase de aplicación. Vea /methodology para saber cómo se construye cada puntuación de este sitio.