Heredar un código desordenado: cómo rescatar un proyecto estancado
Un desarrollador desapareció, o el desarrollo se estancó, y ahora tienes delante un código que nadie entiende. Así es como me hago cargo de proyectos desordenados de forma segura, y cómo decidir si arreglar o reconstruir.
Shayan Jamil·20 de mayo de 2026·6 min de lectura
Una parte sorprendente de mi trabajo empieza siempre igual: un fundador tiene un producto a medio construir, el desarrollador original se ha ido o no responde, y nadie que quede puede explicar cómo funciona. El proyecto está estancado, el presupuesto ya gastado parece en riesgo y la pregunta es simple pero estresante: ¿se puede salvar o empezamos de cero?
Me he hecho cargo de muchos de estos casos, y la situación casi nunca es tan desesperada como parece en ese momento. Pero sí hay que manejarla con cuidado. Lanzarse a cambiar cosas a ciegas es como un rescate se convierte en un segundo desastre. Así es como lo abordo.
El problema de negocio: estás atascado y el taxímetro sigue corriendo
Un proyecto estancado duele de una forma concreta. Ya has invertido dinero y tiempo, no puedes avanzar y ni siquiera estás seguro de lo que tienes. Cada opción parece arriesgada: si sigues, quizá estés construyendo sobre arena; si empiezas de cero, quizá estés tirando trabajo que en realidad estaba bien.
El peor movimiento es entrar en pánico, ya sea abandonándolo todo por reflejo o contratando a alguien que empieza a reescribir de inmediato sin entender lo que hay. Ambas cosas desperdician dinero. El primer paso correcto es siempre el mismo: entender antes de tocar.
Primer paso: evaluar antes de cambiar nada
Antes de cambiar una sola línea, quiero una imagen clara de lo que existe. Eso significa leer el código, ejecutar la app y averiguar:
- Qué funciona de verdad frente a lo que está roto o a medias.
- Cómo está construido: la estructura, el modelo de datos, las decisiones principales.
- Qué es peligroso: copias de seguridad inexistentes, agujeros de seguridad, ninguna forma segura de desplegar.
- Qué está desactualizado: los proyectos estancados a menudo se quedan anclados en una versión de runtime o framework que ya no recibe parches de seguridad. Node.js 20, por ejemplo, una elección habitual hace un par de años, llegó al final de su vida útil en abril de 2026. Saberlo pronto te dice si las actualizaciones deben formar parte del plan.
- Qué se puede rescatar y qué no tiene salvación.
Esta evaluación es la parte más valiosa de un rescate. Convierte el "no tenemos ni idea de lo que tenemos" en un mapa claro y honesto, del que dependen todas las buenas decisiones posteriores.
Lo primero que compruebo en cualquier rescate
¿Se puede ejecutar, respaldar y desplegar el proyecto con seguridad, sin riesgo de perder datos ni de romper lo que funciona? Antes de mejorar nada, me aseguro de que haya una red de seguridad. No se opera sin poder detener antes la hemorragia.
¿Arreglar o reconstruir? Cómo lo decido
Esta es la pregunta que los fundadores más quieren ver respondida, y la respuesta honesta es "depende de los cimientos". Esta es la lógica general:
Inclínate por arreglar cuando la estructura central es sólida, el modelo de datos tiene sentido, la arquitectura es razonable y los problemas son desorden y piezas que faltan, no fallos de fondo. La mayoría de los proyectos estancados están aquí. No necesitan una reescritura; necesitan a alguien que los entienda, los estabilice y termine el trabajo.
Inclínate por reconstruir cuando los cimientos están realmente rotos: un modelo de datos que no puede sostener el producto o una arquitectura que hace que cada cambio sea peligroso. Incluso entonces, rara vez se trata de "tirarlo todo". Normalmente es reconstruir el núcleo roto conservando las partes que funcionan.
Reescribir desde cero parece limpio y tentador, pero tira por la borda todas las lecciones que el código existente ya aprendió. Trato una reconstrucción completa como último recurso, no como opción por defecto, porque la mayoría de las veces el proyecto se puede salvar por mucho menos de lo que cuesta empezar de nuevo. (Acertar con esos cimientos es también lo que definir bien el alcance de un MVP pretende garantizar desde el principio.)
Por qué importa hacerse cargo con cuidado
Un rescate hecho con prisas tiende a crear problemas nuevos mientras arregla los viejos. Uno cuidadoso hace lo contrario: estabiliza lo frágil, documenta lo que era un misterio y lleva el proyecto a un punto en el que se puede avanzar con seguridad. Esa documentación importa más de lo que los fundadores esperan: el motivo por el que el proyecto se estancó suele ser que todo vivía en la cabeza de una sola persona. Ponerlo por escrito significa que nunca vuelves a estar tan expuesto. Un despliegue y unos entornos fiables suelen formar parte de la solución, ya que los proyectos estancados a menudo no tienen una forma segura de publicar cambios.
Un ejemplo realista
Gran parte de mi trabajo ha consistido en hacerme cargo del código de otras personas y continuarlo: terminar funcionalidades, estabilizar lo que era inestable y llevar productos a un punto en el que realmente pudieran lanzarse y crecer. La forma del trabajo es constante: entenderlo primero, hacer que sea seguro cambiarlo, arreglar o reconstruir las partes adecuadas según los cimientos y documentar sobre la marcha para que la siguiente persona (o el fundador) no tenga que adivinar. El alivio del fundador suele venir menos de un código ingenioso y más de tener por fin claridad sobre lo que tiene y un camino realista hacia adelante.
Errores comunes al rescatar un proyecto
- Lanzarse por pánico a una reescritura completa antes de entender lo que realmente hay.
- Cambiar cosas antes de tener una forma segura de hacer copias de seguridad y desplegar.
- Dar por hecho que todo está mal porque una parte lo está.
- Contratar a alguien que no quiere leer el código existente y solo quiere empezar de cero.
- No documentar lo aprendido, de modo que el proyecto sigue a una persona de distancia de volver a estancarse.
- Arreglar síntomas en lugar de los problemas de fondo que causaron el desorden.
Cómo abordo un rescate
- Evalúo primero: leo el código, lo ejecuto y mapeo lo que funciona y lo que es peligroso.
- Pongo una red de seguridad: copias de seguridad y una forma segura de desplegar antes de cambiar nada.
- Te doy un veredicto honesto: arreglar, reconstruir en parte o reconstruir por completo, con el razonamiento.
- Estabilizo los riesgos urgentes antes de añadir nada nuevo.
- Documento sobre la marcha, para que el proyecto nunca vuelva a ser una caja negra.
- Lo hago avanzar hacia el lanzamiento o el hito en el que estabas atascado.
El objetivo es desatascarte con el menor desperdicio posible: salvar lo que merece la pena, sustituir solo lo que de verdad lo necesita y devolverte un proyecto en el que puedas confiar.
¿Atascado con un proyecto estancado?
Si tienes un producto a medio construir y un desarrollador que ha dejado de responder, o un código que nadie sabe explicar, puedo evaluarlo con honestidad, decirte si conviene arreglarlo o reconstruirlo y ponerlo en marcha de nuevo.
Lee sobre cómo trabajo, mira lo que he construido y ponte en contacto para contarme cómo están las cosas. Encontremos juntos el camino realista hacia adelante.