Escalabilidad: que tu app aguante usuarios

Actúa como un ingeniero de backend con experiencia en apps que crecen rápido.

Tu trabajo es decirme qué partes de mi app se van a poner lentas o van a fallar
cuando tenga muchos usuarios y mucha data.

Esto es lo que tengo:
[PEGA AQUÍ el código de tus pantallas y consultas principales, o abre este prompt
dentro de tu proyecto. Dime también qué base de datos usas: Supabase, Firebase,
Postgres, MySQL, etc.]

Revisa:
1. Consultas que traen todas las filas de una tabla sin límite ni paginación
2. Consultas dentro de bucles: una consulta por cada elemento de una lista
   (problema N+1)
3. Columnas por las que filtras, ordenas o unes tablas y que probablemente no
   tienen índice
4. Consultas que traen todas las columnas cuando solo se usan dos o tres
5. Data que se vuelve a pedir en cada carga aunque casi nunca cambia
6. Imágenes o archivos que se cargan en tamaño completo sin necesidad

Responde con este formato:
- Los 5 problemas más graves, ordenados por lo que más se va a notar al crecer
- Para cada uno: archivo y línea, qué pasa hoy con 100 usuarios y qué pasa con
  10,000
- Qué arreglar primero y por qué

No cambies el código todavía, solo dame el diagnóstico.

Actúa como un ingeniero de backend arreglando una pantalla que trae demasiada
data.

Tu trabajo es añadir paginación a esta pantalla.

Esto es lo que tengo:
[PEGA AQUÍ el código de la pantalla y de la consulta que trae los datos]

Haz esto:
1. Dime cuántos registros trae hoy esta consulta y por qué es un problema
2. Implementa paginación trayendo de 20 en 20, usando la forma recomendada para
   mi base de datos
3. Explícame la diferencia entre paginar por número de página y paginar por
   cursor, y dime cuál me conviene aquí
4. Actualiza la interfaz: botón de cargar más o scroll infinito, con su estado
   de carga
5. Asegúrate de que el orden de los resultados sea estable, para que no se
   repitan ni se salten filas al cargar más

Muéstrame el código final completo y dime cómo probar que funciona con muchos
registros.

Actúa como un ingeniero de backend cazando consultas innecesarias.

Tu trabajo es encontrar y arreglar los casos donde mi app hace una consulta por
cada elemento de una lista.

Esto es lo que tengo:
[PEGA AQUÍ el código de la pantalla o del endpoint que muestra una lista con
datos relacionados, por ejemplo pedidos con su cliente]

Haz esto:
1. Cuenta cuántas consultas hace hoy esta pantalla con 20 elementos y con 200
2. Señala exactamente dónde está la consulta dentro del bucle
3. Reescríbelo para traer todo en una sola consulta, usando joins o la sintaxis
   de relaciones de mi base de datos
4. Si no se puede en una sola, agrupa las consultas para que sean pocas y fijas,
   no una por fila
5. Dime cuántas consultas quedan después del cambio

Muéstrame el antes y el después, y confirma que el resultado que ve el usuario
es el mismo.

Actúa como un administrador de bases de datos revisando un proyecto que va a
crecer.

Tu trabajo es decirme qué índices le faltan a mi base de datos.

Esto es lo que tengo:
[PEGA AQUÍ el esquema de tus tablas y las consultas que más corre tu app,
incluyendo por qué columnas filtras, ordenas y unes tablas]

Haz esto:
1. Para cada consulta, dime qué columnas necesitan índice y por qué
2. Dame las instrucciones SQL para crear esos índices, listas para correr
3. Dime cuáles conviene que sean índices compuestos, de varias columnas, y en
   qué orden deben ir esas columnas
4. Avísame si algún índice que propones va a hacer las escrituras más lentas y
   si vale la pena igual
5. Dime si hay índices que probablemente no se usan y solo estorban
6. Explícame cómo confirmar que la base de datos de verdad está usando cada
   índice

Importante: pruébalo primero en un ambiente de pruebas, no en producción. Dime
cómo crear índices sin bloquear la tabla si ya tengo usuarios.

Actúa como un ingeniero de rendimiento revisando cuánta data viaja en mi app.

Tu trabajo es reducir lo que se transfiere en cada pantalla.

Esto es lo que tengo:
[PEGA AQUÍ el código de tus consultas y de las pantallas que las usan]

Revisa:
1. Consultas que traen todas las columnas cuando la pantalla solo usa algunas
2. Campos pesados que se traen sin necesidad: textos largos, JSON grandes,
   imágenes en base64
3. Data que se trae para toda la lista cuando solo hace falta al abrir el detalle
4. Imágenes que se cargan en tamaño completo para mostrarse pequeñas
5. Data que el usuario nunca llega a ver

Para cada caso dime cuánto se transfiere hoy aproximadamente, qué quitar, y
muéstrame la consulta corregida.

Actúa como un ingeniero de rendimiento decidiendo qué vale la pena cachear.

Tu trabajo es evitar que mi app vuelva a pedir lo mismo una y otra vez.

Esto es lo que tengo:
[PEGA AQUÍ el código de tus pantallas principales y dime qué stack usas]

Haz esto:
1. Identifica qué data casi nunca cambia (categorías, configuración, perfiles,
   listas fijas) y cuál tiene que estar siempre fresca (saldos, pedidos, stock)
2. Para cada una, propón dónde cachear y por cuánto tiempo
3. Implementa el caché con las herramientas que ya usa mi proyecto
4. Explica cómo se limpia el caché cuando esa data sí cambia, para que nadie vea
   información vieja
5. Dime qué NO debería cachear nunca en mi caso y por qué

Muéstrame el código final y cómo comprobar que el caché está funcionando.

Actúa como un ingeniero de rendimiento que no adivina, mide.

Tu trabajo es enseñarme a saber exactamente qué está lento en mi app.

Esto es lo que tengo:
[PEGA AQUÍ tu stack y tu base de datos, y describe la pantalla que sientes lenta]

Haz esto:
1. Dime cómo ver cuánto tarda cada consulta en mi base de datos, con el comando
   exacto (por ejemplo, cómo leer el plan de ejecución de una consulta)
2. Enséñame a interpretar ese resultado en español simple: qué significa que
   recorra la tabla completa y qué significa que use un índice
3. Dime cómo medir el tiempo de carga de una pantalla en mi app
4. Recomiéndame una herramienta gratis para ver esto en producción y cómo
   conectarla
5. Dame 3 números que debería vigilar cada semana, con un valor razonable para
   cada uno

Explícalo para alguien que nunca ha medido rendimiento.

Actúa como un ingeniero de QA preparando una prueba de carga.

Tu trabajo es ayudarme a saber cuántos usuarios aguanta mi app antes de que sea
un problema real.

Esto es lo que tengo:
[PEGA AQUÍ el flujo principal de tu app y dónde está desplegada: Vercel,
Supabase, etc.]

Haz esto:
1. Dime cuánta data de prueba debería generar para que la prueba tenga sentido
   (por ejemplo, 100,000 filas) y dame un script para generarla
2. Recomiéndame una herramienta de prueba de carga sencilla y dame la
   configuración lista para correr el flujo principal
3. Simula usuarios en aumento y dime qué debería observar en cada nivel
4. Dime qué límites de mi plan actual puedo tocar: conexiones a la base de
   datos, tiempo máximo de ejecución, límites de peticiones
5. Interpreta los resultados: qué significa que empiece a fallar en cierto punto

Importante: esto se corre contra un ambiente de pruebas con data falsa, nunca
contra producción ni contra datos de usuarios reales.