MVP vs. producto completo: cómo lanzar sin quemar el presupuesto

Una empresa decide construir un sistema. Levanta los requerimientos con todas las áreas, arma una lista de 60 funcionalidades, la cotiza y le dicen un número que la deja fría. Entonces alguien propone "hacer un MVP", y en la reunión siguiente esa palabra significa cinco cosas distintas para cinco personas: para el gerente es lo mismo pero más barato, para el proveedor es la mitad del alcance al mismo precio, y para el equipo de operaciones es un sistema incompleto que igual tendrán que usar. Ese malentendido cuesta caro. Vale la pena aclararlo antes de firmar.

Qué es realmente un MVP (y qué no)

Un MVP —producto mínimo viable— es la versión más pequeña del sistema que igual resuelve el problema completo para un grupo acotado de usuarios reales. La palabra clave es "viable": alguien tiene que poder usarlo de punta a punta y obtener el resultado que buscaba. Si tu bodeguero no puede completar una recepción de mercadería sin volver al Excel, eso no es un MVP: es un sistema a medio construir.

La confusión habitual es recortar en profundidad cuando había que recortar en amplitud. Un MVP bien definido hace menos cosas, pero las que hace las hace enteras. Un mal MVP hace todas las cosas a medias, y el resultado es un sistema que nadie adopta y que obliga a mantener el proceso viejo en paralelo — es decir, el peor de los dos mundos, pagando por ambos.

La regla práctica que uso al definir alcance: si sacas una funcionalidad y el usuario todavía puede terminar su trabajo, sácala. Si al sacarla el usuario queda a mitad de camino, se queda.

Cuándo conviene partir con un MVP

El MVP es una herramienta para reducir incertidumbre, no un descuento. Tiene sentido cuando efectivamente hay algo que no sabes:

• No sabes si la gente lo va a usar. Un portal para clientes, una app para proveedores, cualquier cosa cuyo éxito dependa de que alguien fuera de tu empresa cambie su forma de trabajar. La adopción es una apuesta, y conviene apostar poco al principio.
• El proceso no está definido del todo. Si internamente cada sucursal hace las cosas distinto y nadie se pone de acuerdo, construir "el sistema definitivo" es codificar una discusión no resuelta. Un MVP en una sucursal ordena la conversación con evidencia.
• El presupuesto viene por etapas. Muy común en pymes de la zona: hay plata para partir ahora y probablemente más el próximo ejercicio, pero no hay cómo comprometer el total. Mejor un primer tramo que funcione que un proyecto grande que se quede a medias cuando se acabe el financiamiento.
• Vas a vender ese software. Si el producto es para el mercado y no solo para tu operación, construir mucho antes del primer cliente pagando es la forma más rápida de gastar bien en algo equivocado.

Cuándo el MVP sale más caro

Esta es la parte que los artículos sobre MVP suelen omitir. Hay escenarios donde partir en chico es directamente peor:

Cuando el proceso ya está resuelto y documentado. Si llevas quince años facturando igual, con reglas claras y un flujo que todos conocen, no hay incertidumbre que reducir. Construirlo en tres tramos solo agrega tres coordinaciones, tres pruebas de usuario y tres puestas en producción para llegar al mismo lugar.

Cuando hay obligaciones normativas de por medio. La emisión de documentos tributarios electrónicos, por ejemplo, no admite versiones parciales: o cumples con lo que exige el SII o no puedes operar. Lo mismo con el tratamiento de datos personales. Ahí el "mínimo" lo define la normativa, no tú — y conviene tenerlo claro desde el diseño, como comento en integrar tu software con el SII, Transbank o tu ERP.

Cuando reemplazas un sistema que ya está operando. Si el nuevo sistema tiene que sustituir a uno existente, un MVP con menos capacidades que el actual no lo puede reemplazar. La migración exige, como mínimo, paridad funcional en lo que la gente usa todos los días.

Cuando el ahorro se lo come la coordinación. En proyectos chicos —digamos, bajo unos dos meses de trabajo— partirlos en fases agrega más costo de gestión del que ahorra. Ahí conviene hacerlo de una.

Los cuatro errores que encarecen un MVP

1. Recortar la calidad en lugar del alcance. "Es un MVP, después lo ordenamos" es la frase que produce sistemas imposibles de mantener. Menos funcionalidades, sí; peor construidas, no. Lo que se hace mal en la etapa uno se paga con intereses en la etapa dos, y quien cobra esos intereses es tu propio presupuesto del año siguiente.
2. Saltarse los respaldos, los accesos y el monitoreo. Se ven como "infraestructura para después", pero un MVP que ya tiene datos reales de clientes es un sistema productivo, con todo lo que eso implica. Y la instalación base de estas cosas es barata al principio y cara de retrofitear.
3. No definir el criterio de éxito antes de lanzar. Si no estableciste qué tiene que pasar para justificar la etapa dos —cuántos usuarios, cuánto tiempo ahorrado, cuántos errores menos—, la decisión de seguir invirtiendo se toma por impresiones. Define dos o tres indicadores medibles y una fecha para evaluarlos.
4. Prometer el resto por escrito. Si el contrato del MVP ya compromete las 60 funcionalidades originales, no hiciste un MVP: hiciste un proyecto grande con pagos diferidos, y perdiste la única ventaja real de partir en chico, que es poder cambiar de opinión con la información que obtuviste.

Cómo se ve en la práctica un buen primer tramo

Un caso típico del Biobío: una empresa de servicios con unos 40 trabajadores en terreno quiere digitalizar el reporte diario de faenas, que hoy va en papel y se transcribe a Excel en oficina. La lista de deseos completa incluye app móvil offline, fotos georreferenciadas, firma del cliente, integración con remuneraciones, panel gerencial y reportes automáticos.

El primer tramo razonable no es "la app pero sin fotos". Es: una cuadrilla, un tipo de faena, el flujo entero — el trabajador reporta desde el celular, el supervisor lo revisa y aprueba, y en oficina aparece consolidado sin transcripción. Seis semanas, un grupo reducido, un proceso real terminado de punta a punta. Si funciona, se amplía a las demás cuadrillas y recién entonces se discute qué sigue: probablemente las fotos, quizás no la integración con remuneraciones, que en la práctica resultó menos urgente de lo que parecía en la reunión inicial.

Ese es el valor concreto: al final del primer tramo tienes un sistema en uso y mejor información para decidir el resto. Sin el tramo, decides con supuestos.

Cómo cotizar sin quedar amarrado

Al pedir propuestas, lo más útil es pedir explícitamente dos cosas separadas: el precio cerrado del primer tramo y una estimación de rango, no comprometida, del resto. Un buen proveedor te dará la primera con confianza y será honesto sobre la incertidumbre de la segunda. Uno que te entregue un número exacto para las 60 funcionalidades sin haber construido nada te está dando una cifra que va a cambiar igual, solo que más tarde y con menos margen de maniobra.

Conviene también dejar por escrito, desde el principio, tres cosas: que el código y los datos son tuyos, que existirá documentación técnica mínima, y que el sistema queda en infraestructura a nombre de tu empresa. No son detalles legales sin importancia: son lo que determina si puedes cambiar de proveedor entre el tramo uno y el dos. En cómo elegir un proveedor de software en regiones desarrollo qué más revisar antes de firmar, y en cuánto cuesta desarrollar software a medida en Chile cómo se arma un presupuesto de este tipo.

La decisión, en una línea

Si tienes incertidumbre real —sobre la adopción, sobre el proceso o sobre el financiamiento— parte con un MVP bien definido: menos alcance, misma calidad, un proceso completo funcionando. Si el proceso ya está claro, es normativo o reemplaza algo que ya opera, construye derecho lo que se necesita y no pagues la coordinación de fases que no aportan información.

Si estás en ese punto y no tienes claro de qué lado caes, es exactamente la conversación que conviene tener antes de pedir cotizaciones. Puedo ayudarte a definir el alcance del primer tramo y el criterio para decidir el siguiente, como parte del servicio de desarrollo de software a medida — o, si el proyecto lo ejecuta otro proveedor, desde la contraparte técnica.