Verificador de Preparación para Escalar
Titular
Convierte Tu Aplicación en un Plan Que Pueda Crecer de 5 Usuarios a 5,000 Usuarios, en Palabras Sencillas
Gancho
Sube tu aplicación. Responde algunas preguntas. Obtén el plan completo para hacerla crecer sin que se ralentice o se caiga.
El problema, en palabras sencillas
La mayoría de las aplicaciones funcionan bien con 5 usuarios, luego se ralentizan o se caen cuando se unen más personas. La base de datos tiene que buscar en cada fila, los mismos datos se obtienen una y otra vez, y nadie ha probado qué sucede con 1,000 usuarios a la vez. La solución no es primero un servidor más grande. La solución es un plan: indexar los datos, almacenar en caché lo que se usa a menudo, probar la carga y alojarlo donde pueda crecer.
Lo que obtienes
Una verificación de preparación para escalar y luego un plan de escalabilidad, hecho solo para tu aplicación. La verificación encuentra qué se romperá primero. El plan te da borradores de soluciones para revisar, nunca un cambio en vivo por sí mismo.
Para quién es esto
Fundadores sin código, que quieren saber si su aplicación puede crecer y qué arreglar primero, en palabras sencillas. Dueños de pequeños negocios con una aplicación o una web app que está recibiendo más usuarios. Freelancers y constructores que necesitan un plan de escalabilidad claro para entregar a un desarrollador, con indexación, caché, pruebas de carga y alojamiento incluidos.
Por qué esto ahorra dinero
Arreglar la escalabilidad temprano es más barato que arreglar una caída más tarde. Un plan claro evita que el constructor adivine, reconstruya la base de datos o compre un servidor más grande que aún no necesitas.
Técnico, para programadores
Plan de escalabilidad estructurado con lista de índices de base de datos, plan de caché con claves y vencimiento, plan de pruebas de carga con niveles de usuarios y punto de quiebre, y plan de alojamiento con notas de escalado, listo para informar a Claude, Cursor o cualquier constructor de IA, o un desarrollador humano. Sin garantía de un número de usuarios, y sin afirmar que un plan por sí solo haga escalar una aplicación. El plan es un borrador para revisión del dueño, no un cambio en vivo.
Propósito
Verificar si una aplicación está lista para crecer de unos pocos usuarios a muchos usuarios, luego hacer un plan de escalabilidad para ella. La skill primero verifica, luego planea. No cambia código, no cambia la base de datos, no ejecuta una prueba de carga en vivo sobre usuarios reales, ni despliega nada por sí misma.
Cómo usarlo
Paso 1: pregúntale al usuario estas preguntas, una a la vez, en palabras sencillas. Paso 2: verifica la aplicación contra las 4 verificaciones de escalabilidad a continuación. Paso 3: escribe el plan de escalabilidad, etiquetado BORRADOR, NO EN VIVO, con soluciones borrador para las brechas encontradas. Paso 4: ejecuta las verificaciones faltantes al final y lista lo que está completo, faltante o no confirmado.
Haz estas preguntas primero, una a la vez:
- ¿Qué hace tu aplicación, en palabras sencillas?
- ¿Quién la usa ahora y cuántos usuarios tienes hoy?
- ¿Cuántos usuarios quieres que maneje y para cuándo?
- ¿Qué hace un usuario con más frecuencia en la aplicación, en orden?
- ¿Dónde se almacenan tus datos ahora, por ejemplo Supabase, Firebase, una base de datos u otro?
- ¿Dónde está alojada tu aplicación ahora, por ejemplo Netlify, Vercel u otro?
- ¿Qué es lento ahora, si algo, y cuándo se siente lento?
- ¿Qué NO debe romperse, incluso cuando muchos usuarios se unen a la vez?
- ¿Tienes números de usuarios reales, o los números de usuarios son solo un objetivo?
- ¿Quién hará los arreglos, un constructor de IA, un desarrollador humano o tú con ayuda?
Si el usuario no sabe una respuesta, márcala como No confirmado y usa la respuesta más común para su tipo de aplicación, y dilo. No inventes una respuesta.
Las 4 verificaciones de escalabilidad
Verifica las 4, en orden. Para cada verificación, registra evidencia: el archivo, la tabla, la consulta, la configuración o la respuesta del usuario donde lo viste. Sin evidencia significa No aprobado.
1. Indexación de base de datos
- Las consultas más utilizadas tienen un índice, como un índice de libro, para que la base de datos encuentre filas rápido en lugar de leer cada fila.
- Lista las 5 consultas principales por uso, en palabras sencillas, y di para cada una si tiene índice o no.
- Falla si una consulta principal no tiene índice, o si la misma consulta es lenta con más filas.
- Solución borrador: una lista de índices, con nombre de tabla, nombre de columna y por qué ayuda ese índice, para revisión del dueño. No crees un índice por ti mismo.
2. Almacenamiento en caché
- Los datos que se usan a menudo y cambian raramente se almacenan en caché, para que no se obtengan de la base de datos cada vez.
- Lista lo que está en caché ahora, lo que debería estar en caché y por cuánto tiempo, en palabras sencillas.
- Falla si los mismos datos se obtienen en cada carga de página, sin caché, o si los datos en caché nunca se borran cuando cambian.
- Solución borrador: un plan de caché, con clave de caché, qué contiene, cuánto vive y cuándo se borra, para revisión del dueño. Nombra la herramienta de caché solo si el usuario ya usa una, por ejemplo Redis, o di Sugerido, no confirmado. No configures caché por ti mismo.
3. Pruebas de carga
- La aplicación ha sido probada con muchos usuarios falsos, para encontrar dónde se rompe primero, antes de que los usuarios reales lo encuentren.
- Lista los niveles de usuarios probados, por ejemplo 50, 500 y 5,000 usuarios a la vez, y el resultado para cada nivel.
- Falla si no se hizo ninguna prueba de carga, o si la prueba solo usó 5 usuarios, o si se desconoce el punto de quiebre.
- Solución borrador: un plan de pruebas de carga, con niveles de usuarios, qué hace cada prueba, qué observar y qué cuenta como aprobado, para revisión del dueño. No ejecutes una prueba de carga sobre usuarios reales y no la ejecutes en una aplicación en vivo a menos que el usuario lo permita.
4. Alojamiento que pueda crecer
- El alojamiento puede crecer cuando los usuarios crecen, sin una reconstrucción completa.
- Lista el alojamiento actual y di si escala solo o si necesita trabajo manual para crecer.
- Falla si el alojamiento es un solo servidor pequeño sin plan para crecer, o si un pico de tráfico detendría la aplicación.
- Solución borrador: un plan de alojamiento, con alojamiento actual, qué cambiar y qué queda igual, para revisión del dueño. Prefiere alojamiento simple que escala solo, por ejemplo Vercel o Netlify, sobre configuraciones complejas como Kubernetes o Azure, a menos que el usuario ya use una configuración compleja y quiera mantenerla. No muevas el alojamiento por ti mismo.
Verificaciones adicionales
Estas no son parte de las 4 verificaciones anteriores, pero repórtalas por separado como Notas. No las mezcles en la puntuación de los 4 puntos.
- Páginas lentas: lista la página más lenta y qué la hace lenta, en palabras sencillas.
- Trabajo pesado: lista el trabajo que debería ejecutarse en segundo plano, por ejemplo enviar muchos correos electrónicos o hacer muchos archivos, en lugar de bloquear al usuario.
- Costo: lista qué costará más a medida que crezcan los usuarios, por ejemplo lecturas de base de datos o alojamiento, en palabras sencillas, sin precio inventado.
- Móvil: di si la aplicación se usa en un teléfono y si las partes lentas son peores en un teléfono.
Reglas estrictas
- Nunca marques Aprobado sin evidencia.
- Nunca inventes un número de usuario, una velocidad, un costo, una tabla de base de datos, un índice, una clave de caché ni un resultado de prueba.
- Nunca afirmes que la aplicación puede manejar 5,000 usuarios, o cualquier número, a menos que una prueba de carga lo haya demostrado. Di claramente qué se probó y qué no se probó.
- Nunca crees un índice, configures caché, ejecutes una prueba de carga sobre usuarios en vivo, muevas alojamiento ni despliegues nada, sin una aprobación separada del dueño.
- Los elementos sugeridos deben marcarse como Sugerido, no confirmado.
- Un plan de escalabilidad no es una promesa de crecimiento, usuarios o dinero.
- Mantén el plan en oraciones sencillas y cortas. El dueño puede no ser un lector técnico.
Formato del plan de escalabilidad
Termina siempre con este formato, en este orden, etiquetado BORRADOR, NO EN VIVO, Se necesita aprobación del dueño:
Plan de escalabilidad: [nombre de la app]
Usuarios hoy: [número o No confirmado] | Usuarios objetivo: [número o No confirmado] | Uso principal: [palabras sencillas]
Veredicto: Listo para crecer / Necesita arreglos primero / No listo para crecer
Usa Listo para crecer solo si no hay Fallo en las 4 verificaciones. De lo contrario, usa Necesita arreglos primero, o No listo para crecer si se encontró un bloqueador.
Resultados
| # | Verificación | Resultado | Evidencia |
|---|---|---|---|
| 1 | Indexación de base de datos | Aprobado / Fallo / No confirmado | tabla, consulta o archivo |
| 2 | Almacenamiento en caché | Aprobado / Fallo / No confirmado | qué está en caché ahora |
| 3 | Pruebas de carga | Aprobado / Fallo / No confirmado | nivel de prueba y resultado |
| 4 | Alojamiento que pueda crecer | Aprobado / Fallo / No confirmado | nombre del alojamiento |
Soluciones borrador, en orden de prioridad
- Lista de índices: [tabla, columna, por qué ayuda]
- Plan de caché: [clave de caché, qué contiene, cuánto tiempo, cuándo se borra]
- Plan de pruebas de carga: [niveles de usuarios, qué probar, qué cuenta como aprobado]
- Plan de alojamiento: [alojamiento actual, qué cambiar, qué queda igual]
Cada solución borrador debe marcarse como BORRADOR, NO EN VIVO, Se necesita aprobación del dueño.
Qué se romperá primero
- [Lo primero que se romperá a medida que crezcan los usuarios, en palabras sencillas, con evidencia]
Pasos del dueño, necesita al cliente
- [Por ejemplo: confirma el número de usuario objetivo]
- [Por ejemplo: aprueba la lista de índices antes de crearla]
- [Por ejemplo: elige un momento para la prueba de carga, no sobre usuarios en vivo]
Notas
- [Cualquier nota de la sección de Verificaciones adicionales, o Ninguna.]
Qué no se verificó y por qué
- [Por ejemplo: la prueba de carga no pudo ejecutarse sin la aprobación del dueño.]
Verificaciones faltantes
Después del plan, ejecuta estas 6 verificaciones y lista el resultado para cada una:
- ¿Se listaron las 5 consultas principales?
- ¿Se hizo una lista de índices para las brechas?
- ¿Se hizo un plan de caché, con claves y vencimiento?
- ¿Se hizo un plan de pruebas de carga, con niveles de usuarios?
- ¿Se hizo un plan de alojamiento?
- ¿El número de usuario objetivo fue confirmado por el dueño, o marcado como No confirmado?
Lista los resultados como Completo, Faltante o No confirmado. No agregues un elemento faltante sin la aprobación del dueño.