La checklist de producción que las apps hechas con IA suspenden (7 cosas que se rompen después de la demo)

Has creado una app con un app builder con IA, o la has construido a golpe de prompt, en plan vibe coding, durante unas cuantas tardes. Funciona. Pero fíjate en las condiciones en las que funciona: tu teléfono, tu Wi-Fi, tu cuenta, datos que tecleaste tú mismo, un build generado hace una hora. Una demo es una app probada exclusivamente en condiciones favorables.

Lista para producción significa lo contrario: la app sigue funcionando cuando las condiciones favorables desaparecen. Desconocidos en lugar de ti, un revisor en lugar de un público, meses en lugar de una tarde.

Ya hemos escrito sobre por qué existe esta brecha: nuestro artículo sobre los siete muros entre un prototipo y las tiendas cartografía la distancia estructural, y nuestra pieza sobre crear una app frente a gestionarla pone nombre al trabajo que empieza después del lanzamiento. Esos artículos terminan en preguntas que merece la pena hacerse. Este convierte las preguntas en experimentos: siete pruebas, cada una con un procedimiento concreto y una condición de superación indiscutible, todas ejecutables esta misma semana. Si una prueba te parece aburrida, esa es justo la idea. La producción es donde viven los bugs aburridos.

1. Un desconocido puede crear una cuenta, irse y volver

La demo nunca cierra sesión. Construiste la app ya autenticado, en un dispositivo que ya te conoce, así que toda la maquinaria de cuentas quedó sin probar: el email de confirmación que acaba en spam, el restablecimiento de contraseña que nunca llega, la sesión que muere en cada reinicio, la cuenta que existe en tu teléfono y en ningún otro sitio. Las cuentas son lo primero que toca un desconocido y lo último que prueba una demo.

La prueba: en un dispositivo que nunca haya visto tu app (el teléfono de un familiar sirve; para una app web, una ventana de navegación privada), crea una cuenta con una dirección de email que sea tuya pero que nunca hayas usado con ella. Confírmala. Cierra sesión. Restablece la contraseña. Vuelve a iniciar sesión. Cierra la app y vuelve al día siguiente.

Superada cuando: cada paso funciona sin que toques un dashboard, reenvíes nada a mano ni tengas que explicar un apaño.

2. La app sobrevive vacía, sin conexión y al doble toque

Tu demo corre sobre datos que tecleaste tú, con buena conexión, manejada por la única persona que sabe dónde no hay que hacer clic. Un usuario real empieza sin nada de eso: una cuenta recién creada ve cero contenido, el metro mata la conexión a mitad de una acción y un pulgar impaciente toca dos veces el botón de pagar. Son los estados aburridos, y las apps generadas tienden a no manejarlos, porque nadie los pidió en el prompt. Apple llega a ellos antes que tus usuarios: según la experiencia de nuestro equipo de publicación, durante la revisión es habitual que abran la app sin conexión, y lo que muestra sin red cuenta.

La prueba: instálala desde cero, o abre la app en una ventana privada, y úsala en modo avión; corta también la conexión a mitad de una acción. Después recorre todas las pantallas con una cuenta nueva que tenga cero datos. Después toca dos veces, rápido, cada botón que crea o paga algo. Mantén la parte de pagos en el modo de pruebas de tu proveedor, o usa un artículo barato que reembolsas justo después: lo que buscas es si aparecen dos pedidos, no si se movió dinero.

Superada cuando: ninguna pantalla en blanco, ningún spinner infinito, ningún crash y ningún pedido duplicado.

3. El App Store y Google Play la van a aceptar

Aquí es donde el resultado de tu builder se encuentra con el mundo exterior. Las tiendas quieren binarios nativos firmados, cuentas de desarrollador (99 USD al año en Apple, 25 USD en un pago único en Google), metadatos para las tiendas y declaraciones de privacidad que hace unos años no existían: la sección Data safety de Google Play es obligatoria desde julio de 2022, y los privacy manifests de Apple desde mayo de 2024. Muchas herramientas prompt-to-app generan aplicaciones web, porque una app web es lo que un prompt puede desplegar en un solo paso, así que este muro tiende a aparecer tarde. Una app web es una superficie legítima (GoodBarber entrega una Progressive Web App junto a las nativas), pero renuncia a la distribución de las tiendas y, para la mayoría de los usuarios de iOS, al push. Y luego llega la revisión: de los primeros envíos que gestionó nuestro equipo de publicación en los 12 meses hasta abril de 2026, aproximadamente el 42% volvió de Apple rechazado, y esa es la línea base de un equipo preparado, no un castigo para principiantes.

La prueba: tres preguntas, respondidas con nombres y no con suposiciones. ¿Puede tu herramienta producir binarios firmados para iOS y Android? ¿Tienes cuentas de desarrollador de Apple y de Google? ¿Puedes decir, hoy, qué datos recoge la app, dónde se almacenan y qué servicios de terceros los tocan?

Superada cuando: tres síes, por escrito, antes de reservar una fecha de lanzamiento.

4. Un push programado esta noche está mañana en la pantalla de bloqueo

El push es la razón por la que una app gana a una web en retención, y es también la funcionalidad que una demo finge mejor: todo parece conectado hasta el primer teléfono bloqueado. La entrega es binaria, y por eso esta prueba es un experimento de una noche y no una pregunta. Desde iOS 16.4 (marzo de 2023), iOS entrega el push web solo a las apps web que el usuario ha añadido deliberadamente a su pantalla de inicio; en el navegador, no suena nada. Así que una app web hecha con IA puede verse idéntica a una app nativa en tu pantalla y aun así quedarse muda en cuanto el teléfono se bloquea. Si ni siquiera encuentras dónde se programa una notificación push en tu herramienta, ya tienes la respuesta: la prueba ha fallado.

La prueba: programa una notificación push a tu propio teléfono para mañana a las 7:00 y bloquea el teléfono esta noche.

Superada cuando: el mensaje está en la pantalla de bloqueo cuando te despiertas.

5. Puedes nombrar cada servicio del que depende la app, y cada factura

Una app generada es una app ensamblada. Debajo de la demo hay un stack que el prompt eligió por ti: hosting aquí, una base de datos allá, un servicio de envío de emails, almacenamiento de imágenes, analíticas, quizá un procesador de pagos. Cada uno tiene un login, un plan gratuito que se acaba, claves que caducan y una factura que escala según su propia curva. La demo esconde todo esto porque, para un usuario durante una tarde, todo es gratis y todavía no se ha roto nada. La producción hace una pregunta más dura: cuando la app se cae a las 2 de la madrugada, ¿cuál de estos servicios revisas primero, y quién responde?

La prueba: escribe el inventario, empezando por donde alguien que no programa puede empezar de verdad: busca en tu bandeja de entrada todos los mensajes tipo “Welcome to” y “Verify your email” recibidos mientras construías, añade cada login que creaste por el camino, cada cargo recurrente en el extracto de tu tarjeta y lo que listen las páginas de integraciones y facturación de tu builder. Para cada línea: quién es el dueño de la cuenta, cuánto cuesta con 1.000 usuarios y si se renueva en silencio.

Superada cuando: cada línea tiene un dueño y un precio. Si redactar la lista te ha sorprendido, la sorpresa es el hallazgo.

Ese inventario te va a servir otra vez más adelante. Los servicios que aparecen en él son justo los que tendrías que reemplazar el día que quisieras cambiar de builder, y ahí es donde está de verdad el lock-in: lo desmontamos en ser dueño de tu app no es lo mismo que poder dejar tu app builder con IA.

6. Un cambio sale sin arrastrar todo lo demás

La primera actualización es la prueba más dura a la que se enfrenta una app hecha con IA, porque en el lanzamiento arrancan dos relojes. El primero es el tuyo: los usuarios encuentran bugs, y corregirlos por prompt puede reescribir en silencio partes que ya funcionaban, lo que llamamos regeneration drift (deriva de regeneración). En una base de código generada, el bucle de la etiqueta única tiene una forma particular: cambias la etiqueta, regeneras y descubres cuál de las pantallas que no tocaste cambió de todas formas. El segundo reloj pertenece a Apple y Google: cada uno publica una versión mayor de su sistema operativo al año, Google sube cada año la versión mínima de Android a la que una app debe apuntar, y Apple retira las apps que pasan tres años sin actualizarse y casi no registran descargas, tras un aviso de 90 días. Una app que no puedes cambiar con seguridad es una app que no puedes mantener publicada; escribimos lo que se rompe en silencio cuando una app deja de actualizarse para la versión a cámara lenta.

La prueba: cambia un detalle visible (una etiqueta, un precio, un color) y publícalo: como actualización en las tiendas si la app ya está publicada, o regenerando y redesplegando si no. Después verifica que tres cosas que funcionaban antes siguen funcionando.

Superada cuando: el cambio salió, los tres flujos re-probados siguen funcionando y el bucle completo te llevó una tarde, no una semana.

7. Alguien puede gestionar la app sin reabrir el builder

Dentro de seis meses, lo que la app necesita es operativo, no generativo: publicar el artículo de la semana, cambiar un precio, responder a un cliente, enviar el push de la promo, leer las cifras. Si cada una de esas cosas implica reabrir la herramienta que generó la app y volver a promptear con cuidado alrededor de lo que no debe romperse, la app tiene un punto único de fallo: tú, dentro del builder, para siempre. Una app es operable cuando sus tareas diarias viven en una interfaz construida para ellas, o pueden pasarse a otra persona: un compañero de equipo, o un agente de IA conectado a través de un protocolo abierto como MCP. Quién asume la parte de gestión del trabajo, y con qué herramienta, pesa más en el futuro de tu app que cualquier pantalla que hayas generado.

La prueba: haz la lista de las cinco tareas que tu app necesitará cada semana. Para cada una, di quién la hace y en qué herramienta.

Superada cuando: ninguna de las cinco respuestas es “yo, volviendo a promptear el builder y cruzando los dedos”.

Puntúala con honestidad. Siete pruebas superadas: anuncia el lanzamiento. Uno o dos fallos: ya sabes cuál es el trabajo de esta semana. Tres o más: lo que tienes es una idea validada, que es genuinamente valiosa, y merece unos cimientos construidos para la parte que viene ahora.

Esta es la razón por la que podemos publicar esta checklist sin pestañear: en GoodBarber, la mayor parte no es trabajo tuyo.

Las pruebas 1 y 2 vienen resueltas de fábrica. Las cuentas, las sesiones, el comportamiento sin conexión y los estados vacíos se entregan como componentes nativos, endurecidos a lo largo de los miles de apps en producción que aloja la plataforma, en lugar de generarse desde cero para la tuya. La prueba 3 es un servicio. GoodBarber compila binarios nativos de verdad, Swift para iOS y Kotlin para Android, más una Progressive Web App desde la misma configuración. Las declaraciones de privacidad que piden Apple y Google comparten su fuente de verdad con el propio build, las funcionalidades que activaste, así que la declaración y el binario no pueden divergir. Y si prefieres no enfrentarte solo a la revisión, el equipo de publicación que puede hacerse cargo de tu envío recuperó el 91% de los rechazos de Apple en el primer envío (seguimiento interno del equipo de publicación, 12 meses hasta abril de 2026).

La prueba 4 es infraestructura: el pipeline de push corre de punta a punta en la plataforma y mueve varios millones de notificaciones a la semana. La prueba 5 se reduce a una sola línea, porque el hosting, la base de datos, el CMS, el push, las analíticas y las pasarelas de pago viven en una sola suscripción, con un 0% de comisión de GoodBarber en las transacciones de e-commerce. Esa consolidación explica en buena parte que el coste total de propiedad quede en aproximadamente una décima parte del desarrollo a medida. Y la prueba 6 se absorbe aguas arriba: cuando Apple o Google mueven un requisito, GoodBarber lo parchea una vez, y tu siguiente actualización lo entrega.

La prueba 7 es donde la IA vuelve a entrar, esta vez en el lado correcto de la demo. Cada app GoodBarber puede ser operada por un agente de IA a través del servidor MCP de la plataforma: dile a tu asistente lo que necesitas, y el artículo sale, el push queda programado, el precio cambia y las cifras de la semana pasada vuelven en lenguaje llano, desde Claude, ChatGPT, Cursor o cualquier cliente compatible con MCP. La prueba 7 entera se convierte en una decisión de delegación. Y agent ready significa que la app puede ser operada por un agente, no que se gestiona sola: las reglas y la revisión final se quedan contigo.

El alcance de GoodBarber son las apps de contenido y el comercio móvil: no crea juegos, y un marketplace construido sobre mucha lógica a medida merece otra respuesta, que preferimos darte ahora. Dentro de ese alcance, esta checklist es lo que la plataforma está construida para sostener. En algún lugar del mundo, una app GoodBarber se descarga cada 4 segundos, y los clientes de pago de la plataforma están repartidos por 152 países. Ese es el resultado de superar estas pruebas, año tras año.

¿Qué significa “lista para producción” para una app móvil?

Una app lista para producción sobrevive a las tres cosas que una demo nunca contiene: usuarios reales, revisión real de las tiendas y tiempo real. En concreto: los desconocidos pueden crear cuentas sin ayuda, la app maneja los estados vacíos y sin conexión, las tiendas aceptan sus binarios firmados y sus declaraciones de privacidad, las notificaciones push se entregan, cada servicio de su stack tiene un dueño con nombre y apellidos, se puede actualizar sin romper lo que ya funciona y su operación semanal no depende de una sola persona.

¿Está mi app hecha con IA lista para producción?

Ejecuta siete pruebas: creación y recuperación de cuenta en un dispositivo que nunca haya visto la app, estados vacíos y sin conexión, envío a las tiendas con un binario nativo firmado, entrega de push en un teléfono bloqueado, un inventario con precios de cada servicio del stack, una actualización que no cambia nada más que lo que pretendía cambiar, y la operación semana a semana fuera del builder. Supera las siete y estás listo para anunciar. Los fallos más probables son el envío a las tiendas, el push y la primera actualización, porque muchos app builders con IA generan aplicaciones web en lugar de binarios nativos firmados, y la generación no cubre ni el cumplimiento de las tiendas ni el mantenimiento.

¿Puede una app hecha con IA pasar la revisión del App Store?

Solo como una app nativa de verdad. Apple exige binarios firmados, declaraciones de privacidad completas y una app que sea más que una web reempaquetada (Guideline 4.2). El rechazo es lo normal, no la excepción: Apple rechazó aproximadamente el 42% de los primeros envíos que gestionó el equipo de publicación de GoodBarber en los 12 meses hasta abril de 2026, y el 91% de esos rechazos acabó aceptado tras el trabajo de corrección.

¿Qué es lo primero que se rompe después de lanzar una app hecha con IA?

Las cosas aburridas, más o menos en este orden: la autenticación (emails de confirmación, restablecimientos de contraseña, sesiones muertas), luego los estados vacíos y sin conexión, luego la entrega del push, luego la primera actualización, donde corregir un bug por prompt puede reescribir partes que funcionaban. El patrón detrás de todas es el mismo: una demo se prueba en condiciones favorables, y la producción las va quitando una a una.

¿Necesito un desarrollador para mantener en marcha una app hecha con IA?

Si la app es código generado sobre un stack ensamblado, alguien tiene que ser el dueño de ese código y de ese stack, y eso es trabajo de desarrollador, puedas hacerlo tú o no. En una plataforma gestionada como GoodBarber, el equipo de ingeniería de la plataforma mantiene el código, el hosting, la infraestructura de push y el cumplimiento de las tiendas; tú operas la app desde un back office, o pasas las tareas del día a día a un agente de IA a través del servidor MCP. Te quedas con el papel de operador, no con el de ingeniero.

Siguiente paso: nada de lo que construiste se pierde. La demo zanjó la pregunta cara (si la idea merece una app) y tus pantallas son ahora la especificación. Empieza una prueba gratuita de GoodBarber, reconstruye la idea a partir de esa especificación y ejecuta esta misma checklist sobre el resultado: las seis primeras pruebas las carga la plataforma, y la séptima se resuelve con una frase a un agente.