Cuánto cuesta reconstruir una app de Bubble
Reconstruir una app de Bubble se cotiza por la lógica acumulada, no por la aplicación que se puede ver. Cuatro cosas definen el número: cuántos workflows y ramas existen, cuántas integraciones externas tocan, qué tan enredado quedó el modelo de datos y cuántas reglas de permiso por rol tienes. El conteo de pantallas casi no lo mueve.
¿Por qué nadie te da un número de entrada?
Porque el número no es conocible desde afuera, y un número dado sin inventario es una táctica de venta, no una estimación.
La documentación de Bubble explica el motivo. La plataforma afirma que las aplicaciones corren solo en la plataforma de Bubble y que no hay forma de exportar la aplicación como código. Así que la reconstrucción no es un port. Es reimplementar lógica de negocio que hoy solo existe dentro de un editor visual, y nadie la dimensiona mirando el frontend.
Vas a encontrar rangos de precio publicados por ahí. Trátalos como un presupuesto de obra dado por teléfono: los honestos vienen con la advertencia de que el rango es demasiado amplio para servir, y los seguros de sí mismos son los que deberían preocupar. Nosotros no publicamos un rango por esa razón, y cualquier estudio que te dé uno antes de contar tus workflows está cotizando un proyecto distinto al tuyo.
Lo que sí puedes conseguir rápido, y deberías exigir, es el inventario. Contar es barato. Adivinar es lo que sale caro después.
¿Qué define el precio de verdad?
Cuatro cosas, en orden aproximado de peso.
Workflows y sus ramas. Cada workflow es lógica que alguien tiene que leer, entender y reescribir, incluidas las ramas que solo se disparan en casos límite. El conteo de ramas importa más que el de workflows, porque en las ramas se esconde la regla de negocio no documentada.
Integraciones externas. Cada conexión de API carga su propia autenticación, manejo de errores, comportamiento de reintento y modos de falla. La integración también es donde se concentra el riesgo de la migración, porque a la otra parte no le importa que estés reconstruyendo.
Complejidad del modelo de datos. No la cantidad de tablas, sino cuánto del modelo es accidental. Listas que debieron ser relaciones, option sets que se volvieron tabla, campos que existen porque algún workflow necesitaba dónde guardar un valor. Desenredar eso es el trabajo de cola más larga, porque todo lo construido después hereda la decisión.
Reglas de permiso por rol. Las privacy rules son silenciosas y estructurales. También son lo que más probablemente se reproduzca mal, porque la intención original casi nunca está escrita en ninguna parte.
Fíjate en lo que no está en la lista. El conteo de pantallas, que es por donde empieza casi todo el mundo, se vuelve una tarea de diseño una vez resuelta la lógica, y el diseño es barato al lado de lógica que hay que razonar dos veces.
¿Cómo comparar con el costo de quedarse?
Pon los dos en la misma línea mensual, porque la reconstrucción es un número de una vez y quedarse es un número recurrente, y compararlos en unidades distintas es como la decisión termina postergada.
El costo de quedarse tiene una parte documentada y otra que no. La documentada es el workload: Bubble rastrea doce tipos de actividad que alimentan el total del mes, y el FAQ de precios fija el excedente base en USD 0,30 por cada 1.000 unidades sin suscripción de tier. Saca doce meses de eso y proyéctalo contra tu curva de crecimiento, no contra tu uso actual.
La parte no documentada es lo que la restricción le cuesta al negocio: la funcionalidad que nadie construyó porque saldría cara, el paso que siguió siendo manual, el reporte que se exporta y se termina en una hoja de cálculo. Ese número es mayor que la factura en la mayoría de las operaciones que vemos, y no aparece en ninguna factura.
Hay una tercera opción que suele saltarse, y muchas veces es el primer movimiento correcto. En la plataforma de Colo Saúde la aplicación se estabilizó en Bubble y su consumo se redujo en 60% antes de que empezara cualquier reconstrucción. Parte de una cuenta de workload es arquitectura y no plataforma, lo que significa que parte de la presión por migrar se elimina sin migrar. Comprar margen de tiempo así convierte la reconstrucción de emergencia en plan.
¿Cómo hacer el número más chico?
Borra primero. Los sistemas que crecieron dentro de un editor visual acumulan workflows que existen porque alguien los necesitó una vez, y la migración es el raro momento en que borrarlos es políticamente posible. Cada workflow que retiras es uno que no vas a estimar, construir, probar ni mantener.
Después secuencia por ingresos. Reconstruir la aplicación entera antes de entregar algo es el camino más caro y el de peor modo de falla. Haz el corte por workflow, empezando por los que el negocio necesita, y deja el resto corriendo donde está.
Después decide qué sigue simple. No toda parte de una operación merece software a medida, y una reconstrucción es un buen momento para notar qué herramienta interna podría ser una hoja de cálculo con reglas, o quedarse en la plataforma indefinidamente porque funciona y nadie la toca.
Estimar contra el inventario en vez de contra las pantallas es lo que separa un proyecto que aterriza de uno que se duplica. La secuencia para conducirlo está en migrar de Bubble a código propio.
Preguntas frecuentes
¿Pueden estimar mi reconstrucción viendo una demo de la aplicación?
No con honestidad. Una demo muestra las pantallas, y las pantallas son la parte barata. Una estimación necesita el conteo de workflows y ramas, la lista de integraciones, los tipos de dato con sus relaciones y las reglas de permiso por rol. Producir ese inventario suele llevar días, no semanas.
¿Reconstruir sale más barato que haber hecho a medida desde el principio?
En términos absolutos normalmente no, pero esa comparación ya no está disponible para ti. Lo que sí está disponible es reconstruir ahora contra reconstruir después, en un tamaño mayor, y después siempre sale más caro, porque la lógica se sigue acumulando mientras la decisión no sale.
¿Conviene arreglar la aplicación en Bubble antes?
Muchas veces sí, y es la opción menos discutida. Si la presión es el costo de workload, parte de esa cuenta viene de cómo se construyó la aplicación. Estabilizar compra margen de tiempo, y ese margen decide si la reconstrucción ocurre con calma o bajo un plazo fijado por una factura.
El siguiente paso
Si quieres el inventario antes de querer un número, el Diagnóstico de Arquitectura Operacional es una conversación de 30 minutos para mapear qué contiene de verdad tu aplicación y qué haría falta para moverla. Agenda una conversación.
Lee también
Cases relacionados
¿Reconociste tu operación en este artículo?
Agenda el Diagnóstico de Arquitectura Operacional: 30 minutos para mapear dónde está el cuello de botella de tu operación. Sin compromiso.
Agendar diagnóstico