En corto
- Empezar con IA no fue un error: validaste rápido y barato. El problema llega después, cuando hay usuarios, datos personales y cobros reales.
- Los fallos se repiten: claves expuestas, base de datos sin reglas de acceso, sin permisos, sin copias de seguridad, sin pruebas y nadie sabe desplegar.
- Si guardas datos de personas y la base de datos está abierta, no es un bug pendiente. Es una brecha, y tiene consecuencias legales.
- Primero una auditoría cerrada de unos días, con informe ordenado por gravedad. El informe es tuyo, contrates la corrección o no.
- Se arregla por capas: lo que expone datos o dinero, luego el despliegue, luego los fallos diarios. Lo estético, al final.
- Si rehacerlo sale más barato que arreglarlo, lo digo el primer día en vez de facturar semanas de parcheo.
Mi app hecha con IA funciona en la demo pero se cae con usuarios reales
No es culpa tuya. Lovable, Bolt, v0, Replit o Cursor son buenísimos para llegar rápido a algo que se ve y se toca. Validaste la idea en un fin de semana en vez de gastarte meses y un presupuesto entero para descubrir que nadie la quería. Eso lo hiciste bien.
El problema aparece después. En la demo hay tres usuarios y los tres sois vosotros. En producción entra gente que se registra con datos reales, que paga, que sube documentos y que se equivoca de formas que nadie anticipó. Ahí se ve lo que falta, y casi nunca es funcionalidad: es todo lo que no se ve. Permisos, reglas de acceso a la base de datos, copias de seguridad, control de errores y un despliegue que no dependa de un botón dentro de una herramienta de pago.
Entro justo en ese punto. No para reescribirlo todo por gusto, sino para que aguante.
¿Qué falla normalmente en un proyecto generado con IA?
Los fallos suelen ser los mismos, y no son cosas exóticas: son las que una herramienta de generación no puede saber porque nadie se las dijo.
El más grave suele ser la base de datos. En muchos proyectos con Supabase o Firebase las tablas se crearon sin reglas de acceso, así que cualquiera que abra el navegador y mire las peticiones puede pedir la tabla entera de usuarios. No hace falta ser hacker. Hace falta pulsar F12.
El segundo es la lógica de negocio metida en el navegador. Si el precio, el descuento o el rol de administrador se deciden en el código que se descarga el cliente, se pueden cambiar. Un fallo habitual: el total del carrito viaja desde el navegador hasta el cobro sin que nadie lo recalcule en el servidor.
- Claves de API y credenciales dentro del código o visibles desde el navegador
- Base de datos sin reglas de acceso: cualquier usuario puede leer los datos de todos
- Sin control de quién puede hacer qué: un usuario normal llega a pantallas de administración
- Sin copias de seguridad ni forma de volver atrás si algo se borra
- Cero pruebas y dependencias sin actualizar desde hace meses
Si tienes datos de personas y la base de datos está abierta, eso es una brecha
Esta parte no es una opinión técnica, es un problema legal. Si tu aplicación guarda nombres, correos, teléfonos, direcciones, documentos o historial de compras, estás tratando datos personales. Y si esos datos se pueden leer desde fuera sin autorización, no es un fallo pendiente de arreglar: es un incidente de seguridad, y las obligaciones que genera son tuyas, no de la herramienta con la que se hizo.
Lo incómodo es que casi nunca te enteras. Nadie te avisa de que llevan seis meses descargándose tu tabla de clientes. Te enteras cuando alguien te lo cuenta, cuando aparece la lista en algún sitio, o cuando un cliente pregunta cómo es que le llega publicidad rarísima.
Por eso es lo primero que miro. Antes que el diseño, antes que los fallos y antes que el rendimiento. Un botón que no funciona molesta. Una base de datos abierta te puede costar el negocio.
Nadie sabe cómo desplegarlo, y eso bloquea todo lo demás
El proyecto existe, más o menos funciona, y no hay forma humana de subir un cambio. El desarrollador anterior lo desplegaba desde su portátil. O el proyecto vive dentro de una herramienta de la que nadie sabe cómo sacarlo. O hay tres versiones del código y nadie es capaz de decir cuál está online.
Cuando pasa esto, el proyecto no está parado por falta de ideas. Está parado porque tocarlo da miedo. Y con razón.
Lo primero que hago es recuperar el control: código en un repositorio que sea tuyo, claves y variables fuera del código, despliegue automático al confirmar un cambio y un entorno de pruebas separado del real para que puedas equivocarte sin romper nada.
A partir de ahí ya se puede trabajar. Antes de eso, cualquier mejora es una apuesta.
El desarrollador que lo hizo desapareció y no tengo ni el código
Ocurre más de lo que parece. La persona dejó de contestar, la empresa cerró, o la relación terminó mal. Y te quedas con una web o una aplicación en marcha de la que no controlas nada.
Lo primero es un inventario de qué es tuyo y qué no: dominio, hosting, repositorio, base de datos, correo, pasarela de pago y cuentas de las tiendas de aplicaciones. Muchas veces está casi todo a nombre de otro, y eso se resuelve antes de tocar una sola línea de código.
Si no aparece el código fuente, no siempre está todo perdido. Según cómo esté montado, se puede recuperar del servidor, del propio despliegue, o reconstruir la parte que de verdad importa. Y si no se puede, te lo decimos el primer día en vez de facturarte tres semanas de arqueología.
Cómo funciona el rescate: qué reviso y en qué orden lo arreglo
El orden no es negociable, porque arreglar lo bonito antes que lo urgente es tirar el dinero.
Empezamos con una auditoría cerrada de unos días. Revisamos el código, la base de datos, los permisos, las dependencias, cómo se despliega y qué datos personales hay dentro. De ahí sale un informe en castellano, sin jerga, con todo lo que está mal ordenado por gravedad y una estimación de esfuerzo para cada punto. Ese informe es tuyo, contrates la corrección o no.
Después se arregla por capas, y te voy contando lo que encuentro sobre la marcha. No hay sorpresas al final.
- Primero lo que expone datos o dinero: accesos, claves, reglas de base de datos y cobros
- Segundo lo que impide trabajar: despliegue, entornos, copias de seguridad y registro de errores
- Tercero lo que rompe a diario: los fallos que tus usuarios ya están sufriendo
- Cuarto lo estructural: reordenar lo que impide crecer y poner pruebas en lo crítico
- Y al final lo estético, que es justo lo que todo el mundo quiere primero
Qué te llevas cuando termino el rescate
El objetivo es que no dependas de mí. Si al terminar sigues atado a una sola persona, el trabajo está mal hecho.
Al cierre te entrego el código en un repositorio a tu nombre, con acceso de administrador para ti. El despliegue automatizado y documentado, con un documento corto que explique cómo se sube un cambio y qué hacer si algo se cae a las once de la noche. Las copias de seguridad configuradas y probadas, porque una copia que nunca se ha restaurado no es una copia. Un listado de todas las claves y servicios que usa el proyecto, con sus cuentas a tu nombre. Y la lista de lo que queda pendiente, priorizada, para que decidas tú cuándo lo abordas.
Si luego quieres que lo mantenga, se habla. Si prefieres llevártelo a otro, tendrás todo lo necesario para hacerlo sin pedirme permiso.
Cuándo no merece la pena rescatar y es mejor rehacerlo
No siempre sale a cuenta. Y preferimos decírtelo el primer día antes que cobrarte por mantener vivo algo que se va a morir igual.
Hay tres señales claras. Si el modelo de datos está tan mal planteado que cualquier cambio arrastra media aplicación, arreglarlo cuesta más que rehacerlo. Si el mismo código está duplicado en veinte sitios con pequeñas diferencias, cada corrección deja dos fallos nuevos detrás. Y si lo que hay en producción ni siquiera se parece a lo que pediste, no estás rescatando nada: estás pagando por terminar algo que nunca empezó bien.
El tamaño también cuenta. Una aplicación de cuatro pantallas suele salir más barata rehecha que auditada y parcheada.
Rehacer no significa tirarlo todo. Se conservan el diseño, los textos, los datos y las decisiones de producto, que es donde está tu trabajo de verdad. Lo que se tira es la fontanería.
Preguntas frecuentes
¿Se puede arreglar una aplicación hecha con Lovable, Bolt o v0 sin empezar de cero?+
Casi siempre sí. Lo que generan estas herramientas suele funcionar por fuera y fallar por dentro: permisos, reglas de base de datos, claves expuestas y despliegue. Auditamos el código, corregimos esos puntos por orden de gravedad y lo dejamos desplegado con copias de seguridad. Solo conviene rehacer cuando el modelo de datos está tan mal planteado que parchearlo cuesta más que rehacerlo.
¿Cómo sé si mi base de datos está abierta y cualquiera puede ver los datos de mis clientes?+
La señal más rápida: si tu aplicación habla directamente con Supabase o Firebase desde el navegador y nunca configuraste reglas de acceso o políticas por fila, está abierta. Cualquiera puede abrir las herramientas de desarrollo del navegador, copiar la petición y pedir la tabla completa. Se comprueba en minutos y, si hay datos personales dentro, es urgente.
¿Qué hago si mi web tiene una brecha de seguridad y guarda datos de personas?+
Primero cerrar el agujero: revocar las claves comprometidas, cortar el acceso público a la base de datos y forzar el cambio de contraseñas. Después documentar qué datos han podido verse y desde cuándo, revisando los registros del servidor. Y en paralelo, hablarlo con quien lleve tu protección de datos, porque una brecha tiene obligaciones de notificación con plazos cortos.
¿Cuánto cuesta rescatar un proyecto parado?+
Depende del tamaño y del estado, así que no doy cifras a ciegas. Lo que sí es fijo es el primer paso: una auditoría cerrada de unos días con un informe de todo lo que está mal, ordenado por gravedad y con estimación de esfuerzo por punto. Con ese informe en la mano decides si sigues, si lo llevas a otro sitio o si lo dejas.
¿Puedo recuperar mi proyecto si el desarrollador anterior no me da el código?+
A menudo sí, aunque depende de cómo esté montado. Antes de nada se hace inventario de dominio, hosting, repositorio, base de datos y pasarelas de pago, y ponemos todo a tu nombre. Si no aparece el código fuente, en bastantes casos se recupera del propio servidor o del despliegue. Si no es viable, te lo decimos el primer día.
¿Cuánto tarda un rescate de proyecto?+
La auditoría son unos días y el informe se entrega al terminarla. Las correcciones críticas de seguridad y de despliegue suelen resolverse en las primeras semanas de trabajo, porque son las que no pueden esperar. El resto se planifica por fases y lo decides tú con el informe delante. No trabajo con bolsas de horas abiertas sin final a la vista.
¿Trabajas solo en Cádiz o también en remoto para el resto de España?+
Trabajo desde Chiclana de la Frontera para toda España en remoto. Un rescate es de las cosas que mejor funcionan a distancia: hace falta acceso al código, a la base de datos y a las cuentas de despliegue, no estar en la misma oficina. Si prefieres alguna reunión presencial, en la provincia de Cádiz es posible.
Cuéntanos qué tienes y qué está roto
Escríbenos con dos cosas: qué hace el proyecto y con qué se hizo. Si tienes acceso al código o al panel de la base de datos, mejor todavía. Te decimos si merece la pena rescatarlo o rehacerlo antes de que gastes un euro más en parches.
Escríbenos y lo miramos