Migración de Bubble a código: ¿Cuándo, por qué y cuánto cuesta?

Una guía para equipos que dejan Bubble, construida alrededor de Claude Code y Codex. Esto es para fundadores y CEOs que construyeron un negocio en Bubble y están empezando a sentir las deficiencias de la plataforma.

En resumen

La migración es una decisión de negocio antes que técnica. Una aplicación Bubble real, con clientes de pago y flujos de trabajo, tarda unos meses en reconstruirse correctamente. Los equipos que han hecho esto citan de tres a cinco meses por aplicación, y no están inflando la estimación.

En cuanto al presupuesto, la mayoría de los equipos se sitúan entre $15k y $25k para una reconstrucción completa, dependiendo de las características y la complejidad de los datos. Si prefieres hacerlo tú mismo, le costará tiempo a tu equipo en lugar de dinero.

El beneficio de migrar es que eres dueño del código, la aplicación se vuelve más rápida y te vuelves financiable y adquirible de una manera que una aplicación Bubble nunca lo es del todo. Lo que asumes son las cosas que Bubble hacía silenciosamente por ti, como parches de seguridad, copias de seguridad y tiempo de actividad, que ahora son tuyas.

Pero con Claude Code y Codex, un equipo mucho más pequeño puede reconstruir lo que antes le tomaba a un equipo completo seis meses.

¿Deberías migrar de Bubble a código personalizado?

Bubble es bueno en muchas cosas. Puede llevar tu idea a usuarios de pago sin un equipo de desarrollo, pero hay un límite, y hay señales de que lo has alcanzado.

• El rendimiento de la aplicación disminuye a medida que crecen los usuarios
• Pequeños cambios pueden romper cosas que no tocaste
• Necesitas algo que Bubble no puede hacer, como procesamiento pesado en segundo plano
• Tu equipo dedica un tercio o la mitad de su tiempo a corregir errores en lugar de mejorar las cosas
• Los costos de las Unidades de Carga de Trabajo están aumentando, y escalar el uso lo empeora, no lo mejora

Pero el error que la gente comete aquí es tratar la migración como un todo o nada. No lo es.

Tienes algunas opciones antes de reconstruir completamente tu aplicación Bubble. Puedes reconstruir solo la parte que está realmente rota y dejar el resto en Bubble.

Uno de nuestros clientes tenía una aplicación Bubble bien gestionada que necesitaba un servicio WebSocket para gestionar una flota de neveras conectadas. No recomendamos una migración completa.

Un componente de backend personalizado que conectaba el hardware a la aplicación existente fue todo lo que necesitaron. Todo lo demás se mantuvo en Bubble.

Ese es el tipo de decisión que vale la pena tomar antes de comenzar a migrar tu aplicación Bubble. Ayudamos a los equipos con una auditoría de migración antes de comprometerse con una reconstrucción.

Si hay algo que Bubble no puede hacer, aún puedes construir esa característica con código y usar Bubble para todo lo demás.

Si el rendimiento y el costo están causando problemas, pero la aplicación funciona, planifica una reconstrucción completa en fases.

Si has llegado al límite en todas partes, como la recaudación de fondos, o quieres ser dueño del código fuente, planifica una migración completa.

Sin embargo, si aún estás encontrando el ajuste producto-mercado o la aplicación cambia semanalmente, quédate en Bubble. Migrar ahora es prematuro.

Lo que el código personalizado te da que Bubble no puede

Un error común es enmarcar el cambio como una forma de huir de los problemas de Bubble. Es correcto, pero incompleto.

Funciones en tiempo real (WebSockets)

Puedes crear paneles de control en vivo, edición colaborativa y notificaciones instantáneas. Los usuarios ven las actualizaciones inmediatamente sin actualizar la página, haciendo que la aplicación se sienta receptiva y moderna.

Acceso directo a modelos de IA/ML

Puedes integrar modelos de IA directamente en tu producto en lugar de depender de plugins restrictivos de terceros. Esto te da control total sobre la elección del modelo, el rendimiento, las capacidades y el costo.

Aplicaciones móviles verdaderamente nativas

Crea aplicaciones genuinas para iOS y Android con rendimiento nativo, integraciones de dispositivos y una experiencia de usuario pulida, en lugar de crear una aplicación web encapsulada.

Procesamiento en segundo plano

Puedes ejecutar trabajos de larga duración y computacionalmente intensivos de manera confiable en segundo plano sin estar limitado por cuotas de uso.

Optimización del rendimiento en subsegundos

Puedes optimizar las consultas de la base de datos, el almacenamiento en caché y la arquitectura de la aplicación para mejorar la experiencia del usuario.

Control total de la infraestructura

Elige tu proveedor de nube, estrategia de implementación y enfoque de escalado mientras cumples con tus requisitos de seguridad, cumplimiento y costos.

Sin precios por acción

Mantén los costos predecibles pagando por la infraestructura que usas en lugar de que se te cobre por cada ejecución de flujo de trabajo o acción del usuario.

Cómo se hace lo mismo en Bubble vs. en código

Añadir tablas y campos

Bubble: Crea un tipo de datos en la pestaña Datos y añade campos.

Código: Define un esquema de base de datos, y un agente de IA genera la migración.

Buscar o consultar datos

Bubble: Usa “Do a search for” con restricciones.

Código: Escribe una consulta usando SQL o un ORM, con el agente de IA generando la mayor parte de la implementación.

Reglas de negocio y flujos de trabajo

Bubble: Construye flujos de trabajo arrastrando acciones al lienzo de flujos de trabajo.

Código: Define funciones que se ejecutan en respuesta a eventos, con el agente de IA implementando la lógica.

Lógica condicional

Bubble: Añade condiciones “Only when” a las acciones.

Código: Usa sentencias if estándar y otras construcciones de programación.

Autenticación de usuario

Bubble: La autenticación está integrada y funciona de inmediato.

Código: Elige un proveedor de autenticación e intégralo en tu aplicación.

Carga de archivos

Bubble: Los archivos se cargan y almacenan automáticamente.

Código: Configura el almacenamiento de objetos e implementa el flujo de carga tú mismo.

Integración de API de terceros

Bubble: Conecta APIs usando el Conector de API sin escribir código.

Código: Realiza llamadas directas a la API, dándote control completo sobre las solicitudes, la autenticación y el manejo de errores.

Envío de correo electrónico

Bubble: Usa una acción incorporada o un plugin.

Código: Integra un servicio de correo electrónico y configura los ajustes de entregabilidad como SPF y DKIM.

Trabajos programados

Bubble: Usa “Schedule API Workflow”.

Código: Ejecuta tareas programadas con cron jobs o workers en segundo plano.

Control de acceso

Bubble: Configura las Reglas de Privacidad.

Código: Implementa seguridad a nivel de fila y autorización del lado del servidor.

Despliegue de cambios

Bubble: Haz clic en Preview o Deploy.

Código: Confirma los cambios en Git, deja que CI ejecute las pruebas y despliega a través de una pipeline de lanzamiento.

Depuración

Bubble: Recorre los flujos de trabajo usando el depurador.

Código: Inspecciona los registros, ejecuta pruebas automatizadas y reproduce los problemas localmente.

Control de versiones

Bubble: Confía en los puntos de guardado y el historial de versiones de Bubble.

Código: Usa Git para un historial de versiones completo, ramificación, revisiones de código y reversiones confiables.

Dónde fallan las migraciones de Bubble

Casi todos los errores costosos en una migración de Bubble provienen de un cambio de mentalidad necesario.

Los flujos de trabajo visuales se convierten en código

En Bubble, arrastrabas los pasos del flujo de trabajo. En código, la lógica reside en funciones que se ejecutan cuando algo sucede: un usuario hace clic, se activa una API o se dispara un temporizador.

La lógica es la misma. El “dónde lo veo” es completamente diferente, y eso es lo primero que confunde a la gente.

Tu base de datos de Bubble se convierte en una base de datos real

Los tipos de datos de Bubble se convierten en tablas. Los campos se convierten en columnas.

Ahora necesitas crear reglas. Un campo que se supone que debe contener un número rechazará texto. Bubble era fácil. Postgres no lo es, y la estrictez es tanto una característica como, durante la migración, un área donde ocurren muchos errores.

Las Reglas de Privacidad se convierten en algo que tienes que construir

En Bubble, las Reglas de Privacidad decidían quién podía ver qué. En código personalizado, nada está protegido hasta que escribes la protección. El estado predeterminado de una nueva aplicación es abierto. Cada regla que tenías en Bubble tiene que ser reconstruida. Si la omites, te vuelves propenso a una violación de datos.

Necesitas diferentes servicios para el frontend y el backend

Bubble agrupaba el frontend, el backend, la base de datos y el alojamiento en un solo editor. Con código personalizado, estos son servicios separados. Eso suena a más cosas que gestionar, y lo es, pero también es exactamente lo que permite que dos agentes de IA trabajen en diferentes partes simultáneamente.

Los plugins se convierten en paquetes y APIs

El plugin de Bubble que instalaste con un clic se convierte en una biblioteca o una API que llamas directamente. Esto significa más control y más fiabilidad, pero un poco más de configuración.

Preparación para la migración de tu aplicación Bubble

No hay un botón de “migración de aplicación con un solo clic” en Bubble. No puedes exportar tu HTML ni tus flujos de trabajo. Lo que sí puedes exportar son tus datos, e incluso eso tiene algunos desafíos.

La pestaña Datos te permite descargar cada tipo de datos como un CSV. Debido a que tienes acceso de editor, esto omite las Reglas de Privacidad, por lo que ves todo.

La API de Datos devuelve 100 registros por solicitud, lo que significa que necesitas paginación basada en cursor para obtener todo.

Luego está el problema de los archivos e imágenes. Cuando exportas un CSV, tus archivos e imágenes no están en él. Lo que hay son las URLs que apuntan a donde Bubble aloja esos archivos. Si migras sin transferir tus archivos, esas URLs dejarán de funcionar y los activos desaparecerán.

Los flujos de trabajo y la interfaz de usuario tienen que crearse desde cero porque ninguna de tu lógica se exporta. Alguien tiene que escribir lo que hace cada flujo de trabajo.

Esto es tedioso, y gran parte de tu tiempo se dedicará a esto. Pero el documento que estás produciendo es tu especificación. Es exactamente lo que construirán los agentes de IA.

Y audita tus Reglas de Privacidad ahora, antes de perder el acceso a ellas. Anota cada una de ellas, ya que definen todo tu modelo de autorización. Si está incompleto, a tu nueva aplicación le faltarán reglas de seguridad que no sabías que tenías.

Alojamiento de medios y archivos

Cada vez que un usuario subía una foto de perfil o un PDF a tu aplicación Bubble, Bubble lo almacenaba en AWS y devolvía una URL para ello. En código personalizado, eliges S3 o Cloudflare R2, y tienes que crear la pipeline para ello.

La migración en sí tiene un orden de operaciones específico, y equivocarse resultará en una pérdida permanente de datos.

Primero, exporta tus datos, recordando que obtienes URLs, no archivos. Luego ejecuta un script que descargue cada archivo de cada URL antes de que el alojamiento de Bubble desaparezca. Luego vuelve a subir todo a tu nuevo almacenamiento. Y por último, reescribe cada URL almacenada en tu base de datos para que apunte a la nueva ubicación.

1. 1 Exportar datos (URLs, no archivos) →
2. 2 Descargar cada archivo →
3. 3 Volver a subir al nuevo almacenamiento →
4. 4 Reescribir las URLs almacenadas

Algunas URLs de Bubble están firmadas y caducan, por lo que tienes que decidir qué archivos son públicos y cuáles son privados. Y Bubble usaba una CDN para servir archivos rápidamente en todo el mundo, mientras aplicaba reglas de tamaño de archivo y acceso. Todo eso ahora es tuyo para configurar.

Nada de esto es difícil de forma aislada. El problema es no saber que existía hasta que un usuario informa que sus archivos han desaparecido.

Limpieza de datos

Alguien que nunca ha migrado una aplicación antes no considerará esto un desafío importante.

La base de datos de Bubble es simple. Los campos pueden estar vacíos cuando no deberían. Un campo puede contener un número para 9,000 registros y texto para los otros 12. Las relaciones entre cosas se almacenan por referencia y se desincronizan a lo largo de años de uso real. Nada de esto causó problemas obvios en Bubble, porque Bubble no imponía la estrictez.

Luego te mueves a Supabase o Xano, y la importación falla. Porque tus datos violan las reglas.

Valores nulos donde se requiere un valor. Referencias huérfanas que apuntan a registros que fueron eliminados. Correos electrónicos duplicados en un campo que se supone que es único. Fechas almacenadas en tres formatos diferentes.

Tus Option sets se exportan como IDs o texto de visualización, no como claves foráneas, lo que dificulta vincularlos a los datos relacionales adecuados.

Bubble exportará “cosas” vinculadas como IDs de referencia, no como las relaciones legibles que ves en el editor, y reconstruir cómo todo se conecta requiere mucho trabajo.

El tiempo que dediques a limpiar, desduplicar y conciliar los datos exportados de Bubble siempre superará el tiempo dedicado a escribir la importación en sí.

Manejo de la autenticación de usuarios y migración de cuentas

Bubble no te permitirá exportar los hashes de las contraseñas de tus usuarios. Es bueno que sean difíciles de extraer. Pero significa que no puedes simplemente mover las contraseñas de tus usuarios a un nuevo sistema y hacer que todos inicien sesión como si nada hubiera cambiado.

La primera solución es un restablecimiento de contraseña forzado. Todos se mueven a la vez. En el momento del cambio, cada usuario tiene que restablecer su contraseña, y tú les envías un enlace de restablecimiento por correo electrónico. La ventaja es un cambio limpio, simple y todo a la vez. Para las empresas a las que ayudamos a migrar, elegimos una ventana de bajo tráfico como un fin de semana.

La segunda es la migración por goteo. Mantienes el nuevo sistema de autenticación junto con el antiguo. La primera vez que cada usuario inicia sesión después del cambio, el nuevo sistema verifica sus credenciales contra el antiguo sistema de Bubble una vez, luego almacena la contraseña. A partir de entonces, están completamente migrados.

Para la mayoría de las aplicaciones con menos de unos pocos miles de usuarios, un restablecimiento forzado es más simple y vale la pena la pequeña fricción. Usa el enfoque de goteo cuando un restablecimiento forzado te costaría usuarios o cuando el tiempo de inactividad es costoso.

Más allá de las contraseñas, aún necesitas migrar todo lo demás sobre tus usuarios. Perfiles, roles, permisos, todo se mueve como datos.

Algunas cosas más a planificar: todas las sesiones activas se invalidan en el momento del cambio, por lo que todos cierran sesión una vez; los inicios de sesión sociales como Google tienen que volver a vincularse; y cualquier configuración multifactor tiene que volver a registrarse.

Puedes elegir entre un proveedor de autenticación gestionado como Auth0 o Clerk que se encarga de las partes difíciles por una tarifa, o una biblioteca de autenticación que ejecutas tú mismo con más control y responsabilidad.

Siempre recomiendo pagar por un proveedor gestionado a menos que tengas una razón específica para no hacerlo. La autenticación es una de esas áreas donde el costo de equivocarse ligeramente es muy alto.

Seguridad de los datos

En Bubble, la seguridad ocurría en su mayor parte, pensaras en ella o no. En código, el estado predeterminado de tu aplicación es desprotegido, y cada capa de seguridad es algo que añades deliberadamente.

Cada Regla de Privacidad de Bubble tiene que ser reconstruida como lógica real del lado del servidor, a menudo con seguridad a nivel de fila en la base de datos.

La gestión de secretos es el siguiente paso. Los secretos como las claves API deben estar en variables de entorno del lado del servidor.

Cuando el framework sobre el que construiste lanza una actualización de seguridad, depende de ti aplicarla. Bubble hacía esto por ti en segundo plano. Además, ahora eres dueño del cifrado en tránsito y en reposo, en su mayoría manejado por buenos valores predeterminados y tus elecciones de alojamiento, pero ahora es tu responsabilidad confirmar en lugar de asumir, y la validación de entrada, porque tus propios puntos finales de API están expuestos al mundo y tienen que defenderse contra entradas incorrectas.

La seguridad de los datos es una de las razones por las que hacerlo solo, sin nadie que lo haya hecho antes, puede salir mal de forma silenciosa y costosa.

Lo que Bubble hacía por ti en silencio

Ya debería estar claro que Bubble hacía muchas cosas por ti. Pero también puedes hacer lo mismo siempre que sepas lo que necesitas hacer por tu cuenta.

La razón para enumerarlos no es para asustarte. Es para que “necesitamos configurar copias de seguridad” sea algo que hayas planeado.

Elegir la pila tecnológica

Puedes elegir React, Next.js o cualquier otro framework frontend. Todos los agentes de IA conocen todos los frameworks.

Con los agentes de IA escribiendo la mayor parte del código, el costo de una determinada elección de pila es menor de lo que solía ser. Aunque los LLM tienden a favorecer y son buenos en React y Next.js.

Qué migrar primero

Siempre debes centrarte en el backend. Tu base de datos, tu autenticación y tu API principal son la base sobre la que se construye todo.

Construirlos primero te permite confirmar que tus datos están intactos. Si tengo que recomendar un LLM para esto, elige Codex. Es bueno en operaciones de backend y de datos pesados.

Centrarse primero en el frontend funciona cuando la interfaz de usuario es el problema, y puedes conectar un nuevo frontend a la API de datos existente de Bubble. Puedes empezar a reemplazar la aplicación módulo por módulo mientras Bubble sirve como backend.

Recomiendo trabajar en la migración módulo por módulo. Elige un solo módulo y constrúyelo completamente, base de datos, API e interfaz de usuario, de arriba a abajo.

De esta manera, aprenderás mucho sobre dónde te equivocaste, porque lo harás, antes de haberte comprometido a migrar todo.

Sea cual sea el que elijas, selecciona tu primer módulo con la misma lógica: las dependencias más bajas.

Traza qué otros módulos dependen de él antes de empezar. Deja el módulo más interconectado para cuando los cimientos sean sólidos.

Saltar a la tarea más difícil primero te causará problemas.

Construyendo el frontend y un sistema de diseño

Si empiezas a construir páginas sin un sistema, obtendrás lo que todo el mundo reconoce como una aplicación generada por IA.

La solución es un sistema de diseño. Esto significa tus colores, espaciado y tipografía. Luego, los componentes se construyen a partir de esos tokens, los botones, tarjetas e inputs. Después, las páginas se ensamblan a partir de componentes.

Si lo construyes en ese orden, la consistencia es automática. Pero si construyes las páginas primero, tu aplicación nunca se verá consistente.

Si tienes diseños en Figma, puedes conectar Figma directamente a Claude Code y Codex, para que el agente construya la interfaz de usuario.

Claude es mejor que Codex cuando se trata de frontend. Haz que el agente tome una captura de pantalla de lo que construyó usando Playwright, y revísala. Esto mejora drásticamente la salida en la interfaz de usuario.

Alejarse del aspecto predeterminado se trata principalmente de experiencia, en lugar de aceptar lo primero que construye el agente de IA. Aquí es donde tener a alguien con buen gusto marca la diferencia entre “parece una plantilla” y “parece un producto”.

Construyendo el backend y la lógica

La construcción del backend es principalmente un ejercicio de traducción de la documentación que produjiste anteriormente. Cada flujo de trabajo de Bubble ahora será un endpoint de API.

Primero, vuelve a implementar las Reglas de Privacidad. Cada regla que auditaste anteriormente se convierte en lógica del lado del servidor y seguridad a nivel de fila. No dejes que el agente te asegure que “añadió seguridad”. Verifica que cada regla específica de tu auditoría existe y funciona. Los agentes a veces afirmarán que algo funciona cuando no es así.

Segundo, inicia la migración de datos. Importa los datos limpios al nuevo esquema, ejecuta el proceso de re-alojamiento de archivos y luego valida que los recuentos de registros coincidan. Cuenta los registros en el sistema antiguo, cuéntalos en el nuevo y confirma que coinciden.

Y por último, mueve el trabajo programado y en segundo plano. Los flujos de trabajo de API programados de Bubble deben convertirse en cron jobs o workers de cola.

Configurando una base de código en la que los agentes LLM puedan trabajar

Probablemente usarás Claude Code o Codex para ayudar con la migración. Si no, te recomiendo encarecidamente que lo hagas, y necesitas hacer algunas cosas para asegurar que los agentes sean efectivos.

CLAUDE.md es un archivo donde escribes instrucciones y reglas para Claude Code. Funciona como una guía que le dice a Claude cómo opera tu proyecto, qué estándares de codificación seguir y qué quieres que recuerde sobre tus preferencias.

Se carga al inicio de cada sesión y ayuda a Claude a tomar mejores decisiones sobre tu código. Divide las reglas específicas del dominio en archivos separados que se cargan solo cuando son relevantes.

Luego, estructura el repositorio para que el frontend y el backend estén separados, porque hará posible agentes paralelos. Si los límites son claros, dos agentes pueden trabajar sin pisarse.

La documentación que creaste anteriormente ahora se convierte en tus requisitos de producto, divididos en pequeñas y completas secciones verticales.

Usa Git desde el primer día. Te ayudará a crear ramas y commits, y a retener el historial completo. Esta es tu red de seguridad. Cuando un agente hace un cambio que no te gusta, git es la forma de deshacerlo limpiamente.

Los LLM mejoran cada día, pero aún cometen errores. Sin control de versiones, estás poniendo en riesgo todo tu proyecto.

Claude Code es bueno en trabajo de frontend y UI. Codex es bueno en trabajo de backend pesado y bases de datos. Así que la división más fácil es a lo largo de las tareas de frontend-backend.

Y construye con un agente (Claude o Codex), luego haz que el otro haga una revisión adversaria del resultado. El modo de revisión de Codex es bueno para esto. Un agente escribe, el otro lo revisa, y obtienes un código mejor del que cualquiera produciría solo.

Mantén los contextos separados. No des a ambos agentes la misma información. Enfoca a cada agente en su área específica para mejorar el rendimiento. Un agente de backend no necesita conocer tus reglas CSS.

Puedes ejecutar ambos agentes a la vez usando una terminal que se divide en paneles, con tmux o zellij, o apuntando cada agente a un directorio separado, o con git worktrees, que permiten a los agentes trabajar sin conflictos de fusión.

Mantén una lista de tareas compartida y marca explícitamente las dependencias, para que un agente no empiece un trabajo que depende de algo que el otro no ha terminado. Revisa el estado de git constantemente. Revisa los cambios antes de que se confirmen. Y nunca dejes que dos agentes editen los mismos archivos simultáneamente.

La calidad sufrirá si las tareas no están claramente definidas. Si das a los agentes tareas poco claras, podrían asumir roles superpuestos y terminar creando partes que no funcionan bien juntas. Así que siempre da tareas específicas y bien definidas.

Añadiendo puertas de calidad

Necesitas una red de seguridad que se ejecute para cada cambio que hagan los agentes LLM, sin que nadie tenga que recordar activarla. Eso es lo que son estas puertas.

Los hooks de pre-commit se ejecutan automáticamente antes de que se confirme cualquier código. Formateadores, linters, escáneres de secretos para que una clave API nunca se confirme por accidente, y pruebas básicas.

Puedes automatizar las comprobaciones de corrección para que ocurran antes de que el código llegue a la revisión. La configuración de linting y formato da a los agentes un estilo consistente a seguir, lo que mantiene la base de código legible incluso cuando diferentes agentes escribieron diferentes partes.

La integración continua asegura que tu código cumple con la definición de “hecho” al asegurarse de que es ejecutable. Si las pruebas deben pasar antes del despliegue, se elimina el problema de “funciona en mi máquina”, ya que CI ejecutará las mismas comprobaciones cada vez.

Siempre prueba la salida de los agentes antes de enviarla a producción. Revisar es más rápido que volver a ejecutar todo tú mismo, y funciona incluso para sesiones que no estabas viendo. Mejor aún, haz que un segundo agente con un contexto fresco intente encontrar lagunas en el trabajo del primer agente. El agente que hizo el trabajo no debería ser el que lo califique.

Dónde fallan los agentes de IA

Todo el mundo está promocionando la codificación con IA. Son excelentes para generar código rápidamente, trabajar en muchos archivos, manejar tareas bien definidas y seguir convenciones claras. Úsalos para todo eso. Pero no dependas de ellos para la lógica de negocio.

Pueden tener errores pequeños y fáciles de pasar por alto, y las pruebas mal diseñadas pueden no identificarlos. También tienen una tendencia a afirmar que las medidas de protección están en su lugar, como decir que se añadió una regla de autorización cuando no fue así, o que existe una Regla de Privacidad cuando no hay ninguna.

Si no revisas y compartes comentarios, preferirían usar la biblioteca conveniente, no la correcta, porque un agente de IA optimiza para completar la tarea en lugar de para la mejor elección a largo plazo.

Los agentes de IA te ayudan a migrar aplicaciones Bubble. No reemplazan el saber cómo se ve lo correcto. Un equipo que entiende cómo se ve “lo correcto” trabaja mucho más rápido. Un equipo que no lo entiende terminará rápidamente con una aplicación rota y poco confiable.

Mucha gente te dirá que simplemente contrates una agencia en este punto. Solo diré que la brecha entre un agente de IA rápido y saber cuándo algo anda mal es la razón por la que tener ayuda experimentada vale la pena. Ya sea nosotros o alguien más, no dejes que los agentes sean quienes califiquen su propio trabajo.

¿Quién lo mantiene después del lanzamiento?

Una vez que hayas migrado, ahora necesitas mantenerlo. Puedes contratar a un ingeniero, retener a la agencia que lo construyó, o usar Claude o Codex si el producto es simple. Cualquiera de estas opciones está bien.

Costo de ejecutar una aplicación Bubble vs. código

Tu antigua factura de Bubble era simple. Plan de Bubble, más recargos por Unidades de Carga de Trabajo cuando el uso se disparaba. Pero ahora tu nueva factura tiene un par de proveedores más. Alojamiento, una base de datos, almacenamiento de objetos para archivos, un proveedor de autenticación, un servicio de correo electrónico, monitoreo y un dominio.

Al principio, tus costos aumentan. Pero a medida que tu aplicación crece, se vuelve más barata que Bubble, especialmente para aplicaciones de alto uso. La recompensa no son solo costos mensuales más bajos. Terminas con una aplicación más rápida y un activo que posees por completo.

Dónde falla la migración de Bubble

Esta lista parecerá excesiva hasta que te suceda una de estas cosas.

• Creer que hay una exportación con un solo clic de Bubble a código. No la hay, y planificar en torno a una desperdicia semanas.
• Olvidar que los archivos exportados son solo URLs, y perder todos los activos cuando el alojamiento de Bubble caduca.
• Extraer una tabla grande a través de la API de Datos en una sola solicitud y obtener silenciosamente solo 100 registros.
• Intentar migrar hashes de contraseñas que no puedes exportar, en lugar de planificar una estrategia de restablecimiento o goteo.
• No volver a implementar las Reglas de Privacidad, dejando los datos de la nueva aplicación completamente expuestos.
• Amontonar todo en un gigantesco CLAUDE.md.
• Dar a los agentes indicaciones vagas como “construir un panel de control”.
• Dejar que los agentes hagan grandes reescrituras de varios archivos de una sola vez. Haz pequeños cambios.
• Dos agentes editando los mismos archivos a la vez.
• Confiar en un agente que algo funciona en lugar de comprobarlo tú mismo.
• No dedicar una semana a la limpieza de datos.
• Olvidar que ahora eres dueño de las copias de seguridad, los parches y el tiempo de actividad.
• Realizar el cambio sin un plan de reversión.