Llega una cotización para un marketplace con reservas y el presupuesto disponible es de USD 800. El rango referencial de esa versión mínima va de USD 2.000 a 6.000 sin IVA. La diferencia no es un error de cálculo del cliente: es lo normal, y ocurre porque la solicitud se escribió como la lista de todo lo que el sistema debería hacer algún día, no de lo que debe hacer el primer día.
La respuesta correcta en ese caso no es bajar el precio ni recortar calidad. Es volver a repartir el alcance. Un MVP por módulos consiste en dividir el sistema en unidades que se pueden construir, entregar y usar por separado, y luego decidir cuáles entran en la primera versión y cuáles esperan. Este artículo explica el criterio con el que se hace ese reparto, cuál módulo debe ir primero y cómo se decide, con argumentos y no por intuición, qué queda fuera.
¿Qué significa partir un sistema en módulos?
Un módulo es una porción del sistema que un usuario puede usar de principio a fin sin que exista el resto. Esa es la definición operativa de un MVP por módulos y el error más común es confundir módulo con capa técnica: la base de datos no es un módulo, ni el diseño. Son partes transversales que se necesitan completas desde el inicio.
En un MVP por módulos el corte correcto es vertical, no horizontal. Un módulo atraviesa interfaz, lógica y datos para resolver una tarea concreta: publicar un servicio, reservar una fecha, cobrar. Si una porción del alcance no se puede poner en producción sola, no es un módulo y no sirve para repartir presupuesto. Si ya conoce el concepto general, puede repasarlo en nuestro artículo sobre qué es un MVP y cómo lanzar una startup en Ecuador. Aquí entramos directo al reparto.
Cómo se reparte el alcance, paso a paso
El reparto de un MVP por módulos tiene seis pasos y ninguno requiere conocimientos de programación. Se hace en una reunión de dos a tres horas con las personas que van a usar el sistema.
- Escribir lo que el sistema debe hacer en frases de usuario. Una línea por cada cosa, en lenguaje del negocio: “el cliente reserva una fecha y recibe la confirmación”, no “módulo de reservas con notificaciones”.
- Clasificar cada frase con MoSCoW. El método del Agile Business Consortium ordena los requerimientos en Must Have, Should Have, Could Have y Won’t Have this time. La última categoría es la útil: obliga a declarar en voz alta lo que no se hará ahora.
- Agrupar los Must Have en módulos verticales. Cada grupo debe pasar la prueba: si se construyera solo, alguien podría usarlo para algo real.
- Ordenar los módulos por retorno, no por pantalla. El primero es el que genera ingreso o elimina la tarea manual más costosa, no el que luce mejor en una demostración.
- Estimar módulo por módulo y cortar contra el presupuesto real. Aquí aparece la cifra incómoda, mejor en esta reunión que en el mes cuatro.
- Fijar la Definición de Terminado antes de construir. El Scrum Guide es claro: sin criterio acordado de antemano, nadie puede verificar si un módulo está listo o solo parece listo.
Cuál módulo va primero
La regla de decisión de un MVP por módulos es corta: va primero el módulo que cumple las tres condiciones a la vez. Que toque el ingreso o quite trabajo manual. Que funcione sin los demás. Que se pueda probar con usuarios reales en menos de un mes. Si un módulo falla una de las tres, no es el primero, por importante que parezca.
Con un marketplace con reservas, el MVP por módulos queda repartido así. La tabla sirve como plantilla para cualquier sistema con varios actores.
| Módulo | ¿Primera versión? | Razón | Mientras no exista |
|---|---|---|---|
| Catálogo público con ficha de servicio | Sí | Es lo único que un comprador necesita para decidir | No aplica, es la base |
| Disponibilidad y reserva con confirmación manual | Sí | Captura el pedido, que es el momento del ingreso | No aplica, es la base |
| Registro y panel del proveedor | No | Con pocos proveedores, el equipo publica por ellos | Formulario y carga manual del administrador |
| Pago en línea | Depende | Solo si el comprador no concreta sin pagar antes | Transferencia o enlace de pago enviado a mano |
| Comisiones y liquidaciones automáticas | No | Depende de un volumen que todavía no existe | Hoja de cálculo mensual |
Qué queda fuera y cómo se decide
Un módulo sale del MVP por módulos cuando cumple al menos una de estas cuatro condiciones. El criterio hay que aplicarlo por escrito, porque de lo contrario cada reunión reabre la discusión.
- Se puede hacer a mano el primer trimestre. Si una persona cubre la tarea en menos de dos horas por semana, automatizarla ahora es gasto adelantado.
- Depende de un volumen que todavía no existe. Las liquidaciones automáticas y los paneles de métricas necesitan datos acumulados; sin ellos se construye sobre supuestos.
- No cambia la decisión de compra del usuario. Si el comprador compra igual sin ese módulo, el módulo no es del MVP.
- Su alcance aún no está decidido. Un módulo que el equipo interno todavía discute no se cotiza: espera hasta que haya acuerdo.
Cada módulo se entrega con su código fuente. La propiedad del código es del cliente y debe quedar por escrito en el contrato, con transferencia de derechos patrimoniales y acceso al repositorio desde la primera entrega. Un MVP por módulos sin esa cláusula deja a la empresa atada al proveedor en el momento de mayor dependencia.
Casos por sector
Una academia de formación técnica de Ambato pide una plataforma de cursos con pagos, certificados, foros y seguimiento de progreso. Su MVP por módulos entrega catálogo y matrícula con pago por transferencia verificada a mano, certificados en PDF desde una plantilla, y deja los foros fuera.
Una importadora de autopartes de Guayaquil quiere un portal de pedidos con crédito, cupos y despachos. La primera versión es el catálogo con stock y precio por lista de distribuidor; el cupo de crédito se consulta por teléfono y el módulo de cartera entra en la segunda etapa.
Una clínica privada de Quito solicita agenda, historia clínica y facturación. La primera versión es la agenda con recordatorios, que libera horas de recepción desde la primera semana; la historia clínica espera a que el personal confíe en el sistema. El patrón está en nuestra guía de sistemas a medida.
Precios: qué alcanza cada presupuesto
Los rangos corresponden a la tabla oficial de Blue Nova Consulting, verificada en octubre de 2026, y están expresados sin IVA. Al facturar se suma el 15% vigente. La referencia completa está en la página de precios.
| Alcance | Inversión referencial (sin IVA) | Qué entra en la primera versión |
|---|---|---|
| PWA o aplicación web sencilla | USD 1.500 a 4.000 | Uno o dos módulos, un solo tipo de usuario |
| Marketplace con reservas, versión mínima | USD 2.000 a 6.000 referencial | Catálogo y reserva, con gestión manual detrás |
| Aplicación móvil con acceso y panel | USD 4.000 a 8.000 | Dos o tres módulos y panel de administración |
| Reservas, pedidos o gestión interna | USD 6.000 a 15.000 | Flujo completo con roles y reportería básica |
| Marketplace o plataforma con varios roles | USD 12.000 a 30.000 o más | Varios actores, pagos y liquidaciones |
| Sistema empresarial a medida | USD 20.000 a 50.000 o más | Integraciones con los sistemas de la empresa |
Sobre el caso del inicio: con USD 800 no se construye un marketplace con reservas ni como MVP por módulos. Lo que sí cabe en ese orden de magnitud es una página de catálogo con formulario de solicitud, que valida si existe demanda antes de invertir los USD 2.000 a 6.000 de la versión mínima.
Plazos por módulo
| Periodo | Qué ocurre | Qué recibe usted |
|---|---|---|
| Semana 1 | Reparto del alcance y clasificación MoSCoW | Lista de módulos priorizada y lo que queda fuera |
| Semana 2 | Estimación por módulo y corte contra presupuesto | Cotización del primer módulo con precio cerrado |
| Semanas 3 a 7 | Construcción del primer módulo | Módulo en producción y repositorio entregado |
| Desde la semana 9 | Segundo módulo, ya con evidencia | Alcance ajustado por lo que mostró el primero |
Preguntas frecuentes
¿Se puede hacer un marketplace con USD 800?
No. El rango referencial de la versión mínima va de USD 2.000 a USD 6.000 sin IVA, y por debajo no entra ni el módulo de reservas completo. Con USD 800 sí cabe una página de catálogo con formulario de solicitud, útil para medir demanda antes de invertir.
¿Qué pasa si el presupuesto no alcanza ni para el primer módulo?
Se reduce el módulo, no la calidad, y eso es exactamente lo que permite un MVP por módulos. Un módulo de reservas con confirmación manual por correo cuesta una fracción de uno con pagos, cupos y cancelaciones automáticas, y captura exactamente el mismo pedido. Lo que no se debe hacer es construir la mitad de todos los módulos.
¿Un MVP por módulos sale más caro al final?
Puede costar entre 10% y 20% más que construirlo todo de una vez, por el trabajo de integración repetido. En cambio evita el gasto más caro, que es pagar módulos que nadie usa, y ese ahorro suele superar el sobrecosto.
¿De quién es el código de cada módulo entregado?
Del cliente. La transferencia de derechos patrimoniales sobre el código fuente, la base de datos y la documentación debe constar por escrito en el contrato, con entrega del repositorio al cierre de cada módulo y credenciales a nombre de la empresa.
¿Cómo se evita que la primera versión quede inservible?
Con la prueba de uso completo: un usuario real debe cumplir una tarea de inicio a fin sin intervención del equipo técnico. Si para completar una reserva alguien tiene que entrar a la base de datos, el módulo no está terminado.
¿Los precios incluyen IVA?
No. Todos los rangos están sin IVA y al facturar se suma el 15% vigente en Ecuador. Los descuentos por permanencia aplican solo a los servicios de CRM.
Artículos relacionados
- Proyecto de software por fases: contratar sin arriesgar: contrate un proyecto software por fases: diagnóstico con precio cerrado.
- Sistema caído y no puedo facturar: plan de contingencia: si el sistema se cayó y no puede facturar.
- Base de datos corrupta: protocolo de emergencia paso a paso: base datos corrupta empresa: qué hacer en los primeros cinco minutos.
Fuentes consultadas
- Agile Business Consortium, What is MoSCoW Prioritization: definición de Must Have, Should Have, Could Have y Won’t Have this time.
- The Scrum Guide, Ken Schwaber y Jeff Sutherland: Definición de Terminado e incremento entregable.
- SENADI, Derecho de autor y derechos conexos: derechos patrimoniales transferibles frente a derechos morales inalienables.
- Superintendencia de Protección de Datos Personales, Normativa: LOPDP y su Reglamento General, aplicables a los módulos que tratan datos de usuarios.
Siguiente paso
Si tiene una lista de requerimientos y un presupuesto que no cuadra, el ejercicio útil es armar el MVP por módulos antes de pedir cotizaciones. Revise los rangos en la página de precios, vea sistemas comparables en aplicaciones móviles y en el portafolio, y escríbanos desde contáctanos con su lista tal como está.
Blue Nova Consulting
¿Quiere aplicar esto en su empresa?
Revisamos su situación y le decimos qué corresponde hacer primero y qué puede esperar.
Los valores que aparecen en este artículo son referenciales y no incluyen el IVA del 15 por ciento.
Sigue leyendo
Comentarios y opiniones
0 comentarios · Moderación previa
Cuéntanos tu experiencia, dudas o casos similares. Revisamos cada comentario antes de publicarlo para mantener conversaciones de calidad. También puedes suscribirte para recibir nuevos artículos.