Entrega de apps creadas por IA: pasos claros para tomar el control con seguridad

¿Qué puede salir mal cuando te haces cargo de la app

La mayoría de las tomas de control fallan por razones aburridas: en realidad no tienes control. Un freelancer podría haber configurado todo con su correo personal, su cuenta en la nube o un espacio de trabajo temporal. Cuando desaparece (o se ocupa), pierdes acceso, y hasta los cambios pequeños se vuelven imposibles.

El código es el siguiente problema común. Puedes recibir un archivo zip, pero no el historial completo del repositorio, ni las configuraciones de entorno, ni los pasos exactos para construir y desplegar. Así es como terminas con una app que "funciona en su laptop" pero no puede reproducirse cuando necesitas arreglar un bug.

Las sorpresas en la facturación duelen porque llegan en silencio. Los prototipos creados con IA a menudo dependen de un montón de servicios de terceros: hosting, bases de datos, correo, almacenamiento de archivos, analíticas y una o más APIs de IA. Si esas cuentas quedan a nombre del freelancer, puedes quedarte sin acceso y seguir siendo cobrado. O la app se cae porque terminó una prueba o falló una tarjeta y nadie vio la alerta.

Los problemas de seguridad también son frecuentes, y el código generado por IA puede ser especialmente frágil aquí. A menudo encontrarás claves API hardcodeadas, autenticación débil, accesos administrativos demasiado amplios o atajos “temporales” que nunca se limpiaron. Cuando cambia la propiedad, esos atajos se convierten en riesgos reales.

Una entrega limpia de una app construida por IA es simple de describir: puedes iniciar sesión en todas partes, puedes reconstruir la app desde cero en una máquina nueva y puedes demostrar que lo que está en producción coincide con el código que tienes.

Al final de una buena entrega, deberías poder mostrar:

• Acceso de propietario a cada cuenta de la que depende la app (no contraseñas compartidas)
• Un inventario escrito de servicios, costes y quién los controla
• La base de código completa en un repo que posees, además del método de despliegue
• Prueba de que la app puede desplegarse otra vez (una compilación nueva y un despliegue exitoso)
• Una lista corta de problemas conocidos y riesgos a arreglar a continuación

Antes de empezar: acuerden alcance y tiempos

Una toma de control limpia comienza con un acuerdo: exactamente, ¿qué vas a recibir? Muchas “apps” son en realidad prototipos que funcionan bien en demos pero no están listas para usuarios reales. Si lo tratas como producción desde el día uno, te arriesgas a cortes, pérdida de datos y arreglos de emergencia.

Escribe el objetivo con palabras simples. ¿Quieres mantener la app actual funcionando tal cual durante un mes, lanzarla a usuarios de pago o usarla como punto de partida y reconstruirla? Cada meta cambia lo que necesitas del freelancer y cuánto tiempo reservar.

Fija una fecha clara de entrega y una breve ventana de soporte tras la fecha. Esa ventana sirve para responder preguntas, transferir cuentas y resolver problemas del tipo “solo funciona en mi máquina”. Ponle un límite para que no se convierta en una dependencia abierta.

Aunque la app esté desordenada, pide una lista escrita de sistemas. No es un juicio. Es para evitar sorpresas. Un documento simple o un mensaje está bien siempre que nombre cada servicio que podría bloquearte más adelante.

El acuerdo debe cubrir:

• En qué etapa está: prototipo, beta o lista para producción
• Qué significa “hecho”: login funcional, pagos, panel de admin, pasos de despliegue, etc.
• La fecha de entrega y la ventana de soporte (por ejemplo, 7-14 días)
• Una lista de sistemas usados: repo de código, hosting, base de datos, auth, correo, analíticas, APIs de IA
• Quién paga qué hasta que la transferencia esté completa

Ejemplo: planeas “lanzar la próxima semana”, pero el freelancer dice que la app es un prototipo y usa su propia cuenta en la nube y claves API. Eso no es aún un plan de lanzamiento. Es primero un plan de transferencia.

Haz un inventario de cada cuenta ligada a la app

Una toma de control limpia empieza con un entregable simple: una lista completa de cada cuenta de la que depende tu app. En una entrega de una app construida por IA, el código es solo la mitad de la historia. La otra mitad es el acceso.

Pon todo en una hoja de cálculo o documento con cuatro columnas: nombre del servicio, para qué se usa, quién lo posee (email y empresa) y cómo inicias sesión (SSO, contraseña, MFA, clave API). Si no puedes responder las cuatro, trátalo como un riesgo.

La mayoría de equipos pasan por alto al menos uno de estos grupos:

• Código y colaboración: propietario del repo, permisos de admin, cuentas de CI/CD, dónde viven docs/ issues
• Hosting y tráfico: login de la nube/PaaS, registrador de DNS, correo del dominio, acceso a la pipeline de despliegue
• Capa de datos: usuarios de base de datos, buckets de almacenamiento, connection strings, backups, permisos de restauración
• Tubería del producto: proveedor de email/SMS, pagos, analíticas, logging de errores, APIs de terceros
• Almacenamiento de secretos: dónde viven contraseñas y claves (vault, gestor de contraseñas o un .env)

Un ejemplo realista: un freelancer construyó tu prototipo en su GitHub, lo desplegó desde su cuenta personal de Vercel y conectó Stripe usando su propio correo. Todo funciona hasta que se desconecta y no puedes rotar claves ni cambiar facturación. Tu inventario debe hacer eso imposible.

Pide pruebas, no promesas. Para cada servicio, que el freelancer abra la página de administración y confirme propiedad, rol y contacto de facturación.

Recupera el control de los inicios de sesión sin romper la app

La mayoría de fracasos en entregas no son por el código. Son por la identidad: quién posee los buzones de correo, quién puede resetear contraseñas y qué credenciales “temporales” mantienen en realidad la producción viva.

Empieza moviendo cada cuenta crítica a correos que controles (idealmente tu dominio de empresa). Si la app está atada al Gmail del freelancer o a su gestor de contraseñas, aún no la posees. Trata la propiedad del email como la llave raíz.

Haz la toma de control en un orden seguro

Cambia lo menos posible hasta que puedas probar que aún tienes acceso. Una secuencia fiable se ve así:

• Añade primero tu email como admin u owner, luego confirma que puedes iniciar sesión y resetear contraseñas.
• Activa MFA (autenticación multifactor) para cuentas admin y configura opciones de recuperación a teléfonos y emails de respaldo que controles.
• Exporta y guarda credenciales en un gestor de contraseñas, no en chat o documentos compartidos.
• Rota contraseñas, claves API y secretos de webhooks solo después de verificar que la app sigue funcionando.
• Elimina el acceso del freelancer solo después de probar login, facturación y un deploy.

Un ejemplo simple: tu app usa Google OAuth y una base de datos gestionada. Si rotas el secreto del cliente OAuth antes de actualizar las variables de entorno en el hosting, los usuarios quedarán bloqueados. Si quitas al freelancer de la cuenta en la nube antes de añadir a tu propio admin, podrías perder la capacidad de reiniciar servicios o ver logs.

Tras la transferencia, rota secretos de forma controlada. Cambia una cosa, despliega y prueba el flujo principal (registro, inicio de sesión, pago si lo tienes).

Asegura la base de código completa y un build reproducible

Una entrega de una app construida por IA no es real hasta que puedes construir y ejecutar la app desde cero usando cuentas que controlas. Un zip rara vez basta. Quieres un repo completo, los pasos exactos de setup y prueba de que el código que recibiste coincide con lo que corre hoy en producción.

Primero, mete el código fuente en un repositorio versionado adecuado y asegúrate de que lo posees. Pide instrucciones de build que funcione en una máquina limpia, no solo “run npm install”. Las buenas entregas incluyen versiones fijadas (Node/Python), lock files y los scripts necesarios para migraciones y seeding de bases de datos.

Recopila la configuración de forma segura. Las variables de entorno y claves de servicio deben transferirse por un canal seguro y rotarse después de confirmar la toma. Si los secretos están hardcodeados en el código o compartidos en un documento, trátalos como comprometidos.

Solicita esto como un paquete:

• El repo completo con historial de commits (o historial exportado si hace falta)
• Pasos exactos para construir y ejecutar en local y staging
• Una lista completa de variables de entorno requeridas (con descripciones, no solo nombres)
• Una lista de herramientas de IA usadas (Lovable, Bolt, v0, Cursor, Replit) y cualquier prompt guardado
• El identificador de la versión desplegada (hash/tag de commit) para poder comparar

Luego verifícalo. Levanta una copia en staging y confirma que el código más reciente coincide con lo desplegado (mismo commit, misma forma de configuración, mismas migraciones aplicadas). Si no puedes reproducir el build, no tienes realmente la app.

Evita facturas sorpresa: facturación, límites de uso y cancelaciones

Un freelancer puede entregarte “la app” y aún así dejarte expuesto a cargos que no ves todavía. Antes de invitar a más usuarios, mapea cada servicio pagado a una función real del producto. Esa es la forma más rápida de evitar despertarte con una factura inesperada.

Empieza encontrando dónde puede escaparse dinero. Los culpables habituales son herramientas de pago por uso que siguen corriendo aunque el tráfico sea bajo: llamadas a APIs de IA, envíos de email/SMS, logging de alto volumen, crecimiento de la base de datos/almacenamiento y complementos de hosting.

Luego, confirma quién posee las cuentas de facturación y el método de pago. Si el freelancer es el propietario de la cuenta, puedes perder acceso durante una disputa, o pueden olvidar renovar una tarjeta y tumbar tu app. Traslada la facturación a una cuenta controlada por la empresa y mantén al menos dos admins.

Pon guardrails para que los errores no se vuelvan caros. Usa presupuestos y alertas donde sea posible. Si no hay topes duros, configura alertas múltiples (por ejemplo al 50%, 80% y 100% de tu objetivo mensual) y asegúrate de que lleguen a tu equipo.

Cancela con cuidado. No borres cosas “porque parecen sin uso” hasta confirmar que nada depende de ellas. Un patrón más seguro es pausar o bajar de plan primero, vigilar la app un día y luego eliminar.

Acciones rápidas que puedes hacer hoy:

• Exporta suscripciones y facturas de cada proveedor
• Empareja cada cargo con una funcionalidad que los usuarios puedan nombrar
• Activa alertas de presupuesto y emails diarios de uso
• Añade un segundo admin y transfiere la propiedad a tu empresa
• Pausa o baja de plan un servicio “sin uso”, luego monitoriza antes de eliminar

Revisión rápida de seguridad antes de permitir más usuarios

Antes de abrir la app a más usuarios, haz un repaso rápido de seguridad. El objetivo no es la perfección. Es detectar los problemas que pueden causar daño real en un día: claves filtradas, inicio de sesión falso y puertas de admin abiertas.

Empieza buscando secretos expuestos. Revisa el código, archivos de configuración, ajustes de despliegue y cualquier log de build o servidor al que tengas acceso. Si ves claves API, contraseñas de base de datos, secretos de clientes OAuth o tokens “temporales”, asume que están comprometidos y róta­los.

Luego verifica que la autenticación sea real. Muchos prototipos usan auth placeholder (o una bandera de “admin” hardcodeada) que parece suficiente en una demo. Confirma que:

• Los usuarios deben iniciar sesión para acceder a páginas y APIs privadas
• El acceso admin está limitado a cuentas específicas, no a un toggle en el frontend
• El restablecimiento de contraseña y la verificación de email (si se usan) no pueden abusarse
• Las sesiones expiran y los cierres de sesión revocan realmente el acceso
• No hay un /admin público o un panel de debug expuesto

A continuación, detecta riesgos comunes de fácil solución. Busca consultas SQL crudas construidas mediante concatenación (inyección SQL), subidas de archivos sin restricciones y endpoints que acepten input de usuario sin validación.

Finalmente, revisa quién puede acceder a los datos de usuarios. ¿Quién puede leer datos de producción (cuentas del freelancer, logins compartidos, dashboards de terceros)? ¿Están habilitados los backups y sabes dónde viven?

Una forma práctica de mantenerlo manejable es ordenar los hallazgos en tres buckets:

• Arreglar ahora: rotar secretos filtrados, endurecer admin, cerrar endpoints de debug públicos
• Arreglar pronto: añadir límites de tasa, reforzar validación, mejorar logging y alertas
• Arreglar después: afinar reglas de retención, flujos de exportación/borrado de datos, revisión completa de seguridad

Proceso paso a paso para una entrega limpia (simple y repetible)

Una entrega limpia de una app construida por IA es sobre todo control. Necesitas poseer las cuentas, el código y las claves, y debes probar que puedes desplegar sin el freelancer.

Empieza con una llamada corta compartiendo pantalla (30-45 minutos). Pide al freelancer que inicie sesión en vivo para que puedas ver dónde está todo alojado, qué servicios se usan y cuál es la cuenta real propietaria.

1. Congela los cambios por un día. Acordad una ventana corta donde no se envíen nuevas features. Esto evita la confusión de “iba bien ayer”.
2. Transfiere la propiedad, no solo el acceso. Mueve el repo de código, el proyecto en la nube, el registrador de dominios, DNS y el remitente de correo a cuentas que controles.
3. Captura secretos y luego róta­los. Copia variables de entorno, claves API, secretos de clientes OAuth, contraseñas de base de datos y claves de firma de webhooks en tu gestor de contraseñas. Tras confirmar que la app sigue funcionando, regenera y actualiza los valores.

Una vez que la propiedad y los secretos estén bajo tu control, haz un despliegue tú mismo. Ese despliegue es el momento en que dejas de depender de otra persona para mantener viva la app.

4. Crea primero una copia de staging. Clona la configuración de producción en un entorno de staging y despliega allí bajo tu cuenta. Arregla pasos de build o configuraciones faltantes antes de tocar producción.
5. Prueba solo los flujos que importan. Comprueba registro, inicio de sesión/restablecimiento, pagos (si los hay) y la funcionalidad principal de extremo a extremo con un usuario de prueba nuevo.

Termina removiendo accesos y anotando el estado final. Deshabilita las cuentas del freelancer, revoca tokens de acceso personales, quita claves SSH y guarda una nota corta: dónde está el repo, cómo desplegar, dónde están los secretos y quién posee la facturación.

Trampas comunes que causan pérdida de acceso y cortes

La app puede parecer “terminada” y aun así ser frágil. La mayoría de las interrupciones durante una toma de control ocurren porque la propiedad es confusa, el acceso está disperso o la app depende del portátil y contraseñas de una sola persona.

Una trampa común es que la app corre, pero nadie de tu equipo tiene acceso admin real a la cuenta en la nube. Puedes entrar a la app, pero no puedes cambiar variables de entorno, escalarla, ver logs o renovar certificados. La primera vez que algo falle, dependerás del freelancer.

Otra trampa es el código que falta. Los proyectos creados con IA suelen acabar repartidos en varios repos, copiados entre herramientas o solo almacenados localmente. Si no puedes sacar la base de código completa de un repo compartido y reconstruirla desde cero en una máquina nueva, no posees la app.

Estos problemas se repiten:

• DNS registrado en la cuenta del freelancer, así que un “pequeño” cambio se convierte en downtime cuando no se pueden actualizar registros rápido.
• Secretos compartidos en chat y luego reutilizados en varios servicios, de modo que un valor filtrado puede exponer todo el stack.
• Backups que existen de nombre: están antiguos, incompletos o nadie ha probado una restauración.
• La arquitectura es un espagueti, de modo que arreglos pequeños rompen partes no relacionadas.
• Las cuentas son personales (email del freelancer, tarjeta personal), lo que hace que renovaciones y cambios de facturación sean riesgosos.

Un ejemplo simple: tratas de apuntar el dominio a un nuevo host, pero el login de DNS está bloqueado en el buzón del freelancer. Mientras esperas, el servidor antiguo alcanza un límite y se cae.

Escenario de ejemplo: tomar el control de un prototipo de IA hecho por un freelancer

Maya es una fundadora en solitario. Pagó a un freelancer para construir un prototipo rápido en Replit (historia similar con Lovable). La demo se veía genial, pero cuando intenta mostrársela a usuarios reales, las cosas empiezan a tambalear.

La primera sorpresa: no hay una entrega limpia. El freelancer envía un zip y algunas capturas, pero la app solo funciona en su workspace. Cuando Maya intenta desplegarla, el build falla porque faltan variables de entorno clave. La connection string de la base de datos, la URL de callback de auth y la clave del proveedor de IA nunca se documentaron.

Luego viene la facturación. Maya revisa sus tarjetas y encuentra dos servicios cobrando por lo mismo: una instancia de base de datos sin uso y un segundo proyecto de hosting creado durante las pruebas. La factura de la API de IA también se dispara porque la app reintenta solicitudes fallidas en un bucle.

Una auditoría rápida muestra por qué el prototipo estaba bien para una demo pero era arriesgado para producción:

• La autenticación está parcialmente implementada, pero el restablecimiento de contraseña y las comprobaciones de sesión están rotas.
• Secretos están expuestos en un archivo de configuración que fue commiteado.
• El código duplica lógica en varios archivos, lo que hace que los cambios pequeños sean riesgosos.
• No hay un proceso de despliegue repetible, así que cada release se vuelve conjetura.

En este punto, Maya tiene dos caminos sensatos. Si la idea principal está probada y el código está cerca, primero estabiliza (asegurar secretos, arreglar auth, añadir un build reproducible) y luego refactoriza en pasos pequeños. Si la base es demasiado desordenada, reconstruye lo esencial y porta solo lo que vale la pena conservar.

Checklist rápido que puedes usar en 15 minutos

Usa esto como una comprobación rápida antes de dar por terminada la entrega. Una entrega limpia de una app construida por IA se reduce a propiedad, repetibilidad y saber qué puede costarte dinero mañana.

Propiedad y acceso

• Puedes iniciar sesión como owner/admin en el repo de código y añadir o quitar usuarios.
• Controlas el hosting y el dashboard de runtime con tu propia cuenta admin.
• Controlas el DNS y puedes cambiar registros sin pedirle al freelancer.
• Puedes acceder a la base de datos con un rol admin y sabes dónde está.
• La facturación de la nube y servicios de la app está a tu nombre, con un método de pago que controlas.

Si alguno de esos es “no”, pausa el trabajo de features. Arregla el acceso primero o te arriesgas a bloqueos y downtime.

Build, seguridad y coste

• Puedes desplegar desde el repo usando pasos escritos, sin el freelancer en una llamada.
• Los secretos de la app (claves API, tokens) están en un gestor de secretos o variables de entorno, no en código o logs de chat.
• Tras la transferencia, rotas las claves más sensibles (base de datos, auth, pago, envío de email).
• Existen backups y has probado una restauración al menos una vez (aunque sea en un entorno temporal).
• Tienes una lista simple de cada servicio pagado y qué impulsa la factura (usuarios, requests, almacenamiento, seats).

Escribe los cinco problemas principales para arreglar a continuación (por ejemplo: login roto, claves expuestas, errores en checkout). Esa lista corta evita que te disperses.

Siguientes pasos: estabiliza ahora y decide si reparar o reconstruir

Después de una toma de control, el objetivo es simple: asegúrate de poder ejecutar la app con seguridad hoy, y luego decide si vale la pena mejorar el código actual o empezar de cero donde más duele.

Estabilizar funciona cuando la app funciona mayormente, los cambios son pequeños y puedes enviar arreglos sin romper los flujos principales. Reconstruir tiene más sentido cuando cada cambio causa nuevos bugs, la estructura está enredada o los problemas de seguridad siguen apareciendo.

Señales de que reconstruir (o una reconstrucción parcial) es la opción más segura:

• No puedes explicar cómo funcionan auth, pagos o almacenamiento de datos tras leer el código
• Los despliegues son manuales y frágiles, y nadie puede reproducir el build de forma fiable
• Los secretos están esparcidos por archivos, logs de chat o dashboards
• Los arreglos básicos consumen horas porque un cambio rompe tres áreas distintas
• Los costes son impredecibles porque los límites de uso y la facturación son poco claros

Para evitar deriva, marca un plan de 7 días con resultados concretos:

• Día 1-2: asegurar la propiedad (acceso admin, MFA, gestor de contraseñas, emails de recuperación)
• Día 2-3: lograr un despliegue limpio que puedas repetir (pasos de build, vars de entorno, backups)
• Día 3-4: parchear riesgos de seguridad obvios (claves expuestas, queries inseguras, auth débil)
• Día 4-5: añadir controles de coste (propietarios de facturación, presupuestos, alertas, cancelar herramientas sin uso)
• Día 6-7: añadir monitorización básica (errores, checks de uptime y quién recibe las alertas)

Si heredaste un prototipo generado por IA que ya falla en producción, un equipo de remediación puede acortar la parte dolorosa. FixMyMess (fixmymess.ai) se centra en diagnosticar y reparar codebases creadas por IA: cosas como autenticación rota, secretos expuestos, refactorización y preparación de despliegue, para que puedas estabilizar rápido o reconstruir con un plan claro.