El error más caro en el desarrollo de producto
El error más caro que veo en startups no es elegir el stack equivocado ni contratar al developer equivocado. Es construir demasiado antes de saber si alguien lo quiere. Me llegaron clientes con 6 meses de desarrollo, $30.000 USD gastados, y cero usuarios. El producto tenía 40 features. Necesitaban 3.
Un MVP no es un producto malo. Es un producto enfocado. Su único objetivo es validar una hipótesis con el menor costo posible.
Semana 1: definición de alcance (la más importante)
Antes de escribir una línea de código, dedico la primera semana a entender qué es lo que realmente necesita validarse. Las preguntas que hago:
- ¿Cuál es el problema central que resuelve este producto?
- ¿Quién es el usuario que más sufre ese problema hoy?
- ¿Qué es lo mínimo que tiene que funcionar para que ese usuario diga "esto me sirve"?
- ¿Qué features son "nice to have" disfrazadas de necesidades?
El output de esta semana es una lista de exactamente 3 a 5 features que van al MVP. Todo lo demás va a un backlog explícito. Cuando el cliente quiere agregar algo en este punto, la conversación es: "¿Esto ayuda a validar la hipótesis principal? Si no, va al backlog."
Semana 2-3: construcción del core
Con el alcance claro, la construcción es mucho más rápida de lo que la mayoría espera. Mi stack para MVPs rápidos:
- Backend: Node.js + Express + MongoDB. Sin microservicios, sin arquitecturas complejas. Un monolito limpio es perfectamente válido para un MVP.
- Frontend: React + Vite + Tailwind CSS. Componentes reutilizables, sin sobre-ingeniería.
- Auth: JWT simple o incluso magic links para evitar la fricción de registro.
- Deploy: Vercel para frontend, Railway o Render para backend en MVP. AWS viene después.
Lo que NO construyo en un MVP: sistema de notificaciones complejo, onboarding elaborado, dashboard de analytics interno, múltiples roles de usuario, internacionalización.
Semana 4: testing, deploy y primeros usuarios
La semana 4 no es solo "deploy". Es preparar el terreno para aprender:
- Deploy en producción con dominio real.
- Analytics básico (Google Analytics o propio) para ver qué hacen los usuarios.
- Sesiones de usuario: onboardear manualmente a los primeros 5-10 usuarios y observar cómo usan el producto.
- Un canal directo de feedback (WhatsApp, Typeform, lo que sea).
Cómo medir si el MVP cumplió su función
Un MVP no es un éxito o fracaso por la cantidad de usuarios. Es un éxito si te da información clara para tomar decisiones. Las preguntas post-lanzamiento:
- ¿Los usuarios completaron el flujo principal?
- ¿Volvieron a usarlo al día siguiente?
- ¿Recomendarían el producto aunque sea incompleto?
- ¿Qué feature pedían que no estaba?
Con esa información, la decisión es: pivotar, iterar o escalar. Las tres son respuestas válidas. La única respuesta inválida es seguir construyendo features sin datos.