MVP: qué recortar y qué conservar

Un MVP es la versión más pequeña de un producto que permite comprobar una hipótesis importante con una persona usuaria real y reunir una señal fiable para la siguiente decisión. Puede ser una aplicación funcional de alcance estrecho, pero no debe confundirse con una versión incompleta al azar de un sistema mayor.

La dificultad está en que la decisión de «qué recortar» es una decisión de negocio y a menudo se toma como si fuera técnica. Esta es la prueba que usamos para tomarla.

La prueba de tres preguntas

Para cada función de la lista, pregunta por orden:

1. ¿Se puede realizar el flujo principal de principio a fin sin ella? Si no, se queda. Si sí, es candidata a retirar.
2. ¿Su ausencia bloqueará la implantación con la primera persona usuaria real? No con el cliente objetivo ideal, sino con la primera. Son personas distintas.
3. ¿Aplazar esa decisión creará un coste o riesgo desproporcionado? Si afecta a límites de datos, permisos o cumplimiento, hay que diseñar ahora el mínimo necesario; que un cambio posterior sea algo más caro no justifica por sí solo toda la función futura.

La tercera pregunta protege del ahorro aparente. No todo puede añadirse después sin coste, pero eso no significa diseñar toda la arquitectura futura ya en la primera versión.

Lo que a menudo se puede aplazar

• Un panel de administración para todo. Al principio diseña solo las operaciones seguras necesarias para atender la primera versión. El acceso directo a la base de datos no debe sustituir el control de permisos, el registro de cambios y las copias.
• Multilingüismo sin una audiencia actual. Añade trabajo a pantallas, mensajes, contenidos y pruebas. No lo aplaces si la primera versión atiende de verdad varios idiomas o lo exige la ley o un contrato.
• Informes amplios. Al principio basta el conjunto mínimo de indicadores necesario para la decisión que se prueba. Añade vistas de diagnóstico a partir de preguntas de usuarios y problemas revelados por los datos.
• Notificaciones en todos los canales. Empieza por los canales necesarios para el flujo clave y el riesgo; variantes adicionales pueden añadirse después de comprobar el uso.
• Configurabilidad sin necesidad demostrada. Un panel de ajustes se justifica cuando una persona usuaria debe cambiar a menudo un parámetro o la solución atiende variantes distintas. En caso contrario basta una configuración explícita mantenida por el equipo.
• Capa de IA si no es el núcleo del producto. Añadir un asistente a una aplicación que aún no tiene usuarios es coste sin medición.
• Integraciones «para el futuro». Conectamos solo las que son necesarias para cerrar el proceso.

Lo que no se debe recortar sin evaluar el riesgo

Los elementos siguientes a veces se tratan como funciones para añadir después, aunque su ausencia pueda elevar el coste de un fallo, de una reconstrucción o de atender a las primeras personas usuarias:

• Modelo de datos con límites correctos. No se trata de prever todas las funciones futuras, sino de reconocer los conceptos básicos, la propiedad de los datos y las relaciones necesarias en el alcance actual. Un modelo excesivamente complejo también aumenta el coste del MVP.
• Autenticación y permisos adecuados al alcance actual. Añadir tarde el control de acceso exige revisar pantallas, operaciones y datos. El modelo de permisos evolucionará, pero los límites seguros de la primera versión deben definirse antes de admitir personas usuarias.
• Copias de seguridad con restauración probada. Crear una copia no demuestra que pueda restaurarse en el tiempo requerido. Ajusta el alcance y frecuencia de la prueba al valor de los datos y al tiempo de interrupción admisible.
• Monitorización y registros básicos. Su ausencia limita la capacidad de reproducir un error y a menudo deja al equipo solo con un aviso general de usuario.
• Gestión de errores visible para el usuario. Una aplicación que muestra una ventana vacía ante un problema se percibe como rota aunque la lógica sea impecable.
• Prueba con datos reales. Una aplicación que funciona con tres registros de ejemplo puede derrumbarse con diez mil.

Regla: retiramos funciones, no requisitos indispensables para el funcionamiento seguro del alcance actual. Cada «fundamento» debe surgir del riesgo y de la forma de uso del MVP, no de una versión hipotética dentro de varios años.

Cómo reconocer que el MVP es demasiado grande

Cuatro señales de advertencia:

Señal	Qué significa
No hay plazo ni límite de presupuesto	el alcance no tiene un límite real
No puedes describirlo en una frase	el alcance aún no está decidido
Cada nuevo rol necesita su propio flujo y permisos	comprueba si es necesario para la hipótesis que pruebas
La respuesta a «¿y si no hacemos esto?» es «bueno, quedaría más bonito»	se retira

Cómo reconocer que el MVP es demasiado pequeño

Un alcance demasiado estrecho tampoco puede entregar una prueba fiable:

• No permite probar el resultado prometido. Un paso manual o una hoja de cálculo puede ser una parte consciente del MVP siempre que el usuario siga recibiendo valor y el equipo mida la hipótesis correcta.
• No hay forma de medir si ayudó. Sin un punto de referencia e indicadores elegidos según la hipótesis, no sabrás si merece continuar.
• La versión es tan estrecha que el usuario no percibe valor. Entonces no obtendrás feedback, sino indiferencia.

Cuánto cuesta

Nuestros rangos de agosto de 2026 para un producto de entrada son 15.000–35.000 PLN netos, aproximadamente 4–6 semanas y precio fijo para un alcance definido. El plazo se refiere a un recorrido clave, datos disponibles y un número limitado de integraciones; un alcance mayor se presupuesta como proyecto separado. Un precio fijo exige criterios de aceptación, supuestos por parte del cliente y reglas para manejar cambios.

Si el alcance aún no está claro, la primera etapa puede ser un discovery por 3.000–8.000 PLN netos, que ordena los supuestos necesarios para presupuestar. Más sobre los rangos: cuánto cuesta una aplicación web.

Qué hacer después de implantar el MVP

Un MVP no es el objetivo, sino una herramienta para decidir el siguiente paso. Establece la ventana de medición según la frecuencia de uso y el comportamiento que investigas:

1. Compara el uso con la tarea esperada. La falta de uso puede significar una función innecesaria, pero también un problema de descubrimiento, acceso o selección de audiencia.
2. Recoge preguntas, no deseos. «¿Dónde encuentro X?» indica un problema de interfaz; «quiero Y» es la idea de una sola persona.
3. Decide la etapa siguiente con datos. Para eso servía toda la disciplina de alcance.

Preguntas frecuentes

¿El MVP se puede ampliar después o hay que reescribirlo?

Normalmente se puede ampliar si el alcance tiene límites claros y el modelo de datos y permisos corresponde al proceso actual. Sin embargo, no se puede prometer que no haya reconstrucción: un cambio de modelo de negocio, escala o requisitos regulatorios puede exigir otra arquitectura.

¿El MVP tiene que verse bonito?

Debe ser comprensible, accesible y lo bastante coherente para que la capa visual no distorsione el resultado de la prueba. Un lenguaje de marca cuidado importa más en un producto dirigido a clientes, pero una herramienta interna también necesita jerarquía legible, estados de error y feedback.

¿Quién debe decidir retirar una función?

La persona responsable del resultado de negocio debe decidir junto con el equipo técnico, seguridad y, cuando sea necesario, un abogado. El coste es un criterio, pero no puede ocultar el efecto de la función sobre la hipótesis probada y el funcionamiento seguro.

---

Vendemos MVP en 4–6 semanas con precio fijo para un alcance acordado, porque dividir en etapas reduce el riesgo para ambas partes. Si tienes una idea y no sabes qué debe ir en la primera versión, escríbenos.