El framework de 6 categorías
Cuando evalúo un proyecto, no miro "qué tan grande es" en abstracto. Miro seis dimensiones específicas. Cada una puede ser verde, amarilla, o roja.
La regla es simple: si dos o más dimensiones están en rojo, el proyecto no cabe en 30 días. Punto.
Aquí está la tabla completa. Ve leyéndola con tu proyecto en mente.
| Categoría |
Verde (encaja) |
Amarillo (ajustable) |
Rojo (no encaja) |
| Usuarios |
<1,000 en 6 meses |
1,000-10,000 en 6 meses |
>10,000 desde el día 1 |
| Integraciones |
1-3 APIs conocidas |
3-5 APIs, algunas complejas |
5+ sistemas legacy |
| Datos |
Empezar limpio o migración simple |
Migración de decenas de miles de registros |
Millones de registros de sistemas no documentados |
| Funcionalidad |
3-5 flujos bien definidos |
5-10 flujos relacionados |
20+ features distintas sin núcleo claro |
| Regulación |
Ninguna o básica |
GDPR estándar, reglas locales |
HIPAA, PCI-DSS, regulación financiera fuerte |
| Real-time |
Batch/polling aceptable |
Notificaciones casi-instantáneas |
WebSocket crítico, latencia <50ms |
Cada categoría merece un segundo de explicación. Porque "encaja en verde" se siente obvio hasta que lo miras de cerca.
Categoría 1: Usuarios
No es solo cuántos usuarios tienes hoy. Es cuántos esperas en los primeros 6 meses de operación.
La diferencia importa porque la arquitectura para 500 usuarios es fundamentalmente distinta a la arquitectura para 50,000. No es cuestión de "escalar después" — las decisiones de base de datos, cache, y división de servicios se toman al principio.
Si estás lanzando un MVP para validar con 100-500 usuarios beta, estás en verde. Si necesitas soportar 50,000 usuarios concurrentes desde el día uno (piensa marketplaces con campaña publicitaria nacional), estás en rojo.
Categoría 2: Integraciones
Cada integración que tu producto necesita con un sistema externo es trabajo. APIs de pagos (Stripe, Conekta, OpenPay), notificaciones (Twilio, SendGrid), autenticación social, CRMs, ERPs — cada una se integra, se prueba, y se maneja para errores.
Uno a tres APIs conocidas y bien documentadas encajan fácil. Cinco o más, especialmente si incluyen sistemas legacy sin documentación pública (el ERP interno de la empresa, el sistema viejo del contador), es rojo. No porque sea imposible — es porque el tiempo de descubrir cómo funcionan esos sistemas se come el sprint.
Categoría 3: Datos
Los Excels bonitos y bien estructurados se migran en horas. La base de datos de un sistema que lleva 15 años acumulando casos raros, reglas de negocio implícitas, y campos vacíos con "lógica escondida" — esa migración puede tomar más que todo el sprint.
Si me dices "tengo 2,000 registros en Excel limpio" — verde. Si me dices "tengo 3 millones de registros en un sistema legacy de 1998 y nadie entiende cómo funciona" — rojo. Lo segundo no es un MVP; es un proyecto de migración que merece su propio sprint separado.
Categoría 4: Funcionalidad
Un MVP enfocado en un solo cuello de botella tiene típicamente 3-5 flujos de usuario bien definidos. Ejemplo: login, dashboard, crear registro, ver listado, exportar reporte. Eso cabe en 30 días con tiempo de polish.
Veinte features distintas — autenticación social, chat en vivo, sistema de notificaciones push, marketplace interno, sistema de reviews, integración con 5 redes sociales, panel de analytics custom, sistema de membresías con 4 niveles — eso no es un MVP. Es un producto completo comprimido.
La pregunta que uso para distinguir: si solo pudieras entregar UNA cosa en 30 días, ¿cuál sería? Si no puedes contestarla, el scope todavía no está listo.
Categoría 5: Regulación
La regulación fuerte — HIPAA para salud en EEUU, PCI-DSS para manejo directo de tarjetas, regulación CNBV para fintech en México — no se improvisa en 30 días. Cada una agrega semanas o meses de trabajo solo en compliance, auditorías, y documentación.
Si tu producto maneja datos de salud, transferencias financieras reguladas, o información bancaria directa, necesitas un timeline más largo o un approach diferente (por ejemplo: usar proveedores certificados como procesadores en lugar de manejar los datos tú).
Categoría 6: Real-time
Batch processing (los datos se actualizan cada 5 minutos) y polling (el cliente revisa cada X segundos) son suficientes para la mayoría de los productos. Eso es verde.
Pero si tu producto requiere WebSockets con latencia menor a 50 milisegundos — trading algorítmico, videollamadas, juegos multijugador, IoT crítico — la complejidad de infraestructura se multiplica. Eso es rojo para un sprint estándar.
Proyectos que encajan fácil en 30 días
Después de 50+ productos construidos, hay patrones claros. Estos son los proyectos que históricamente encajan en 30 días con cero drama:
Portal de clientes para un negocio de servicios. Login de clientes, dashboard con estatus de sus proyectos/pedidos, sistema de tickets o mensajes, notificaciones por email. Típicamente 3-4 flujos, 2 APIs, datos limpios. Verde en todo.
Herramienta interna para reemplazar un Excel caótico. Base de datos real, formularios de captura con validación, reportes, exportación, roles de usuario. El caso más común en RASS. Verde en todo si el Excel no excede decenas de miles de filas.
SaaS de una sola función. Un producto que resuelve un problema concreto: un generador de cotizaciones, un sistema de reservas para un nicho específico, un tracker de inventario para un tipo de negocio. Cuando el scope está enfocado, cabe.
MVP para validar una idea con usuarios beta. Autenticación, función principal, métricas básicas de uso, deploy en producción. 100-500 usuarios objetivo en los primeros 3 meses. Diseñado para aprender, no para escalar masivamente todavía.
Dashboard de analytics para un negocio específico. Conectado a 1-2 fuentes de datos (Stripe, Google Analytics, un CRM), visualizaciones personalizadas, exportación. Scope acotado = sprint acotado.
En todos estos casos, el patrón es el mismo: un problema central claro, 3-5 flujos bien definidos, datos razonablemente limpios, regulación ligera, y un usuario target concreto.
Proyectos que se pueden reescopear más chico
A veces el proyecto original no cabe, pero una versión más enfocada sí. Este es el escenario más común en las Discovery Calls: la idea tiene potencial, pero el scope inicial es demasiado grande.
Lo que hago en estos casos es aplicar la pregunta del bottleneck: si solo pudieras resolver UNA cosa en 30 días, ¿cuál sería la más valiosa?
Ejemplos reales de reescopeo:
"Quiero construir un marketplace completo con pagos, chat, reviews, y sistema de reputación." → Fase 1: listado y contacto directo sin pagos integrados. Pagos y reviews en Fase 2.
"Necesito un ERP con módulos de ventas, inventario, contabilidad, RRHH, y compras." → Fase 1: solo inventario con movimientos básicos. Los otros módulos, en sprints separados.
"Quiero un producto como Airbnb pero para cabañas en Chiapas." → Fase 1: listado de propiedades + formulario de contacto que manda email al dueño. El sistema de reservas con pagos viene después de validar demanda.
El reescopeo no es "hacerlo menos bonito". Es construir el MVP enfocado en un solo cuello de botella — validar primero que el problema central importa, después agregar capas.
Si llevas meses pensando en construir algo y el scope se sigue expandiendo, probablemente tu proyecto cabe en 30 días — solo no la versión que tienes en la cabeza hoy.
Proyectos que honestamente no encajan
Hay una categoría de proyectos donde el sprint de 30 días simplemente no es la respuesta correcta. Te lo digo porque perder tiempo descubriéndolo después es caro para los dos.
Plataformas con compliance regulado fuerte. Productos que manejan datos médicos protegidos (HIPAA), pagos con tarjeta directos (PCI-DSS nivel 1), o regulación financiera (CNBV, SEC). Necesitas un timeline de 90-180 días mínimo, con tiempo específico dedicado a arquitectura de seguridad y auditoría.
Apps móviles nativas desde cero. Web responsive sí cabe. iOS + Android nativos (Swift + Kotlin) requieren más tiempo, no por la funcionalidad, sino por los procesos de publicación en App Store y Play Store que tienen sus propios timelines.
Migraciones masivas desde sistemas legacy. Cuando el proyecto es 80% migrar datos de un sistema viejo mal documentado al nuevo, el trabajo real es de arqueología de datos, no de construcción. Eso es un proyecto separado.
Plataformas enterprise con múltiples stakeholders. Si tu proyecto requiere aprobación de 10 personas antes de cada decisión, el cuello de botella no es técnico — es de procesos. Un sprint de 30 días necesita decisiones en 24 horas, no en 2 semanas.
Productos con inteligencia artificial custom entrenada. Integrar APIs de IA existentes (OpenAI, Anthropic, etc.) sí cabe. Entrenar un modelo custom con tus datos desde cero es un proyecto de meses, no de semanas.
¿Qué hacer si tu proyecto cae aquí? Tres opciones honestas:
- Scopear una fase 1 más pequeña que sí encaje — y construir el resto en fases siguientes
- Contratar una agencia más grande que pueda dedicar un equipo de 5-8 personas por 3-6 meses
- Construir un equipo interno si el proyecto es central al negocio y necesita mantenimiento continuo
Ninguna de estas tres opciones es "peor" que un sprint de 30 días. Son diferentes para diferentes contextos. La velocidad es la única ventaja competitiva real para una startup — pero solo cuando el proyecto es scopeable para ir rápido. Forzar un proyecto enorme en 30 días es peor que tomarse 4 meses con un equipo adecuado.
Cómo validar tu proyecto en una Discovery Call
Antes de agendar, haz este ejercicio contigo mismo. Toma 10 minutos.
Pregunta 1: ¿Cuál es el UN problema que este software resuelve?
No la lista de features. El problema. Si tu respuesta empieza con "es como X pero para Y", no tienes un problema claro — tienes una comparación. Sigue escarbando hasta llegar a "la gente pierde X horas haciendo Y" o "el negocio pierde $Z al mes porque no existe Z".
Pregunta 2: ¿Cuál sería la UNA función que, si la entregara en 30 días, te daría suficiente valor para justificar el proyecto?
No todas las funciones — una. La que, si la tuvieras funcionando mañana, cambiaría tu operación o tu validación. Esa es tu MVP real. El resto son features que pueden esperar a Fase 2.
Pregunta 3: ¿En cuál color de cuál categoría estás?
Pasa por las 6 categorías del framework. Sé honesto. Si estás en rojo en 2+ categorías, el sprint de 30 días no es la respuesta — y es mejor saberlo antes de agendar que 3 semanas dentro del proyecto.
Si pasaste este filtro y las tres preguntas tienen respuestas claras, probablemente tu proyecto encaja. Agenda la Discovery Call y en 30 minutos te confirmo por teléfono si efectivamente cabe — o te recomiendo otra ruta si no.
Si tu proyecto nació como "quiero salir de Excel" pero creció hasta convertirse en una plataforma completa, este post te puede ayudar a encontrar el scope mínimo viable antes de la llamada.
Un filtro honesto, no una venta
El objetivo de este post no es convencerte de agendar. Es lo contrario: darte el framework para que tú solo decidas si vale la pena hacerlo.
Un prospecto bien filtrado que agenda sabiendo que su proyecto probablemente encaja es un prospecto que llega con expectativas alineadas. Esa Discovery Call es productiva. Produce una propuesta en 48 horas y un proyecto que termina bien.
Un prospecto que agenda con un proyecto que claramente no encaja me consume 30 minutos, le consume 30 minutos, y termina en un "no es un fit" que pudo haberse evitado. Ambos perdemos tiempo.
Por eso este post existe como un paso previo. Úsalo como autoevaluación. Si pasas el filtro, hablemos. Si no, ahorraste tiempo y sabes qué camino tomar.
Agenda una Discovery Call gratuita →
30 minutos. Gratis. Sin compromiso. Si después de aplicar el framework crees que tu proyecto encaja, agendemos. Si ya sabes que no — no lo hagas, y hazme saber qué ruta tomaste. Siempre es valioso saber.
Sobre el autor: Ramm Alvarez es un Solutions Architect con más de 10 años de experiencia. Durante 6 años tuvo su propia consultora de software, donde construyó más de 50 productos para 10 industrias diferentes. Los últimos 4 años los pasó como Senior Software Engineer en startups de Estados Unidos, más recientemente arquitectando sistemas de pagos globales en Routefusion. Hoy dirige RASS, un estudio de desarrollo que entrega MVPs listos para producción en 30 días.
