Agencia de desarrollo de MVP: lo que debe entregar y lo que hay que exigir antes de firmar
Eric Leroy
Buscar una agencia de desarrollo de MVP suele significar querer ir rápido sin equivocarse. Los dos objetivos chocan desde la primera reunión: ir rápido empuja a recortar lo que te protege, no equivocarse empuja a preverlo todo. Este artículo explica lo que una agencia debería entregar de verdad en un MVP, los cinco compromisos que conseguir antes de firmar y las situaciones en las que es mejor no contratar una.
Un MVP no es una versión recortada de tu producto
Es el malentendido más caro, y se cuela en casi todos los encargos. Un MVP no es «el producto con menos funcionalidades». Es el sistema más pequeño capaz de responder a una pregunta que te haces: ¿tienen de verdad estos usuarios este problema, están dispuestos a pagar, aguanta este flujo con datos reales?
La diferencia no es teórica: cambia lo que se construye. Si la pregunta es «¿aceptarían los profesionales de oficios seguir sus trabajos desde el móvil?», el MVP no necesita facturación, ni permisos, ni panel de administración. Necesita un flujo que funcione con trabajos reales y una medida de lo que pasa después. Todo lo demás es producto, no MVP.
Una agencia que empieza pidiendo tu lista de funcionalidades construirá un producto pequeño. Una agencia que empieza preguntando qué decisión tomarás según el resultado construirá un MVP.
Lo que entrega de verdad una agencia de desarrollo de MVP
Una definición que recorta. El valor de la definición de un MVP no se mide por lo que añade, sino por lo que quita. Si sales de la definición con un alcance mayor que con el que entraste, algo ha fallado.
Un sistema en marcha, usado por personas reales. Una maqueta clicable prueba una interfaz, no una hipótesis de mercado. Mientras nadie de fuera haya usado el sistema con sus propios datos, tienes opiniones, no hechos.
Una medida definida antes del desarrollo. Este punto distingue a los proveedores con más fiabilidad que cualquier argumento técnico. Antes de escribir la primera línea, hay que saber qué contará como respuesta positiva y qué contará como respuesta negativa. Sin eso, cualquier resultado se leerá de forma favorable: es humano, y es justo lo que un MVP debe evitar.
Una base que no te encierra. Un MVP está pensado para tirarse o para llevarse más lejos. Los dos desenlaces están bien; lo que no está bien es no poder elegir porque nadie más sabe hacer funcionar el proyecto.
Los cinco compromisos que conseguir antes de firmar
No cuestan nada si se piden de entrada. Reclamados más tarde, se negocian desde una posición débil.
- El repositorio de código es tuyo desde el primer día, no en la entrega. La diferencia se nota el día en que la relación termina mal.
- Los accesos a los servicios de terceros están a tu nombre: alojamiento, dominio, base de datos, servicios de correo. Un servicio crítico en la cuenta personal de un proveedor es una dependencia que descubrirás en el peor momento.
- Un procedimiento de instalación que un tercero pueda seguir. La prueba es sencilla: ¿cuánto tardaría un desarrollador externo en poner el proyecto en marcha en su máquina? Si la respuesta es «habría que preguntar a quien lo escribió», no tienes un entregable, tienes una dependencia.
- El criterio de éxito está escrito antes del desarrollo, e incluye lo que te haría parar.
- Un plazo de preaviso para terminar la colaboración. Un traspaso preparado cuesta semanas; uno brusco puede costar el proyecto.
Cuándo no conviene contratar una agencia
Hay casos en los que la respuesta honesta es no, y una agencia seria debería decírtelo.
Cuando la pregunta se puede responder sin software. Muchas hipótesis se prueban con un formulario, una hoja de cálculo y algunas llamadas. Si diez conversaciones bastan para saber que el problema no existe, desarrollar cuesta semanas para una respuesta que podías tener en tres días.
Cuando el alcance no cabe en un ciclo corto. Si la definición acaba en varios meses, ya no es un MVP: es una primera versión, con el presupuesto y el riesgo de una primera versión. La palabra cambió de sentido por el camino, y es ahora cuando hay que decirlo, no seis meses después.
Cuando lo que buscas sobre todo es tranquilidad. Un MVP existe para zanjar una pregunta, también en contra del proyecto. Si la organización no está preparada para oír una respuesta negativa, el resultado se reinterpretará hasta que sea positivo, y el dinero habrá comprado una confirmación.
Cómo comparar dos propuestas
Los presupuestos se parecen todos; las respuestas a estas preguntas, no.
- ¿A qué pregunta responde este MVP, y qué contaría como respuesta negativa?
- ¿Qué se quitó del alcance durante la definición, y por qué?
- ¿Cuánto tardaría un tercero en retomar el proyecto?
- ¿Qué poseemos exactamente al final, y en qué momento?
- ¿Qué no está incluido?
La última es la más reveladora. Un proveedor que responde con precisión a «qué no está incluido» ha pensado en el alcance; uno que la esquiva te facturará esos elementos más tarde, o los entregará mal.
Si preparas un proyecto de este tipo, lo más rápido es contarnos el contexto: te diremos con honestidad si tu necesidad justifica un MVP, si puede resolverse sin desarrollo o si en realidad es una primera versión. Puedes consultar nuestro servicio de desarrollo de MVP, nuestra comparación entre agencia y freelance, los rangos de nuestra guía del coste de desarrollo de un SaaS, o describirnos tu situación directamente.
Preguntas frecuentes
¿Qué hace exactamente una agencia de desarrollo de MVP?
Construye el sistema más pequeño capaz de responder a una pregunta que te haces sobre tu mercado, no una versión ligera del producto final. En la práctica: formular la hipótesis que se quiere probar, recortar el alcance hasta que solo quede lo que produce una respuesta, desarrollar, lanzar e instrumentar para medir el uso real. Una agencia que empieza pidiendo tu lista de funcionalidades en lugar de la pregunta que quieres responder construirá un producto pequeño, no un MVP.
¿Cuánto tarda un MVP?
Depende por completo del alcance, y conviene desconfiar de cualquier cifra dada antes de fijarlo. Lo cierto es que la duración es la mejor señal de alarma: si la definición acaba en varios meses de desarrollo, ya no es un MVP sino una primera versión. La palabra cambió de sentido por el camino, y con ella el presupuesto y el riesgo. Un alcance que no cabe en un ciclo corto es un alcance que todavía no se ha recortado.
¿Agencia o freelance para un MVP?
Las dos opciones funcionan, y la forma jurídica no es el buen criterio. Lo que decide es la continuidad (qué pasa si la persona deja de estar disponible a mitad del proyecto) y lo que posees al final. Un desarrollador independiente que te entrega un repositorio de código que controlas y una documentación de instalación vale más que una empresa que te hace dependiente. Tratamos estos criterios en nuestra comparación entre agencia y freelance.
¿Qué debemos poseer al final del proyecto?
El código, en un repositorio que te pertenece, desde el primer día y no en la entrega. Los accesos al alojamiento y a los servicios de terceros a tu nombre, no en la cuenta personal del proveedor. Un procedimiento de instalación que un tercero pueda seguir. Estos tres puntos van en el contrato: reclamados después, se negocian desde una posición débil, y su ausencia convierte un cambio de proveedor en una reescritura.
¿Cómo saber si el MVP ha funcionado?
Definiendo, antes del desarrollo, qué contará como respuesta. Un MVP que funciona no es uno que gusta: es uno que zanja la pregunta, también cuando la zanja en contra del proyecto. Si no se fijó ninguna medida antes del lanzamiento, obtendrás opiniones e impresiones, no una decisión. Es la parte que más a menudo se saltan los proveedores, porque es la menos visible en un presupuesto.
Lo que hay que retener
Una agencia de desarrollo de MVP no vende semanas de desarrollo: vende una respuesta, obtenida rápido y a un coste conocido. El proveedor que necesitas es el que recorta tu alcance en lugar de aceptarlo, el que escribe contigo el criterio de éxito antes de empezar y el que te deja en condiciones de irte. Los errores más comunes de un MVP rara vez son técnicos: tienen que ver con la pregunta planteada y con lo que aceptas no construir.