La reunión de inicio duró dos horas y salió con 47 funcionalidades anotadas en la pizarra. "Pero esto es solo el MVP", dijo el gerente comercial, "lo mínimo para partir". Seis meses después, el sistema seguía en desarrollo, el presupuesto se había ido entero y ningún cliente lo había usado.
Cuando una empresa de desarrollo de software escucha "queremos un MVP", lo primero que conviene preguntar es qué quiere aprender el cliente con esa primera versión. La respuesta casi nunca está en la lista de funcionalidades. Un MVP (producto mínimo viable) bien planteado es la primera versión de un software que pone una idea frente a usuarios reales lo antes posible, para saber si vale la pena seguir invirtiendo en ella. Mal planteado, es el producto completo con otro nombre.
Este artículo trata de cómo acotar ese MVP: qué entra, qué se deja para después, cómo medirlo y qué hacer con lo que aprendas. Si todavía no tienes escrito el requerimiento, parte por cómo armar un requerimiento para cotizar. Y si lo que te preocupa es el precio, revisa qué explica el costo de una aplicación a medida.
Qué es (y qué no es) un MVP
El término lo popularizó Eric Ries en el método Lean Startup. Su definición, publicada en Lean Startup Co., dice que el MVP es la versión de un producto nuevo que permite a un equipo obtener la mayor cantidad de aprendizaje validado sobre sus clientes con el menor esfuerzo.
Fíjate en la palabra "aprendizaje". Un MVP se mide por la pregunta que responde; la cantidad de pantallas da lo mismo. Algunos ejemplos de preguntas:
- ¿Los vendedores en terreno van a ingresar pedidos desde el celular, o van a seguir mandándolos por WhatsApp?
- ¿Los clientes van a usar un portal de autoatención, o prefieren llamar?
- ¿El cálculo automático de despachos reduce de verdad los errores que hoy salen de la planilla?
Tampoco es un prototipo de pantallas sin código. Un prototipo sirve para validar el diseño con unas pocas personas en una sala. El MVP funciona, maneja datos reales y lo usan personas haciendo su trabajo de verdad. Por eso tiene que ser estable y seguro aunque sea chico: un sistema que se cae o pierde datos no te enseña nada sobre la idea, solo te enseña que estaba mal construido.
Qué entra en la primera versión de un software
La forma más práctica de acotarlo es partir por un solo flujo completo de punta a punta, para un solo tipo de usuario. En vez de construir el módulo de pedidos, el de inventario y el de reportes a medias, construyes el camino entero de un pedido: se ingresa, se aprueba, llega a bodega y el cliente recibe la confirmación.
Para ordenar el resto, sirve clasificar cada funcionalidad en una de cuatro categorías (el método MoSCoW, usado en gestión ágil):
| Categoría | Qué significa | Ejemplo en un sistema de pedidos |
|---|---|---|
| Debe tener | Sin esto no se puede probar la idea | Ingresar pedido, validar stock, confirmar al cliente |
| Debería tener | Importa, pero hay una forma manual de cubrirlo por un tiempo | Descuentos por volumen (se aprueban por correo mientras tanto) |
| Podría tener | Mejora la experiencia, no cambia lo que vas a aprender | Historial de pedidos con filtros |
| No por ahora | Fuera de esta versión, por acuerdo explícito | App para clientes finales, integración con el CRM |
La última fila es la que más cuesta escribir y la que más ayuda. Dejar por escrito qué no va a tener la primera versión evita que el alcance crezca reunión tras reunión.
Hay cosas que no conviene recortar aunque el presupuesto apriete: autenticación de usuarios, respaldos, registro de errores y una forma de medir el uso. Si el sistema va a tratar datos personales, también el resguardo de esos datos desde el diseño. La Ley 21.719 sigue con su entrada en vigencia fijada para el 1 de diciembre de 2026. El proyecto que la posterga al 15 de octubre de 2027 fue aprobado en general por la Comisión de Constitución de la Cámara el 4 de noviembre, pero todavía no es ley. En la práctica, un MVP que sale ahora va a operar con la ley vigente.
Cómo medir con usuarios reales
Antes de escribir código, define dos o tres métricas que te digan si la idea funciona y qué valor esperas en cada una. Si no lo decides antes, después cualquier resultado parece bueno.
Algunas que suelen servir:
- Uso real: cuántos de los usuarios invitados usan el sistema al menos una vez por semana.
- Reemplazo del proceso anterior: qué porcentaje de pedidos entra por el sistema y cuántos siguen llegando por correo o WhatsApp.
- Resultado de negocio: tiempo entre que se toma el pedido y se despacha, o errores de digitación por mes.
Los números dicen qué pasa. Para saber por qué, hay que hablar con la gente. Reserva media hora cada dos semanas para sentarte con dos o tres usuarios y mirar cómo trabajan con el sistema. Lo que ves en esa media hora (el campo que nadie entiende, el paso que se saltan) no aparece en ningún reporte.
Elige bien el grupo piloto. Un área chica, con una jefatura que quiera que esto resulte, te va a dar información más útil que un lanzamiento a toda la empresa con gente que no pidió el cambio.
Decidir la siguiente iteración
Después de cuatro a ocho semanas de uso hay suficiente información para decidir. Lo normal es que termines en una de estas opciones:
- Seguir: las métricas van bien y los usuarios piden más. Pasas al "debería tener" de la tabla, priorizado según lo que viste en terreno.
- Ajustar: la gente lo usa, pero no como esperabas. Puede que el problema real fuera otro, o que el flujo esté al revés. Corriges antes de agregar.
- Detener: nadie lo usa y entiendes por qué. Duele, pero gastaste una fracción de lo que habría costado el producto completo para enterarte.
Lean Startup describe esto como un ciclo de construir, medir y aprender. La decisión tiene que salir de los datos y de las conversaciones con usuarios. Si sale de quién tenía más ganas de ver su funcionalidad construida, volviste al punto de partida.
Un detalle técnico que pesa en esta etapa: si el MVP se construyó con atajos que no aguantan crecer, la segunda versión empieza con una reescritura. Pídele a tu proveedor que te diga qué decisiones tomó para salir rápido y cuáles habría que revisar si el sistema sigue. Lo que viene después de la puesta en producción lo vimos en qué pasa tras la entrega de un software a medida.
Errores típicos al encargar un MVP
| Error | Qué pasa | Qué hacer |
|---|---|---|
| Llamar MVP al producto completo | Meses de desarrollo antes de que alguien lo use | Un flujo, un tipo de usuario, una pregunta |
| No definir métricas antes | Cualquier resultado se interpreta como éxito | Dos o tres métricas con valor esperado |
| Recortar seguridad y respaldos | El piloto falla por razones técnicas, no de negocio | Mantener lo básico aunque haya pocas funcionalidades |
| Lanzar a toda la empresa | Mucho ruido y poca información útil | Grupo piloto chico y comprometido |
| Agregar funcionalidades durante el piloto | No sabes qué cambio produjo qué resultado | Congelar el alcance hasta la revisión |
Preguntas frecuentes
¿Cuánto tiempo toma desarrollar un MVP?
Depende del flujo que elijas y de las integraciones que necesite. Si una empresa de desarrollo de software te propone un MVP de muchos meses, revisa el alcance: probablemente incluye más de lo necesario para responder tu pregunta.
¿Un MVP es solo para startups?
No. Una empresa establecida lo usa igual cuando quiere digitalizar un proceso o lanzar un servicio nuevo sin apostar todo el presupuesto de entrada. La lógica es la misma: aprender antes de escalar.
¿Qué pasa con el código del MVP si el proyecto sigue?
Si se construyó con buenas prácticas, se sigue usando como base. Por eso conviene que el MVP sea chico en funcionalidades, pero no improvisado en calidad, y que el código y las cuentas queden a nombre de tu empresa.
Empieza por la pregunta, no por la lista
En Disrupsoft partimos cada proyecto entendiendo tus requerimientos y procesos, y trabajamos en comunicación constante con tu equipo mientras desarrollamos aplicaciones web y móviles a medida con Angular, Node.js, Azure y Power Platform. Si tienes una idea y quieres saber cuál sería la primera versión que vale la pena construir, conversemos sobre tu proyecto de desarrollo de software a medida.
