Límites de Base44: ¿cuándo pasar a tu propio código?
Dónde encaja Base44 y dónde se queda corto: backend, acceso a datos, respaldos, créditos y control del código. Señales para migrar y opciones intermedias.
Read in English →
Base44 es un buen lugar para construir y operar una app mientras sea sobre todo pantallas, formularios y datos sencillos. Empieza a quedarse corto cuando tu negocio depende de cosas que la plataforma controla por ti: el backend y la base de datos corren en Base44, el código que exportas sigue hablando con ese backend, los respaldos automáticos solo vienen en los planes más altos y el uso se mide en créditos. El momento de planear la salida es cuando alguno de esos puntos empieza a costarte clientes, dinero o tranquilidad, no simplemente porque la app creció.
En esta guía te explicamos cómo está armada una app de Base44, los límites que más pesan en la práctica, las señales de que ya te quedó chico y las opciones que hay entre "quedarse" y "rehacer todo".
¿Cómo está construida una app de Base44?
Conocer las piezas ayuda a medir los límites. Según la documentación de Base44:
- El frontend es una app estándar de React construida con Vite. Puedes ver el código en la pestaña Code y, en los planes pagos, editarlo dentro de la app.
- Los datos viven en tablas de Base44 (llamadas entities), cada una definida por un esquema JSON.
- La lógica de backend corre como backend functions, escritas en TypeScript y ejecutadas en Deno, más automatizaciones que se disparan por horario o por eventos.
- El login, los correos, la subida de archivos y las llamadas a IA salen de los servicios integrados de Base44.
- Lo que conecta todo es el paquete
@base44/sdk, que el frontend usa para hablar con los servidores de Base44.
Ese último punto explica casi todo lo que sigue. Tu código de frontend se puede llevar a otro lado; los servicios que tiene detrás son de Base44.
¿Qué límites de Base44 pesan más en la práctica?
Trabajas los datos a través de Base44, no en una base propia
Ves y editas tus tablas en la página Data, exportas cada una como CSV y accedes a los datos desde el código mediante el SDK y las APIs. Para muchas apps alcanza. Se complica cuando necesitas reportes complejos que cruzan tablas, conectar una herramienta de BI directo a tus datos u operaciones masivas que serían más simples en SQL.
Los respaldos dependen de tu plan
Los registros borrados se pueden recuperar durante 30 días. Los respaldos automáticos con historial, descarga y restauración están en el plan Elite (7 días) y en los planes Business y Enterprise (30 días). En los demás planes, tu respaldo son las exportaciones CSV periódicas, y tienes que acordarte de hacerlas. Además, los usuarios de la app se guardan aparte de tus tablas y no entran en esos respaldos.
El uso se mide en créditos
Cada plan incluye créditos mensuales de mensajes (para construir con la IA) y créditos de integración. La documentación de Base44 indica que las operaciones de backend consumen créditos de integración. Con un uso estable es predecible, pero una función que de pronto se vuelve popular, o una automatización que corre más seguido de lo previsto, consume créditos más rápido.
El control del código tiene condiciones
La sincronización bidireccional con GitHub está disponible desde el plan Builder, y la rama por defecto del repositorio tiene que llamarse main. Una vez conectada, Base44 sincroniza los cambios automáticamente y ya no puedes usar Version History para volver a versiones anteriores a la conexión. Con la sincronización bidireccional, las entities se administran en Base44 y no se guardan en tu repositorio.
El código exportado sigue necesitando a Base44
Como el frontend usa el SDK de Base44, exportar el código no te da una app independiente. La CLI de Base44 tiene un comando eject que crea una copia separada de la app, pero su documentación aclara que la copia arranca con la base de datos vacía: los esquemas de las entities se copian, los datos no.
¿Cuáles son las señales de que es hora de migrar?
Cuenta cuántas de estas se cumplen en tu caso:
- Clientes o inversionistas preguntan dónde se guardan los datos, cómo se respaldan y quién tiene acceso, y las respuestas dependen de un plan que no tienes o de funciones que no puedes configurar.
- Perdiste datos, o estuviste a punto, y recuperarlos dependió de la suerte o de una exportación manual.
- El gasto en créditos es difícil de prever, y un mes con mucho movimiento implica subir de plan sin haberlo planeado.
- Las funciones que necesitas chocan una y otra vez con la plataforma, como permisos complejos, reportes pesados, integraciones específicas o una función concreta de base de datos, y cada una exige muchos prompts y parches.
- Se sumó un desarrollador que necesita ramas, revisión de código, pruebas automáticas y un entorno de pruebas con sus propios datos para trabajar a diario.
- La app es el negocio, y depender del backend de un solo proveedor es un riesgo que ahora prefieres manejar tú.
Una o dos de estas suelen significar "ajusta cómo usas Base44". Cuatro o más suelen significar que toca planear la migración.
¿Tengo que rehacerlo todo?
No. Entre quedarse y empezar de cero hay pasos intermedios:
| Opción | Qué implica | Conviene cuando |
|---|---|---|
| Quedarse y reforzar | Activar la sincronización con GitHub, programar exportaciones CSV, revisar permisos de datos | La app funciona y los riesgos son de red de seguridad |
| Subir de plan | Pasar a un plan con respaldos o con los controles que necesitas | Los límites son funciones del plan, no de la plataforma |
| Mover primero el frontend | Conservar el código React y cambiar de a poco las llamadas al SDK por tu propia API | La interfaz está bien y el problema es el backend |
| Migración completa | Backend y base nuevos, datos importados, usuarios migrados | Se cumplen varias de las señales a la vez |
El frontend en React muchas veces vale la pena conservarlo, porque es código estándar. Lo que se reconstruye es la capa que hoy da el SDK: base de datos, login, almacenamiento de archivos, correo y funciones. Una migración cuidadosa además conserva los IDs de los registros para que no se rompan los vínculos entre tablas, y define cómo van a entrar los usuarios en el sistema nuevo.
Antes de decidir, haz un inventario de tus entities, funciones, automatizaciones e integraciones, y exporta tus datos (en la guía para exportar los datos y el código de tu app de Base44 vemos cómo). Después compara el esfuerzo con honestidad. La guía sobre reescribir o arreglar tu app ayuda con esa decisión, y la de deuda técnica del vibe coding explica qué suele romperse cuando una app crece.
Respuestas rápidas
¿Una app de Base44 puede escalar? En muchos casos, sí. Los límites con los que choca la gente tienen menos que ver con el tráfico y más con el acceso a los datos, los respaldos, el costo en créditos y el control del código.
¿Puedo exportar mi app de Base44 y alojarla yo? Puedes obtener el código con la sincronización de GitHub o con el comando eject, pero el frontend exportado usa el SDK de Base44, y eject copia los esquemas, no los datos. Para que corra solo en lo tuyo hay que reemplazar el backend.
¿Base44 respalda mis datos? Los respaldos automáticos vienen con los planes Elite, Business y Enterprise. En cualquier plan, los registros borrados se pueden recuperar durante 30 días. Fuera de eso, exporta tus tablas como CSV con regularidad.
¿Sale más barato quedarse en Base44? Muchas veces sí, mientras la app es chica. Compara lo que gastas en créditos y plan con el costo de hosting, base de datos y horas de desarrollo de tu propia infraestructura.
¿No sabes si quedarte o irte?
La decisión es más fácil con alguien que ya leyó el código y el modelo de datos de la app. Nuestro servicio para arreglar apps de Base44 puede revisar dónde estás parado y qué implicaría una migración, y el equipo de desarrollo de software a medida puede llevarla a cabo si esa es la respuesta. Empieza por la revisión gratuita de tu app o cuéntanos de tu app.
