Cómo arreglar un MVP roto (sin empezar de cero)

Casi todo fundador con un MVP roto pregunta si reescribirlo. Casi siempre la respuesta es no — y la razón es aritmética, no sentimental.

Un MVP roto se presenta normalmente de tres formas: se cae con uso real, cada cambio rompe otra cosa, o los desarrolladores originales se fueron y nadie lo entiende. El instinto dice empezar de nuevo. Ese instinto es caro y suele estar equivocado.

Por qué reescribir es una trampa

La reescritura resulta atractiva porque el sistema nuevo es imaginario, y los sistemas imaginarios no tienen bugs. En la realidad:

• El código existente codifica años de casos límite que nadie documentó — se redescubrirán como incidentes en producción
• Congelas el desarrollo de funcionalidades durante meses mientras los competidores no lo hacen
• La reescritura choca con la misma complejidad, porque la complejidad está en el dominio, no en el código
• Las estimaciones de reescritura fallan por mucho, de forma consistente, en todas las organizaciones

Paso 1: detener la hemorragia

Antes de mejorar nada, haz el sistema observable y recuperable. No puedes arreglar lo que no ves, ni experimentar sin camino de vuelta.

1. Seguimiento de errores, para que los fallos se conozcan en vez de que los reporten los clientes
2. Monitorización de disponibilidad y transacciones clave — pago, registro, cobro
3. Un rollback que funcione y esté probado
4. Copias de seguridad, y una restauración que se haya realizado de verdad al menos una vez

Paso 2: triar, no inventariar

Resiste el impulso de listar todo lo que está mal. Ordena los problemas por consecuencia:

La mayoría de rescates encuentra dos o tres elementos en la primera categoría y un puñado en la segunda. Ese es un programa de trabajo manejable — muy distinto de la impresión abrumadora que tenía el equipo antes de ordenarlo.

Paso 3: arreglar en el orden que compone

1. Integridad de datos primero — los datos corrompidos o perdidos son irrecuperables de una forma en que la caída no lo es
2. Luego la ruta de despliegue — hasta que publicar sea seguro y frecuente, cualquier otro arreglo sale lento y con riesgo
3. Luego la principal fuente de fallos — normalmente uno o dos endpoints o consultas causan la mayoría de incidentes
4. Luego el bloqueador de cambios — el acoplamiento o la falta de tests que hace que el equipo tenga miedo de tocar
5. Y solo entonces, rendimiento y acabado

Paso 4: prevenir la recaída

• Tests en las rutas que duelen — dinero, autenticación y exactamente lo que se rompió
• Un registro de decisiones escrito, para que el siguiente ingeniero herede razonamiento y no solo código
• Un proceso de despliegue que cualquiera del equipo pueda ejecutar
• Una regla explícita de que el roadmap incluye capacidad de mantenimiento — si no, la deuda vuelve

Un rescate no es una limpieza. Es un número pequeño de cambios dirigidos que llevan al sistema de inseguro a aburrido — y aburrido es lo que permite a un equipo volver a entregar.

Definir la reparación antes de reescribir

Demuestra que un recorrido fallido puede estabilizarse. Usa ese resultado para estimar el siguiente tramo y evaluar la sustitución.

1. Crear una prueba de regresión del fallo observado.
2. Reparar un límite acotado y comprobar comportamientos adyacentes.
3. Comparar reparación y sustitución con migración y operación paralela.

• rescate MVP →
• auditoría técnica MVP →