De demo a vendible: las 10 capas que tu app hecha con IA necesita para que la gente pague

Actúa como mi auditor de seguridad de front-end. Revisa cómo se empaqueta y se publica mi aplicación y dime, en lenguaje simple, qué tan expuesto está mi código.

1. Confírmame si el build de producción genera source maps y si se están subiendo al servidor. Si es así, explícame el riesgo y desactívalos en la configuración del bundler (Next.js, Vite o el que use).
2. Busca llaves, tokens o secretos escritos directamente en el código del front-end (claves de API, de Stripe, de la base de datos). Lístalos con su archivo y su línea.
3. Por cada secreto expuesto, dime cuál debería vivir solo en el servidor o en variables de entorno, y muévelo. Diferencia las variables públicas (las que sí pueden ir al cliente) de las privadas.
4. Verifica que el código de producción salga minificado, sin comentarios ni nombres internos.

Primero entrégame el reporte con todo lo que encontraste. No cambies nada hasta que yo te diga "aplícalo".

Actúa como mi experto en seguridad de base de datos. Quiero blindar mi base con RLS (Row Level Security), que es el candado para que cada usuario solo vea y toque sus propios datos.

1. Revisa mi base (Supabase/Postgres o la que use) y dime tabla por tabla si tiene RLS activado o si está abierta para cualquiera.
2. Señala las tablas con datos sensibles (usuarios, pagos, mensajes) que hoy podría leer o modificar alguien que no es el dueño.
3. Propón las políticas RLS necesarias para que cada fila solo sea accesible por su dueño (por ejemplo, comparando el user_id de la fila con el usuario autenticado) y muéstrame el SQL.
4. Dame un caso de prueba: cómo confirmar que el usuario A ya no puede ver los datos del usuario B.

Entrégame primero el diagnóstico y el SQL propuesto. No ejecutes cambios en la base hasta que yo lo apruebe.

Actúa como mi guía de control de versiones con Git. Quiero poder mejorar mi app sin miedo a romperla.

1. Revisa si el proyecto ya usa Git. Si no, inicialízalo y crea un .gitignore correcto para mi stack (que no suba node_modules, .env ni archivos de build).
2. Confírmame que ningún secreto (.env, llaves) esté en el historial de Git. Si lo está, avísame y dime cómo sacarlo.
3. Explícame en simple un flujo de trabajo seguro: rama principal estable, una rama por cada cambio y commits con mensajes claros. Propón nombres de ejemplo.
4. Enséñame cómo volver atrás si una versión sale mal (cómo deshacer el último cambio sin perder todo).

Primero el diagnóstico del estado actual. Cuando lo apruebe, hacemos los cambios.

Actúa como mi arquitecto de APIs. Quiero que mi app se conecte bien con servicios externos y exponga sus propios endpoints de forma ordenada.

1. Lista las APIs que ya consume mi app y las rutas propias que expone. Dime cuáles devuelven datos sensibles sin pedir autenticación.
2. Revisa que cada endpoint valide quién llama (autenticación) y qué puede hacer (permisos), y que valide los datos de entrada antes de usarlos.
3. Propón una estructura clara y consistente para mis endpoints: nombres, métodos, manejo de errores y respuestas. Marca lo que hoy está inseguro o inconsistente.
4. Sugiéreme dónde conviene una integración por API (pagos, correo, IA) en lugar de reinventarla.

Dame primero el inventario y los hallazgos. No toques el código hasta que te diga que sí.

Actúa como mi ingeniero de despliegue. Quiero sacar mi app de mi computadora (localhost) y ponerla en vivo en internet de forma estable.

1. Mira mi stack y recomiéndame la forma más simple de publicarla (por ejemplo Vercel, Netlify o similar para el front, y dónde irían la base de datos y el backend).
2. Lista lo que necesito configurar para producción: variables de entorno, dominio, HTTPS y la separación entre el entorno de pruebas y el de producción.
3. Dame el paso a paso del primer despliegue, asumiendo que nunca lo he hecho.
4. Dime qué revisar después de publicar para confirmar que todo quedó funcionando.

Primero el plan completo. Lo ejecutamos cuando lo apruebe.

Actúa como mi auditor de seguridad de aplicación. Quiero cerrar los huecos por los que alguien podría entrar o vaciarme la cuenta.

1. Revisa cómo manejo el inicio de sesión y las sesiones: contraseñas, tokens, expiración y cierre de sesión. Marca lo débil.
2. Busca vulnerabilidades comunes: inyección en consultas a la base, datos del usuario que se usan sin validar, endpoints sin protección y permisos mal puestos.
3. Revisa que los servicios que cobran por uso (IA, envíos, pagos) no puedan ser disparados por cualquiera sin control.
4. Entrégame los hallazgos ordenados por gravedad (crítico, alto, medio) con una explicación simple de cada uno.

Solo el reporte priorizado por ahora. Los arreglos los aprobamos uno por uno.

Actúa como mi experto en rate limiting. Quiero que nadie pueda pegarle mil veces a mi app y quemarme el saldo o tumbar el servicio.

1. Identifica los endpoints más caros o sensibles (los que llaman a IA, mandan correos, hacen login o tocan pagos).
2. Dime si hoy existe algún límite de peticiones por usuario o por IP. Si no hay, explícame el riesgo concreto en dinero y en disponibilidad.
3. Propón límites razonables por ruta (cuántas peticiones por minuto) y una herramienta simple para aplicarlos (por ejemplo Upstash/Redis o lo que encaje con mi stack).
4. Define qué pasa cuando alguien se pasa del límite: qué mensaje recibe y por cuánto tiempo se bloquea.

Dame el plan con los límites sugeridos. Lo implementamos cuando lo apruebe.

Actúa como mi especialista en rendimiento y caché. Quiero que mi app se sienta rápida y que la gente no se salga por lentitud.

1. Encuentra las operaciones lentas o repetidas: consultas pesadas a la base, llamadas a APIs externas y datos que casi no cambian pero se piden todo el tiempo.
2. Dime dónde conviene poner caché (en el navegador, en el servidor o en una capa tipo Redis) y por cuánto tiempo en cada caso.
3. Explícame el riesgo de mostrar datos viejos y cómo invalidar la caché cuando algo cambie.
4. Estima cuánto mejoraría la velocidad cada cambio, para priorizar.

Primero el diagnóstico y la propuesta. No cambies nada hasta que lo apruebe.

Actúa como mi arquitecto de escalabilidad. Quiero que el día que tenga 1,000 usuarios usándola al mismo tiempo, mi app no se caiga.

1. Encuentra los cuellos de botella: consultas sin índices, procesos que bloquean, tareas pesadas que deberían correr en segundo plano y conexiones a la base mal manejadas.
2. Dime qué partes aguantan crecer y cuáles se romperían primero bajo carga, con una explicación simple.
3. Propón mejoras concretas y priorizadas: índices en la base, mover tareas lentas a una cola, paginar resultados y separar lo que más consume.
4. Sugiéreme cómo simular muchos usuarios para probar antes de que pase de verdad.

Entrégame el reporte priorizado. Aplicamos los cambios uno por uno cuando lo apruebe.

Actúa como mi ingeniero de monitoreo. Quiero enterarme de qué se rompe en mi app antes de que me lo diga un usuario enojado.

1. Revisa si hoy tengo forma de ver errores en producción y registros (logs). Si no, dímelo claro.
2. Recomiéndame una herramienta simple para capturar errores y alertas (por ejemplo Sentry o similar) y guíame para conectarla a mi stack.
3. Define qué debería vigilar: errores, caídas, tiempos de respuesta lentos y gasto inusual en servicios que cobran por uso.
4. Configura alertas para que me avise (correo o mensaje) cuando algo se salga de lo normal, sin llenarme de ruido.

Primero el plan de monitoreo. Lo conectamos cuando lo apruebe.