¿Rehacer o parchear? Qué hacer con un producto mal construido
Tenés un sistema que funciona a los tumbos: cada arreglo rompe otra cosa. La decisión de rehacer o parchear tiene criterios concretos. Acá están.
Es más común de lo que parece: pagaste por un sistema, funciona "casi siempre", pero cada cambio tarda semanas, cada arreglo rompe otra cosa y el desarrollador original ya no responde. La pregunta inevitable: ¿lo arreglamos o lo hacemos de nuevo?
No hay respuesta única, pero sí criterios concretos.
Cuándo conviene parchear
- El núcleo es sano. Si la arquitectura de base es razonable y los problemas son superficiales (lentitud puntual, bugs acotados, diseño viejo), una puesta a punto rinde más que una reconstrucción.
- El negocio depende de él hoy. Si el sistema procesa tus ventas diarias, la continuidad manda: se estabiliza primero, se decide después.
- Los problemas están localizados. Tres módulos con bugs conocidos se arreglan. Bugs nuevos cada semana en lugares distintos son otro diagnóstico.
Cuándo conviene rehacer
- Cada cambio simple cuesta semanas. Es el síntoma definitivo de deuda estructural: el costo de tocar supera al de reconstruir.
- Nadie puede (o quiere) mantenerlo. Tecnología abandonada, sin documentación, sin el autor. Cada día que pasa, el rescate se encarece.
- El producto necesita ir a un lugar que la base no soporta. Si tu roadmap pide multiusuario, integraciones o escala y la base fue pensada para otra cosa, estirar lo viejo sale más caro que construir lo nuevo.
- No sos dueño del código. Si el proveedor anterior retiene el código o las cuentas, la reconstrucción es también una recuperación de soberanía.
El error más caro: la reconstrucción infinita
Rehacer no es la solución mágica: los rescates que fracasan son los que intentan reconstruir todo, con todas las mejoras, de una vez. La reconstrucción sana replica primero el flujo que genera ingresos, migra los datos, y recién después suma lo nuevo. En paralelo, el sistema viejo sigue operando hasta el switch.
Cómo lo evaluamos nosotros
En TheMakers arrancamos con una auditoría corta: estado del código, de los datos, de las cuentas y del costo real de cada camino. Salís con un diagnóstico honesto — a veces la respuesta es "parchá con otro proveedor, no hace falta rehacer" — y un plan con números para decidir.
¿Tenés un sistema que funciona a los tumbos? Contanos qué tenés y te decimos qué camino conviene — con fundamentos, no con humo.