El problema que todos conocen pero pocos nombran
Cuando alguien llega con una idea de software, lo primero que hacen la mayoría de las agencias es agendar reuniones. Una, dos, tres. Cada semana hay una nueva ronda de preguntas, nuevos documentos de requerimientos, nuevos ajustes al presupuesto. Y cuando el cliente pregunta cuándo va a ver algo funcionando, la respuesta siempre es vaga.
El resultado: proyectos que tardan meses en arrancar, clientes frustrados y equipos que trabajan sobre supuestos en lugar de hechos. Nosotros pasamos por eso, lo vimos en otros equipos y decidimos que había una forma mejor.
Nuestra definición de MVP
Antes de hablar del proceso, hay que alinear qué entendemos por MVP. No es un prototipo con clics en Figma. No es una demo sin base de datos. Es el sistema mínimo que permite a un usuario real completar el flujo principal y generar valor concreto, ya sea ahorrando tiempo, procesando un pago o tomando una decisión con datos.
Todo lo que no sea ese flujo principal es ruido por ahora. Y separar señal de ruido es exactamente lo que hacemos en el levantamiento.
Principio clave
"Un MVP que llega tarde y con todo es menos útil que uno que llega a tiempo con lo justo."
Las 3 semanas: semana a semana
- Una sola sesión de 90 minutos con el cliente o founder.
- Mapeamos el flujo principal en un diagrama simple: quién hace qué, cuándo y por qué.
- Identificamos las 3 decisiones técnicas críticas (autenticación, modelo de datos, integraciones externas).
- Entregamos un documento de 1 página con el alcance del MVP y lo que queda fuera.
- Setup del stack completo: repositorio, CI/CD, entornos de staging y producción.
- Implementación del flujo principal de extremo a extremo, sin UI pulida pero funcional.
- Primera demo interna al finalizar la semana para detectar desviaciones del plan.
- El cliente tiene acceso al staging desde el día 8.
- Refinamiento de UI basado en feedback real del cliente sobre el staging.
- Pruebas de los casos edge más críticos (pagos fallidos, usuarios sin permisos, datos vacíos).
- Configuración de monitoreo básico: logs, alertas y métricas de uso.
- Deploy a producción con checklist de lanzamiento.
Lo que esto requiere del cliente
Este proceso funciona porque le pedimos algo poco habitual al cliente: decisiones rápidas. En el levantamiento inicial, si aparecen dos alternativas, elegimos una en el momento. Si hay dudas sobre el alcance, las resolvemos en la reunión, no en un hilo de correos.
No es para todos. Si el cliente necesita aprobar cada pixel con un comité de 8 personas, este proceso no va a funcionar. Pero si hay un responsable con poder de decisión y voluntad de ejecutar rápido, podemos tener un sistema real en producción en 21 días.
Qué pasa después del MVP
El MVP no es el destino, es el punto de validación. Una vez que hay usuarios reales usando el sistema, aparecen los datos que importan: qué flujo usan más, dónde se atascan, qué funcionalidad piden primero.
Con esa información, el roadmap del producto deja de ser una suposición y se convierte en una decisión basada en evidencia. Y eso vale más que cualquier documento de requerimientos elaborado en el vacío.