Qué pasa después de hacer una app con vibe coding: la mañana en que deja de ser una demo y el go/no-go que viene después

Nadie decide llevar a producción una app hecha con vibe coding. Lo decide producción por ti, una mañana que no has elegido: paga el primer desconocido, se da de alta una segunda empresa o el departamento de compras de un cliente te manda un cuestionario de seguridad. A partir de esa mañana la app ya no es una demo, diga lo que diga el código.

Escribo esto desde el asiento que recibe la llamada unas semanas más tarde. En Conectia nos hacemos cargo de apps construidas con Claude Code, Cursor, Lovable, v0, Bolt y Replit y las ponemos a funcionar con clientes de verdad; antes pasé años en DevOps y en respuesta a incidentes en entornos corporativos, y mi parte en estos encargos son las dos primeras semanas: leer lo que hay y dejar por escrito qué hacer con ello. Esto no es un tutorial para llevar una app de Cursor a producción. Ya he escrito dónde se rompe un MVP hecho con IA y cómo audito una app de Lovable sobre Supabase. Este post va de la decisión: qué pasa cuando la demo deja de ser una demo, y cómo se llega a un veredicto que puedas comprobar en lugar de creer.

La pregunta nunca es «si el código es bueno». La pregunta es «qué módulos aguantan a un usuario que paga, y con qué evidencia».

La app deja de ser una demo una de estas tres mañanas

El fundador casi nunca se da cuenta del momento. La app, sí. Hay tres hechos que convierten un prototipo en una obligación, y cada uno cambia lo que significa el mismo código.

El primer usuario que paga. Mientras no se mueve dinero, un bug es un bug. Después, ese mismo bug es una devolución, una disputa con la tarjeta o un cliente que se va y se lo cuenta a tres más. El pago añade además la única parte de la app que mueve el sistema de otro: el webhook. El proveedor reintenta, el evento llega dos veces o no llega, y tu código se ejecuta en el orden que haya decidido la red. Una demo nunca pasa por ese camino, porque pulsaste «pagar» una vez y viste que funcionaba.

El segundo cliente. Los datos del primer cliente vivían en unas tablas que eran, en la práctica, suyas. Los del segundo caen en las mismas tablas, y quién puede leer qué deja de ser una cuestión teórica. En una app de Lovable la respuesta son unas políticas de Postgres que quien la construyó puede haber escrito o no; en una app de Cursor o de Claude Code es la autorización que el agente dejó en la API, y muchas veces es un botón escondido. En mayo de 2025 un investigador escaneó 1.645 apps del escaparate público de Lovable y encontró 170 que se podían leer o escribir con la clave pública y nada más (CVE-2025-48757). Aquellas apps funcionaban. Funcionaban para todo el mundo.

El primer cuestionario de seguridad. Un cliente grande quiere comprar y te envía una hoja de cálculo: dónde están los datos, quién tiene acceso, cómo se rotan las claves, cuál es la copia de seguridad y hasta qué punto se recupera, si guardáis registros. Las preguntas no son difíciles. Lo que pasa es que no tienen respuesta en una app que nadie ha leído como sistema, y «la hicimos con IA» no es una respuesta que un departamento de compras acepte.

Cada una de estas tres mañanas pide lo mismo: alguien que lea la app entera y firme un veredicto. Y no quien la construyó, que ya sabe que no va a aguantar y no sabe decir por qué.

Los ocho síntomas son la app señalando el módulo que ha fallado primero

Cuando un fundador nos escribe, trae un síntoma, no una causa. Tras bastantes casos, los síntomas se ordenan solos en ocho, y cada uno apunta a un módulo. Publicamos la lista porque le ahorra una semana a todo el mundo.

1. El login se rompe o los usuarios pierden la sesión. La autenticación se quedó en los valores por defecto del constructor: URL de redirección, caducidad de sesión, confirmación por correo. En Supabase, sin un SMTP propio, el remitente incorporado se para en dos correos por hora, y esa es la avería del día de lanzamiento que nadie ve venir.
2. La base de datos va más lenta cada semana. Consultas sin índices, pantallas que cargan tablas enteras, una política que evalúa auth.uid() fila a fila. Con cincuenta usuarios no se nota.
3. El pago entra y el acceso no se desbloquea. Webhooks sin verificación de firma, sin reintentos ni idempotencia, de modo que un evento perdido o repetido deja la cuenta en el estado equivocado.
4. Funciona en preview y falla en producción. Variables de entorno y ajustes de build que solo existen en la plataforma del constructor, sin ningún staging en medio. Las apps de v0 y de Replit lo muestran más que ninguna, porque la plataforma era el entorno.
5. No pasaría una revisión de seguridad. Claves dentro del bundle del navegador, políticas de acceso que nadie ha probado, ningún registro de accesos.
6. No puedes dar de alta a un segundo cliente. Aislamiento por convención: el front filtra por organization_id; la base de datos, no.
7. Nadie se atreve a desplegar. Sin tests en los caminos que mueven dinero o datos personales, sin CI, y cada arreglo del agente rompe otra cosa. El agente de Replit borró una base de datos de producción en julio de 2025 durante una prueba en vivo, después de que le ordenaran no tocar nada. La lección no va de Replit: un solo entorno más un agente con permiso de escritura es un entorno de menos.
8. La factura de la nube crece más deprisa que los usuarios. Llamadas al modelo sin tope, funciones que se ejecutan en cada vista de página, recursos que nadie apagó.

Cada síntoma, una vez tiene nombre, es uno o dos días de trabajo senior. Lo caro viene antes: decidir cuál de los ocho tienes, en qué módulo, y si ese módulo merece conservarse.

Las dos respuestas equivocadas son reescribirlo todo y «lanzar y ver qué pasa»

Alguien, a menudo tu primer fichaje senior, propondrá reescribirla «como es debido». He visto ese consejo quemar un trimestre de caja en productos cuyas pantallas y cuyo modelo de datos estaban bien. Primero el perímetro, después sustituir lo que lleva riesgo pieza a pieza, y seguir sacando funcionalidades mientras tanto: ese orden gana casi siempre, y lo defendí en el primer post de esta serie.

La otra respuesta equivocada es seguir adelante. Es la que más fundadores eligen, porque hoy la app funciona y porque quienes les dicen que paren son los mismos que venden la parada. Concedo la versión más fuerte de esa objeción: nueve de cada diez apps de aquel escaneo de Lovable no estaban expuestas por ese fallo, y una app sin usuarios que paguen y sin datos sensibles debería seguir construyéndose con la herramienta que la trajo hasta aquí. Un veredicto antes de que haya algo que proteger es dinero gastado en un activo que quizá no sobreviva al siguiente giro.

Pero cuando ya ha llegado una de las tres mañanas, «lanzar y ver» significa dejar que la auditoría la hagan los clientes. La harán. Y entregarán los hallazgos en forma de devoluciones y de cuestionarios.

Hay una tercera respuesta, y tiene nombre en todas las disciplinas que lanzan cosas. Antes de un lanzamiento, cada puesto de la sala canta go o no-go con su propia telemetría. El director de vuelo no lanza por una corazonada, sino sobre una lista de «go», cada uno respaldado por un número que alguien puede enseñar. Yo pasé años en la versión corporativa de esa sala, donde una release solo recibía el go con un rollback probado y una copia que alguien había restaurado de verdad. Eso es lo que quiero de las dos semanas que van de «ha dejado de ser una demo» a «empezamos el trabajo».

Un sprint de discovery termina en un go/no-go por módulo, con la medición al lado

El Diagnóstico y Blueprint es ese sprint de discovery: dos semanas, acceso de solo lectura al repositorio, a la base de datos y a la consola de la nube, una sesión de trabajo con quien mejor conoce el producto y, al final, un veredicto por escrito. La página cuenta qué contiene el documento. Lo que quiero dejar claro aquí es el listón que tiene que superar el veredicto, porque un veredicto que no se puede comprobar es una opinión con membrete.

La unidad es el módulo, no la app. Login, datos, pagos, integraciones, la capa de IA: cada uno recibe una de tres palabras. Rescatar significa que el módulo aguanta a un usuario que paga con una lista acotada de arreglos. Rehacer significa que los arreglos cuestan más que una versión limpia que encaje en la arquitectura objetivo. Tirar significa que nadie lo usa y lleva riesgo. Ningún módulo se queda en «depende».

Cada veredicto lleva su evidencia, y la evidencia es una medición, no una impresión:

• Caminos críticos ejecutados. Alta, login, pago y la consulta que sería una brecha si se filtrara, recorridos de principio a fin contra una copia de los datos, con lo que pasó anotado. No «la autenticación parece correcta»: esta petición, este usuario, esta respuesta.
• Consultas cronometradas. La pantalla lenta tiene una consulta, la consulta tiene un plan y el plan tiene un número. Un «rescatar» en el módulo de datos llega con el índice que lo arregla y con el tiempo de antes y de después.
• Costes medidos. Cuánto cuesta una petición a la capa del modelo, cuánto cuesta una vista de página en invocaciones de funciones y cuál sería la factura con diez veces más usuarios. Si nadie puede dar esos tres números, el síntoma ocho ya está de camino.
• Para las funcionalidades de IA, un conjunto de evaluación y una métrica. Esta es la que la mayoría de fundadores no se ha encontrado todavía. Una funcionalidad de IA sin evals es una funcionalidad que nadie puede tocar: el siguiente retoque al prompt puede mejorarla o romperla, y nadie lo sabrá hasta que lo sepa un cliente. El veredicto sobre un módulo de IA es un go/no-go contra un conjunto de casos que el modelo tiene que superar y la métrica que tiene que alcanzar, y ese conjunto se convierte en la suite de regresión de todos los cambios que vengan después.

Las mediciones se entregan con los archivos, para que la siguiente persona, ya sea tu fichaje, nuestro equipo o el mismo agente que escribió la primera versión, pueda repetirlas. Esa es la diferencia entre un sprint de discovery y una presentación.

Qué haría yo la semana siguiente a la primera factura

Si la app fuera mía y el primer desconocido acabara de pagar, en este orden:

1. Apunta en qué mañana estás. Primer pago, segundo cliente o cuestionario. Eso fija el orden de todo lo que sigue.
2. Quítale al agente el permiso de escritura en producción. Un solo entorno con un agente de código dentro es la historia de Replit esperando a repetirse. Dale al agente una rama y una base de datos de preview; producción queda para las personas y para la CI.
3. Rota todas las claves que hayan pasado alguna vez por el repositorio y busca en el bundle compilado la clave secreta o de service role. Es una tarde de trabajo, y cierra el hallazgo por el que pregunta primero cualquier cuestionario.
4. Recorre tú mismo los tres caminos críticos y anota lo que viste. Si no sabes dibujar el recorrido de la petición más arriesgada, ese es el primer trabajo de la auditoría.
5. Pide un veredicto por módulo a alguien que ya lo haya hecho antes, por escrito y con las mediciones adjuntas. Dos semanas es la duración correcta: más tiempo significa que el auditor se ha puesto a construir; menos, que está adivinando.
6. Decide con los números delante. Rescatar, rehacer o tirar, módulo a módulo, y solo entonces construir. En la mayoría de apps hechas con IA las pantallas y buena parte del modelo de datos se quedan, la autenticación y los pagos se rehacen, y cuando hay que rehacer el núcleo, es un MVP en 6 semanas.
7. Deja los archivos de contexto en su sitio. CLAUDE.md, AGENTS.md, los tests y las evals, para que Cursor o Claude Code sigan construyendo dentro del plan y no alrededor.

La demo demostró la demanda; el veredicto es lo que debes a quien ha pagado

Una app hecha con vibe coding hace lo caro en un fin de semana: demuestra que alguien quiere el producto. Lo que no puede hacer es decidir qué le debe a la persona que ha pagado, y esa decisión es todo lo que pasa después. Ni una reescritura ni encogerse de hombros: un go/no-go por módulo, cada uno con una medición que alguien pueda repetir.

Ese es el primer paso de cómo llevamos a producción una app hecha con IA: un Diagnóstico y Blueprint de dos semanas que termina exactamente en ese veredicto, y que puedes ejecutar con nosotros, con tu propio fichaje o con el agente que escribió la primera versión. Si quieres compararnos con otras empresas que hacen este trabajo, lo hice yo mismo en la guía sobre a quién contratar para un MVP hecho con IA, y estamos en el directorio de agencias de vibecoding.app, en su categoría de rescate full-stack, al lado de las demás.