¿Cuándo conviene reconstruir un MVP?

Define el detonante como restricción de producto

Escribe el resultado de usuario u operación que el sistema no sostiene. Adjunta incidentes, cambios fallidos, límites medidos, dependencias sin soporte, caminos inaccesibles o recuperación imposible. Separa dolor actual de escala futura imaginada. Un volumen hipotético o arquitectura impopular es un detonante débil sin umbral probado y necesidad próxima.

Detén una propuesta sin objetivo, propietario de datos o responsable de decisión. Rehacer implementación no corrige una propuesta de valor confusa, falta de usuarios u operación sin dueño. Si la dirección del producto no está validada, usa descubrimiento o experimento menor en lugar de convertir incertidumbre en plataforma nueva.

Inventaría lo que debe sobrevivir

Mapea recorridos, reglas, datos, integraciones, identidades, permisos, analítica, registros, dominios, tiendas, despliegue y soporte. Separa conducta intencional de la accidental que usuarios quizá esperan. Identifica fuentes de verdad, conservación y límites externos. No empieces solo por pantallas ni ignores las tareas operativas invisibles.

Crea una base de producción: frecuencia de fallos, recuperación, tiempo de release, testabilidad, mantenibilidad y rendimiento medido cuando importe. Registra calidad y vacíos de evidencia. Así se evalúa mejora y se evita llamar éxito a una reescritura más limpia que empeora fiabilidad u operación.

Prueba reparar, contener y reemplazar

Investiga la restricción más dura con un alcance limitado: actualizar dependencia, aislar componente tras API, añadir pruebas de caracterización, corregir datos o reemplazar un tramo. Evalúa cuánto riesgo desaparece sin migrar todo y conserva alternativa mientras la nueva vía no esté probada.

Si reconstruir sigue justificado, secuencia por resultados y datos, no por copiar pantallas. Define convivencia, validación de migración, rollback, soporte y retirada. Asigna fecha de decisión a cada componente para evitar dos sistemas permanentes. Una migración de golpe necesita evidencia de recuperación más sólida.

Acepta contra la restricción original

Usa los mismos recorridos y límites para ambas vías. Prueba datos, permisos, errores, rendimiento importante, accesibilidad, observabilidad, despliegue y recuperación. Registra defectos corregidos, pendientes y cambios deliberados. Terminar código nuevo no basta si migración u operación siguen sin demostrar evidencia reproducible.

Define la aceptación con evidencia observable, por ejemplo un recorrido probado, una compilación aprobada, controles reproducibles, un runbook de incidentes y un traspaso verificado. Nada de eso demuestra retención, ingresos o encaje de mercado. Separa evidencia de entrega, aprobación de proveedores externos y resultado comercial.

Transfiere, observa y retira con intención

Coloca repositorios, infraestructura y accesos bajo la organización y documenta lanzamiento y recuperación. Observa la nueva vía durante un periodo o tráfico definido. Conserva datos y evidencia necesarios, elimina acceso obsoleto con cuidado y registra la retirada. Una migración técnica no demuestra mejora de adopción o negocio.

Mantén repositorios, dominios, tiendas, analítica, organizaciones cloud y credenciales de producción bajo propiedad explícita de la empresa. Concede acceso limitado y revocable y ensaya el traspaso antes de la factura final. La etiqueta del proveedor importa menos que la capacidad de otra persona autorizada para inspeccionar, desplegar, recuperar y continuar el producto.

Criterios de decisión

Aplica las mismas preguntas a cada opción antes de elegir.