Cuánto tarda un MVP de software en Perú

Un MVP —producto mínimo viable— es la menor cantidad de software que un usuario real puede usar para completar un proceso y darte retroalimentación. No es “la app completa pero fea”, ni la demo que funciona solo en la laptop del desarrollador. Si tu MVP no puede responder una pregunta de negocio concreta —¿la gente va a pedir citas por este canal?—, no es un MVP: es un prototipo caro.

¿Por qué el plazo? Porque dos meses es lo que tarda un equipo pequeño en construir, desplegar y corregir un flujo, y es también lo que tarda un mercado en decirte si vas bien. Cuando un “MVP” se presupuesta en seis meses, casi siempre significa que alguien tiene miedo de preguntarles a los usuarios temprano. Las metodologías ágiles existen precisamente para eso; hay buenas introducciones públicas en la biblioteca ágil de Atlassian.

La otra cara del plazo es el costo: cada semana extra de equipo en proyecto es plata, y en Perú el trabajo se paga en soles mientras la competencia no se toma vacaciones. El recorte del alcance es la decisión más rentable del proyecto.

¿Cómo sabes si tu alcance ya es MVP o todavía es un sistema completo disfrazado? Aplica la prueba de la frase única: si no puedes describir el producto en una oración que empiece con “cualquier [usuario] puede [hacer X proceso] desde [canal]”, hay dos proyectos peleándose adentro. En esa discusión se ganan o se pierden semanas; mejor pelearla en la semana uno, con lápiz, que en la semana doce, con dinero.

Este es el desglose que usamos para planificar, con la premisa de un flujo principal y un equipo de dos a tres personas. Las etapas no son cascada: diseño y primer sprint se solapan, y por eso el total es menor que la suma de las partes.

Si tu MVP incluye autenticación con DNI, pagos o emisión de comprobantes, agrega una semana de colchón por cada integración: los ambientes de prueba de terceros no responden a tu calendario.

Scrum no hace el trabajo más rápido; hace que el retraso sea visible temprano, que es distinto y más valioso. Cada dos semanas hay algo desplegado —aunque sea interno— y una revisión con el negocio. Si en el primer mes no puedes mostrar progreso, el alcance estaba mal cortado, y eso es información que en cascada descubrirías al sexto mes.

La estimación dentro de los sprints sigue métodos públicos y probados: puntaje de historias, velocidad del equipo y un backlog priorizado. Scrum Guides publica la guía oficial del framework en español, y en la guía de estimación ágil de Atlassian está el detalle de cómo se puntúa sin adivinar. Nosotros traducimos eso a una regla simple: lo que no entra en dos semanas de sprint, se parte o se sale.

El segundo efecto de los sprints es psicológico y económico: cada despliegue quema supuestos incorrectos con plata tuya, no con las del presupuesto completo. Un MVP ágil no es un proyecto corto; es un proyecto que sabe temprano que debería ser más corto (o distinto).

Fuera del MVP, los plazos se miden en meses y se explican por el mismo motivo: un ERP no se demora por “dibujar pantallas”, se demora por datos, permisos, excepciones y capacitación. Un módulo de compras que parece dos semanas de código esconde cuatro meses de reglas que nadie escribió.

Referencias realistas para Perú: un ERP o CRM por módulos toma de 3 a 9 meses, con el primer módulo productivo entre el mes dos y el cuatro. Un SaaS con facturación, multitenancy y panel de administración, de 4 a 6 meses hasta el primer cliente de pago. Una app iOS y Android con backend, de 2 a 4 meses si el flujo principal es uno, y de 4 a 6 si hay dos plataformas con lógica distinta.

Lo que más comprime estos plazos no es programar más rápido: es decidir antes. Cada semana que una pantalla espera una aprobación de tres jefes es una semana de calendario y de plata. Define un solo dueño de producto con facultad de decidir antes de arrancar, y el cronograma deja de ser ficción.

Un truco de planificación que funciona bien con ERPs: tratar cada módulo como un mini-MVP con su propia fecha de entrada en producción. Compras primero, inventario después, producción al final. Así el negocio ve valor en el mes dos en vez de todo en el mes ocho, y tú descubres los datos sucios módulo por módulo, con presupuesto para limpiarlos, no todos juntos el día del apagón.

Los retrasos casi nunca nacen en el desarrollo. Nacen en cinco lugares predecibles, y todos se pueden negociar desde el día uno con nombre y fecha:

Nota el patrón: cuatro de los cinco son decisiones o accesos del cliente, no del equipo. Por eso en Bytes pedimos los accesos de prueba y el dueño de producto antes de firmar, y por eso un proyecto que no puede mostrar algo desplegado en su primer mes casi nunca se recupera en el tercero.

• Datos sin dueño: nadie puede decir si el Excel viejo es la verdad o la mitad de la verdad.
• Accesos a sistemas heredados que tardan semanas en aprobarse (y no deberían).
• Comités: cinco aprobadores sin voto; cada reunión de alineamiento es medio sprint.
• Cambios de alcance sin recálculo de precio y fecha: el “pues ya que estamos” es el enemigo.
• Pruebas externas: calendarios de SUNAT o del banco corren a otro ritmo que tu sprint.
• Estacionalidad peruana: feriados, carnavales, Fiestas Patrias y la quincena vacacional de diciembre.

Sí, y es la única forma seria de trabajar con fechas imposibles. Si necesitas estar operativo para una feria en octubre, un cierre tributario o la temporada, dilo al inicio: el calendario manda el recorte del alcance, no al revés. Lo que no se puede mover es la fecha; lo que se negocia es cuánto producto entra en esa fecha.

Para casos tributarios, ten en cuenta que los cronogramas y ambientes de prueba de SUNAT tienen su propio calendario, publicado en sus guías y manuales de comprobantes electrónicos. Un proyecto que emite comprobantes debe reservar sus últimas semanas para pruebas de certificación y contingencia; eso no se puede comprimir en la semana del lanzamiento.

¿Y cuánto cuesta apurar un MVP con fecha? Generalmente se resuelve recortando flujos, no sumando gente: agregar personas a un proyecto tarde cuesta más de lo que ahorra. Si quieres los números antes de comprometerte con tu directorio, la guía de cuánto cuesta un software a medida en Lima tiene los rangos en soles.