8 Señales de que tu App de IA es Solo una Demo, No un Producto Real
Un amigo me envió un enlace un viernes por la noche. "Prueba esto, no está terminado pero funciona."
Ya era mala señal: localhost:3050. 😬
TL;DR: 8 señales de que tu app de IA no está lista para producción. Para cada una: qué se rompe, por qué se rompe, y un prompt de Claude Code para arreglarlo. Esencial si ya has lanzado algo, aunque sea una herramienta personal que nadie más conoce todavía.
Se lo dije. Me envió un enlace como Dios manda diez minutos después.
Abrí la app, eché un vistazo. La idea era sólida. Pero deformación profesional, presioné F12. Abrí la consola.
Lo que encontré fue un resumen de todo lo que mata apps en producción.
Errores de CORS apilados de a tres. Una API key de OpenAI en texto plano dentro de las requests de red. Un SELECT * disparándose con cada tecla en el campo de búsqueda. Sin rate limiting en ningún lado. Cuando le pregunté cómo monitoreaba errores en prod, me dijo "simplemente veo si se cae."
No era un producto. Era un demo con nombre de dominio.
Clásico.
Existe una versión de "terminado" que se ve exactamente como lo real. Misma UI. Misma URL. A veces hasta usuarios que pagan. Pero por debajo, funciona sobre supuestos que solo se mantienen cuando nada sale mal.
Un demo está optimizado para impresionar. Un producto está optimizado para sobrevivir. No son dos puntos en un espectro, son dos modos de construcción completamente diferentes. Un demo tiene éxito si funciona una vez frente a alguien. Un producto tiene que funcionar diez mil veces mientras no estás mirando.
Cada señal en esta lista es consecuencia directa de esa única distinción.
1. Tienes Cero Visibilidad de Lo Que Pasa en Producción
Si tu estrategia de monitoreo es "me daré cuenta si se cae," no tienes monitoreo. Tienes esperanza.
Sin logs estructurados. Sin alertas de errores. Sin checks de uptime. En modo demo, ejecutas la app tú mismo, ves todo, nada te sorprende. En producción, las funcionalidades pueden romperse silenciosamente por tres días. Los usuarios dejan de volver. No tienes idea por qué.
Tuve un webhook de n8n que dejó de procesar por 48 horas. Me enteré por casualidad mientras debuggeaba otra cosa. Después leí un comentario en uno de mis artículos de Medium preguntando por qué la herramienta que había mencionado devolvía 503s. El artículo tenía tres días. La herramienta había estado caída desde que lo publiqué.
Solución: Sentry tier gratuito para errores de runtime. UptimeRobot para uptime. Quince minutos en total. Sin excusas.
"Configura monitoreo básico de producción para esta app. Agrega Sentry para tracking de errores, integra UptimeRobot vía un endpoint /health, y añade una alerta de webhook de Slack para cualquier excepción no manejada en prod."
No necesitas una sala de guerra. Necesitas un detector de humo.
2. No Tienes un Ambiente de Staging
La app de mi amigo vivía en un servidor. El mismo servidor en el que estaba desarrollando activamente. Lo que significaba que cada vez que subía un fix, producción era el ambiente de pruebas.
Una vez rompí el auth de OpenClaw por dos horas porque una variable de entorno en prod tenía un nombre ligeramente diferente que en local. El tipo de cosa que detectas inmediatamente en staging. El tipo de cosa que hace que los usuarios piensen que tu app los desloguea al azar, y después no vuelven.
Staging no necesita ser elegante. Un VPS de $3 (yo ejecuto el mío en una caja de $5 — mismo principio). Una branch de preview de Vercel. Un workflow de GitHub Actions que deploya a staging en cada PR y a prod solo en merge a main.
Cualquier cosa que cree una capa entre "acabo de cambiar algo" y "usuarios reales lo están usando." El punto no es tener un proceso perfecto. El punto es tener un deploy que no apunte directamente a usuarios reales.
"Crea una configuración de ambiente de staging para este proyecto. Separa .env.local y .env.production, agrega un workflow de GitHub Actions que deploya a staging en PR y a prod en merge a main, y añade un checklist pre-deploy al README."
3. Tus API Keys Están en el Código
Esto es lo que la IA genera por defecto:
const openai = new OpenAI({ apiKey: "sk-proj-..." });Funciona. También está a un git push de ser público.
No explicaré cómo, pero tengo amigos que nunca pagan por una sola herramienta SaaS. No porque pirateen nada. Porque cada pocos meses ejecutan un escaneo de dos minutos y encuentran suficientes keys filtradas para cubrir su stack por el próximo trimestre. Sentadas en repos públicos. Olvidadas en el historial de commits. Como un mundo post-apocalíptico donde las puertas están abiertas y las neveras siguen llenas. Nadie limpió antes de irse.
Tu key probablemente está en una de esas neveras ahora mismo.
La IA no tiene concepto de si estás construyendo una app personal de todos o un SaaS con clientes que pagan. Pone la key donde es conveniente. "Esto terminará en GitHub" no está en su modelo de amenazas.
Solución: archivo .env, .gitignore, listo. Después ejecuta git log -p | grep -i "api_key" en tus repos existentes. Puede que no te guste lo que encuentres.
"Audita este codebase por API keys, tokens y secretos hardcodeados. Lista cada ocurrencia con archivo y número de línea. Genera la migración completa a .env y actualiza todas las referencias para usar process.env."
(Este no es un error de principiante. Es un error de "moverse rápido sin checklist." Nos pasa a todos eventualmente.)
4. No Tienes Rate Limiting
Alguien encontrará tu endpoint de API. Podría ser un bot. Podría ser un usuario curioso. Podría ser un scraper que encontró tu URL en un sitemap. No importa quién. Lo que importa es que lo golpearán 400 veces en tres minutos y te enterarás en tu dashboard de facturación.
En ContentForge, tenía un endpoint de generación sin límites. Un scraper lo golpeó antes de que siquiera lanzara públicamente. Sin daño porque lo detecté rápido. Pero la alerta mental fue fuerte: si no hubiera estado viendo los logs esa mañana, habría quemado todo mi presupuesto de API antes de que apareciera el primer usuario real.
Solución: express-rate-limit en Node. Rate limiting a nivel de Traefik o Nginx si estás auto-hosteado. Cinco líneas de config. Detiene el 90% de las cosas tontas antes de que se vuelvan cosas caras.
"Agrega rate limiting a todos los endpoints de API en este codebase. Usa express-rate-limit con 100 requests por 15 minutos por IP como default. Aplica límites más estrictos en rutas de auth y cualquier endpoint que dispare una llamada a API externa."
5. Nunca Has Probado Qué Pasa Cuando Alguien Hace Algo Estúpido
La IA genera el happy path. Siempre.
El usuario llena el formulario correctamente, hace clic en el botón correcto, tiene una conexión estable, no hace doble clic en submit. Lo que no genera: envíos de campos vacíos. Uploads de archivos con 0 bytes. Sesiones que expiran a mitad de formulario. El mismo botón clickeado dos veces porque el primer clic se sintió lento.
En ContentForge, un usuario envió un prompt vacío. NaN se escribió en la base de datos. Lo que cascadeó en metadata roto en cada artículo generado después de eso. Lo encontré dos días después mientras debuggeaba algo completamente no relacionado.
Solución: antes de compartir el enlace con alguien, pasa diez minutos activamente tratando de romper tu propia app. No se requieren unit tests. Solo caos. Haz clic en cosas en el orden incorrecto. Deja campos vacíos. Envía dos veces. Refresca a mitad de operación.
O simplemente ejecuta esto en Claude Code primero:
"Actúa como un usuario malicioso tratando de romper esta app. Prueba cada formulario con inputs vacíos, caracteres especiales y payloads sobredimensionados. Intenta enviar el mismo formulario dos veces en sucesión rápida. Expira la sesión a mitad de flujo. Documenta cada crash, comportamiento inesperado o caso edge no manejado que encuentres."
La IA nunca hará esto por ti a menos que se lo pidas explícitamente. Y aun así, se perderá la mitad.
6. Tus Configs de Prod y Dev Son los Mismos Archivos 😱
Mismo .env. Misma base de datos. Mismo bucket de S3.
La IA no hace la distinción entre ambientes. Configura para "funciona," no para "funciona de forma segura cuando estás probando una migración destructiva localmente." La separación de ambientes no está en el prompt, así que no llega al código.
Esto no es solo un fix técnico. Es una decisión estructural que tiene que tomarse antes del primer deploy, no descubrirse seis semanas después cuando una prueba local borra una tabla con datos reales de usuarios. Definir esos límites por adelantado es el tipo de contrato arquitectónico que separa apostar de enviar. Por eso existe el framework de prompt contracts — definir límites antes de que te veas forzado a hacerlo.
Solución: .env.local, .env.production, dos bases de datos separadas. Incluso para un proyecto personal con tres usuarios. Especialmente para un proyecto personal con tres usuarios.
"Audita la configuración de ambientes de este proyecto. Identifica cada lugar donde prod y dev comparten la misma config, base de datos o storage. Genera un plan completo de separación de ambientes con archivos .env separados, conexiones de base de datos y buckets de storage para cada ambiente."
7. Tus Errores Son Silenciosos
La IA escribe bloques try/catch. También los llena con console.error o nada en absoluto.
El error se captura. Nadie lo sabe. El usuario ve un resultado en blanco o un spinner congelado. Se van. Tú no ves nada.
Tuve un formulario de contacto en un proyecto personal que había estado silenciosamente descartando cada envío por dos semanas. El mailer se estaba cayendo por un problema de config. Capturado, loggeado a ningún lado, tragado. Me enteré cuando alguien preguntó en los comentarios por qué nunca respondí a su mensaje.
Dos semanas de leads muertos. Cero indicación de que algo estaba mal de mi lado.
Solución: Sentry tier gratuito. Es una plataforma de tracking de errores que captura cada excepción no manejada en tiempo real, con el stack trace completo, el navegador del usuario, la línea exacta de código, y un conteo de reproducción. Diez minutos de setup. No es opcional si tienes usuarios reales.
¿Sin Sentry todavía? Como mínimo, ejecuta esto primero:
"Audita cada bloque try/catch en este codebase. Reemplaza catches vacíos y catches de solo console.error con logging estructurado de errores. Agrega un handler global de unhandledRejection. Genera un resumen de cada punto de falla silenciosa que encontraste."
Los errores silenciosos no son bugs. Son fantasmas.
8. No Sabes Qué Estás Gastando en Tiempo Real
Llega la factura. La abres. No reconoces el número.
En dev, llamas a la API diez veces. Pruebas una funcionalidad, funciona, sigues adelante. En prod, un usuario con un loop agresivo de retry, un campo de búsqueda disparando en cada tecla, una query sin índice ejecutando full table scans en un dataset creciente. Cualquiera de estos puede convertir un presupuesto de $20/mes en una sorpresa de $200 antes de que termines tu café.
La IA genera código que funciona. No genera código que es económicamente seguro bajo carga. No tiene concepto de tu tope de presupuesto, tu margen, o qué pasa cuando alguien que no eres tú golpea el endpoint 400 veces.
Solución: alertas de facturación en cada servicio por el que estés pagando. AWS, OpenAI, Anthropic, Supabase. Todos tienen alertas de umbral. Configúralas antes de compartir el enlace públicamente. Límites duros en llamadas de API por usuario por día. Un dashboard básico de costos, incluso una hoja de cálculo, revisado semanalmente.
No es glamoroso. Te salva el mes.
"Agrega protección de facturación a esta app. Implementa límites diarios de llamadas de API por usuario, agrega topes duros en cualquier loop que llame a una API externa, y genera una sección de README con instrucciones paso a paso para configurar alertas de presupuesto en OpenAI, Anthropic, AWS y Supabase."
Envíalo Bien o Envíalo Dos Veces
Mi amigo, por cierto, arregló todo. Le tomó un fin de semana. La app es genuinamente buena, mejor que la mayoría de lo que veo enviado por equipos con presupuestos reales. Esa es la cosa sobre las apps vibe-coded hechas bien: la idea y la ejecución pueden ser excepcionales. La capa de infraestructura es lo que las mata. Y esa parte es arreglable.
La industria seguirá llamando "productos" a estos demos por otros dieciocho meses. Las capturas de pantalla se ven iguales. Los posts de lanzamiento suenan idénticos.
Los builders que realmente envían revisan esta lista antes de compartir el enlace. No después de la brecha. No después de la factura de $14k. Antes.
Un demo impresiona. Un producto sobrevive.
Si esto te salvó de una mala noche de viernes, hay más de donde vino. Escribo sobre construir cosas reales con IA, las partes que los tutoriales se saltan.
(*) La portada es generada por IA. Prompteada, no pintada, pero las historias de horror en el artículo son demasiado reales.
Este artículo puede contener enlaces de afiliados, y puedo ganar una pequeña comisión.
Cada demo de IA esconde secretos que pueden destruir tu producto en producción. Te cuento los 8 errores críticos que transforman tu app de 'wow' a 'caída'.