¿Cuánto se tarda en desarrollar un MVP? Plazos reales por tipo de producto

La complejidad es el mejor indicador del plazo de un MVP. Al presupuestar proyectos usamos tres niveles.

Los mismos niveles fijan el presupuesto. Nuestro análisis de cuánto cuesta un MVP SaaS muestra el rango de precio de cada uno.

Los tipos de producto encajan en esos niveles de forma bastante previsible. Esta tabla muestra dónde suelen caer los MVP más comunes; el suyo puede subir o bajar un nivel según sus detalles.

Una Telegram Mini App suele caer en el nivel sencillo o medio. Se abre dentro de Telegram, así que no hay que publicarla en una tienda de aplicaciones, y la cuenta del usuario viene del propio Telegram.

Todo MVP pasa por las mismas fases, aunque se solapan más de lo que sugiere una lista simple.

• Presupuesto. Su brief se convierte en una propuesta con alcance, plazo y precio. En Sakura, la mayoría de las propuestas salen en 2-3 días hábiles tras recibir un brief completo.
• Diseño. Primero los flujos de usuario, luego pantallas hechas con un sistema de componentes reutilizables y después un prototipo navegable.
• Desarrollo. Frontend, backend e integraciones, con una versión funcional que puede recorrer cada semana.
• Pruebas. Cada flujo en los navegadores y dispositivos acordados, además del rendimiento y la accesibilidad básica.
• Lanzamiento. Despliegue, analítica, envío a la tienda si hay app móvil y las primeras correcciones cuando llegan los usuarios reales.

El diseño y el desarrollo se solapan a propósito. En cuanto se aprueban los primeros flujos, el desarrollo empieza por ellos mientras los demás todavía se diseñan.

El diseño suele empezar antes y terminar antes que el desarrollo, pero ambos no deberían ir uno detrás de otro. Cuando el diseño entrega un archivo terminado y se desentiende, el desarrollo a menudo descubre pantallas caras de implementar, y se pierden semanas rehaciendo trabajo.

La solución es diseñar con los mismos componentes que construirán los desarrolladores. Así, una pantalla aprobada ya está casi construida, y las dudas se resuelven cuando aún es barato.

Por ejemplo, AutoIntel, una herramienta B2B para el mercado alemán de coches usados, empezó con el diseño de producto y un prototipo interactivo con anuncios de muestra. El cliente recorrió el prototipo con su equipo y decidió qué campos y filtros importan antes de presupuestar la recolección de datos. Ese orden mantiene la parte más cara del desarrollo centrada en lo que la interfaz realmente necesita.

¿Está planificando una fecha de lanzamiento? Envíenos un brief breve y le diremos en qué nivel cae su producto y qué plazo es realista.

Algunas funciones parecen pequeñas en el brief y añaden semanas al desarrollo. Estas son las que conviene vigilar:

• Integraciones. Pagos, proveedores de inicio de sesión, CRM y API externas: cada una suma configuración, manejo de errores y pruebas.
• Roles y permisos. Cada rol adicional multiplica los estados que tiene que manejar cada pantalla.
• Una app móvil nativa. Añade un segundo frontend y una revisión en la tienda. El App Review de Apple revisa al menos el 50% de los envíos en menos de 24 horas y el 90% en menos de 48 horas, pero un rechazo reinicia el reloj.
• Varios idiomas. Cada texto, mensaje de error y ayuda debe existir en cada idioma, y el diseño tiene que admitir la versión más larga.
• Contenidos tardíos. Los textos, precios, documentos legales y datos reales que llegan la última semana bloquean las pruebas.
• Decisiones lentas. Una pregunta que espera una semana su respuesta retrasa todo lo que se construye encima.

El plazo de un MVP se acorta haciendo menos, no haciéndolo peor. Estas decisiones son las que más tiempo ahorran:

• Recorte flujos completos, no el acabado. Pase los flujos secundarios a una versión posterior en lugar de construir cada flujo a medias.
• Lance primero en la web. Una web app adaptable llega a usuarios de móvil y escritorio y evita la revisión de las tiendas.
• Use servicios probados. Una página de pago alojada, proveedores de inicio de sesión y servicios de correo existentes son más rápidos y seguros que versiones propias.
• Decida rápido. Nombre a una persona que pueda aprobar diseños y responder preguntas en el mismo día.
• Pruebe pronto con pocos usuarios. La investigación de Jakob Nielsen mostró que probar con 5 usuarios revela la mayoría de los problemas de usabilidad, así que varias rondas pequeñas superan a una grande.

CarPixly, un estudio fotográfico con IA para anuncios de coches, publicó la versión de Android como APK en su propia página de descarga mientras la versión de iOS seguía en camino. Lanzar donde se puede y añadir plataformas después suele ser el camino más rápido hacia usuarios reales.

Las primeras semanas van más rápido si algunas cosas están listas antes del arranque. Ninguna requiere conocimientos técnicos:

• Una lista corta de flujos principales. Las una a tres tareas que los usuarios deben poder hacer en el lanzamiento, en palabras sencillas.
• Una persona que decida. Alguien que pueda aprobar diseños y responder preguntas en el mismo día.
• Acceso a las cuentas existentes. Dominio, alojamiento, analítica, proveedor de pagos y cualquier API que ya utilice.
• Contenidos reales, o una fecha para tenerlos. Textos, precios, páginas legales y datos de muestra que mostrará el producto.
• Su condicionante de lanzamiento. El evento, la reunión con inversores o la temporada que hacen importante la fecha.

Con esto a mano, el presupuesto lleva días en lugar de semanas, y el diseño puede empezar con contenidos reales en lugar de textos de relleno.

Los plazos rara vez se retrasan porque los desarrolladores escriban despacio. Se retrasan por decisiones tomadas, o no tomadas, alrededor del desarrollo:

• Un alcance que crece a mitad del proyecto sin un proceso de cambios por escrito.
• Rondas de comentarios que tardan una semana en lugar de un día.
• Una definición de «terminado» que nadie escribió, de modo que las últimas semanas se convierten en una discusión.
• Integraciones previstas como una línea del alcance en lugar de con sus casos límite reales.

Un alcance cerrado con un proceso de cambios mantiene casi todo esto bajo control. Explicamos cómo en precio cerrado o por horas.

El lanzamiento pone en marcha un segundo reloj, no detiene el primero. Las primeras semanas tras la publicación suelen ser las de más trabajo de todo el proyecto.

Los usuarios reales encuentran errores que las pruebas no detectaron, piden pequeños cambios y usan el producto de formas que nadie había previsto. Reserve justo después del lanzamiento un periodo corto de correcciones y mejoras rápidas, antes de cualquier función nueva.

Después, el trabajo pasa a un ritmo estable: un plan mensual de mejoras basado en lo que muestra el uso real. Cada proyecto de Sakura incluye un periodo de garantía definido para corregir errores, y el trabajo posterior puede seguir con un plan mensual o pasar a su propio equipo.

Lo menos posible, siempre que siga poniendo a prueba su hipótesis principal. El sentido de un MVP, en palabras de Lean Startup, es «empezar a aprender lo más rápido posible».

Si su plan supera con creces el nivel complejo, pregúntese qué quiere aprender y si un producto más pequeño podría enseñarle lo mismo. A menudo, un solo flujo lanzado antes responde a la pregunta que más importa.

Cuando quiera planificar el suyo, cuéntenos sobre su producto. Recibirá una propuesta con alcance, plazo y precio cerrado, y cada semana una versión para ver cómo va tomando forma.