30 días de MVP: semana 1 = definición + arquitectura, semana 2 = core funcionalidad, semana 3 = flow completo end-to-end, semana 4 = pulido + deploy. Regla dura: no sumamos ni una feature que no tenga que ver con validar la hipótesis principal. El resto queda para v1.1.
Qué es y qué NO es un MVP
Un MVP es la versión más chica de tu producto que ya prueba algo real con usuarios reales. No es una demo, no es un prototipo bonito, no es un pitch deck con capturas de Figma.
Qué SÍ es:
- Un usuario real puede registrarse
- Puede hacer la acción principal (comprar, reservar, publicar, buscar)
- Recibís data real de uso (analytics, logs, feedback)
- Cobrás plata real si el modelo lo requiere
Qué NO es: un MVP con 47 features, dashboards múltiples, roles complejos y admin panel de 200 pantallas. Eso ya es un producto — que si no vende, tirás 6 meses de trabajo.
Semana 1 · Definición + arquitectura
El primer día no se toca código. Definimos:
- La hipótesis principal: ¿qué querés validar en 30 días? Ej: "la gente paga por acceso premium a X"
- Métrica de éxito: ¿cómo sabés si funcionó? Ej: "10 pagos reales en las primeras 2 semanas"
- Feature list ULTRA acotada: las 5-7 features indispensables. Nada más.
- Stack: elegís tecnologías que conocés + servicios administrados (no armes tu propio Auth, usá Clerk/Supabase; no montes DB compleja, usá Cloudflare D1)
El resto de la semana: setup de infra (dominio, hosting, DB, auth, pagos si aplica), diseño rápido de las 5-7 pantallas principales en Figma o directamente en HTML.
Semana 2 · Core funcionalidad
Aca se construye el corazón del producto. La acción principal de un usuario tiene que funcionar end-to-end antes de agregar cualquier otra cosa.
Regla dura: si aparece una idea nueva que "queda mejor", va a un doc separado llamado 'v1.1'. NO se implementa. Es la parte más difícil, sobre todo si el cliente empuja.
Al final de esta semana, un usuario tiene que poder hacer el flujo core sin ver errores. La UI puede ser fea, pero funcional.
Semana 3 · Flow completo end-to-end
Ahora vamos por los flujos secundarios que sostienen el core:
- Onboarding (registro + primer uso guiado)
- Pagos o suscripción (si aplica)
- Notificaciones (email transaccional + WhatsApp si aplica)
- Panel admin básico (para ver qué está pasando)
- Analytics (GA4 o similar) para medir uso real
Al final de esta semana, el producto está "vivo" — un usuario random puede usarlo sin ayuda tuya.
Semana 4 · Pulido + deploy
Los últimos 7 días son para ajustar UX, arreglar bugs críticos, mejorar textos, optimizar performance, y preparar el lanzamiento.
Qué NO hacer en la semana 4: agregar features nuevas. Es la trampa más común. Si algo aparece "tiene que estar" a esta altura, va a v1.1.
Las 5 trampas que matan un MVP
Después de armar varios, estas son las que vemos siempre:
- Feature creep: el cliente suma "solo una cosita más" durante 4 semanas y termina siendo un producto de 3 meses
- Overengineering: "por si escalamos, meto microservicios y Kubernetes" — no. Cloudflare Workers + D1 + R2 aguanta más usuarios que los que vas a tener en el primer año
- Diseñar antes de validar: pasar 2 semanas en Figma para tener "la UI perfecta" es lujo de producto ya validado
- No tener métricas: lanzar sin analytics es lanzar a ciegas — no vas a saber si funcionó ni por qué
- Postergar el pricing: si es pago, cobrale desde el día 1. Si no cobra, no valida nada.
"Un MVP feo que vende vale más que un producto hermoso que nadie usa."