Caso: migrar de no-code a nativa (el viaje real del cliente)

Una app hecha en no-code casi nunca se rompe de golpe. Se rompe como una acumulación lenta de parches, hasta que un martes cualquiera entra una incidencia que no se puede resolver sin reconstruir la pieza entera. Ese es el momento en el que migrar de no-code a nativa deja de ser una conversación futura y se convierte en un trimestre de trabajo. Aquí está la forma de ese viaje, a partir de las migraciones que hemos hecho. Los datos del cliente están anonimizados y las cifras son rangos en euros, no la factura de una empresa concreta, porque el patrón se repite mucho más de lo que sirve cualquier número aislado.

Qué significa realmente migrar de no-code a nativa

Migrar de no-code a nativa significa sacar un producto que ya funciona de una plataforma alojada como Bubble, Glide, Softr o Adalo y llevarlo a código propio, normalmente una app nativa o multiplataforma con un backend que controlas tú. El producto conserva su nombre, sus usuarios y sus datos. Cambia todo lo que hay debajo.

La distinción importa porque muchas fundadoras lo describen como “rehacer la app”, y entonces el comité oye “empezar de cero”. No estás empezando de cero. Estás conservando el comportamiento ya validado y sustituyendo la maquinaria que lo ejecuta. Lo valioso es el conocimiento sobre qué hacen tus usuarios. La plataforma solo era el andamio.

Las cuatro señales de que el no-code se ha quedado corto

En las migraciones que hemos ejecutado, el detonante casi siempre es una de estas cuatro cosas, y normalmente dos que llegan el mismo mes.

Rendimiento con carga real. Las plataformas no-code son generosas hasta que dejan de serlo. La app que iba instantánea con 400 usuarios tarda seis segundos en cargar un listado con 4.000. No hay un profiler que abrir ni una consulta que optimizar, porque la consulta no es tuya.

Una funcionalidad que la plataforma no hace. Sincronización en segundo plano, modo offline, integración con hardware, o un flujo de pago con Redsys o Bizum que el builder no soporta bien. El apaño existe, cuesta tres plugins y una cadena de automatizaciones, y se rompe cada vez que uno de ellos se actualiza.

Un coste que escala al revés. El precio por usuario o por registro es calderilla al principio y una partida seria después. Hemos visto facturas mensuales de plataforma superar lo que costaría hostear un código propio mantenido, lo cual invierte por completo la razón por la que se eligió no-code.

Alguien haciendo due diligence. Un inversor, un comprador o un cliente corporativo pregunta de quién es el código y dónde están los datos. “Está en Bubble” es una respuesta defendible en pre-seed y complicada en una ronda seria, sobre todo si el RGPD entra en la conversación.

Si ninguna de las cuatro te aplica, no migres. El no-code es la respuesta correcta para muchísimos productos, y la forma más rápida de quemar seis cifras es migrar por estética en vez de por necesidad.

Cuánto cuesta la migración en España

Este es el rango honesto de los proyectos que hemos presupuestado, con tarifas de estudio español para un producto que ya existe y tiene usuarios reales. El discovery es más corto que en un desarrollo desde cero, pero el trabajo de datos e integraciones pesa bastante más.

Hay dos cosas que sorprenden de estas cifras. La primera es que reconstruir suele salir más barato que el coste total de propiedad del no-code a tres años, una vez sumas cuotas de plataforma, licencias de plugins y el mantenimiento de los apaños. La segunda es que casi nunca sale más barato el primer año. Es una inversión que devuelve en un horizonte, y si la empresa no ve dieciocho meses por delante con cierta confianza, el momento no es este. Nuestro desglose de cuánto cuesta crear una app en España sitúa estos números frente a un desarrollo desde cero.

La parte difícil son los datos, no la app

Todas las migraciones que hemos hecho reparten el dolor igual. La app en sí se entiende bien, porque la versión no-code es una especificación viva. El equipo puede abrirla, usarla y saber exactamente qué construir. Ese trabajo es predecible.

Los datos no. Las plataformas no-code premian esquemas que crecen por sedimentación. Un campo llamado estado guarda siete significados distintos según el año en que se creó el registro. Relaciones que deberían ser claves foráneas viven como texto separado por comas porque en 2024 el builder lo puso fácil. La mitad de los registros tiene un campo que la otra mitad no tiene, porque se cambió un plugin a mitad de vida.

Presupuesta esto con honestidad. En una migración típica asumimos que entre una quinta parte y un tercio del esfuerzo total se va en extraer, limpiar, mapear y reconciliar datos, y en escribir los scripts que permiten repetir la migración, porque la vas a repetir más de dos veces. Los ensayos no son desperdicio. Son la forma de descubrir los siete significados de estado antes de que los descubran tus usuarias.

La segunda pieza infravalorada es el corte. Los usuarios tienen sesiones, estado guardado y expectativas. Una migración que obligue a todo el mundo a restablecer la contraseña un lunes por la mañana te va a costar un porcentaje medible de tu base activa. Planifica el corte como su propio flujo de trabajo, con su comunicación, no como la última línea del ticket de ingeniería. Si manejas datos personales, revisa además el impacto en tus registros de tratamiento antes de mover nada, algo que cubrimos en cómo cumplir el RGPD en una app española.

Qué haríamos distinto

Tres cosas, siempre las mismas.

Convivir más tiempo con los dos sistemas. El instinto pide un cambio limpio. El patrón seguro es un periodo en el que la app nativa está viva para un grupo mientras el no-code sigue sirviendo al resto, con los datos fluyendo en un solo sentido. Cuesta unas semanas más y elimina casi todo el riesgo de vuelta atrás.

Congelar el no-code pronto. Cada funcionalidad que entra en la plataforma antigua durante la migración es una funcionalidad que hay que construir dos veces. Acordar una fecha de congelación, y sostenerla, vale más que cualquier decisión técnica del proyecto.

Elegir el destino a conciencia, no por inercia. Nativa, multiplataforma y PWA son respuestas genuinamente distintas según lo que disparó la migración. Si el detonante fue el modo offline y el acceso a hardware, el campo se estrecha. Si fue el coste y la propiedad del código, no. Nuestra comparativa de nativa, híbrida y PWA es el argumento que repasamos con cada cliente antes de escribir una línea.

Dónde te deja esto

Migrar de no-code a nativa no es el fracaso de la decisión original. Elegir un builder para llegar a un producto funcionando con usuarios reales fue casi con seguridad lo correcto, y la migración es la factura de haber acertado. Los proyectos que salen mal son aquellos donde el detonante era difuso, la congelación nunca se sostuvo y los datos se trataron como una tarea en lugar de como un flujo de trabajo entero.

Si estás en algún punto de esto y quieres una segunda opinión sobre si el momento es el adecuado, cuéntanos tu proyecto con lo que has construido y por dónde está crujiendo. Te diremos con claridad si creemos que deberías quedarte donde estás.