Recuperar un proyecto de software fallido vs empezar de cero
Audita antes de decidir: esa es la respuesta honesta, y vale en las dos direcciones. La mayoría de los proyectos de software atascados conservan más valor recuperable del que sugiere la frustración — módulos que funcionan, integraciones ya pagadas, lógica de negocio difícil de reconstruir —, pero no todos. La decisión depende de tres criterios medibles: acceso, arquitectura y presupuesto restante.
Fracasar a esta escala es lo común, no la excepción. Un estudio de McKinsey y Oxford sobre 5.400 proyectos de TI (octubre de 2012) concluyó que los grandes proyectos superan el presupuesto en un 45% y entregan un 56% menos de valor del prometido. Doomity, firma de desarrollo de software con clientes en EE. UU., Reino Unido, España y Portugal, ha escrito esta guía para que decidas con datos y no con emociones.
Actualizado: julio de 2026
¿Deberías recuperar un proyecto de software fallido o empezar de cero?
Ninguna de las dos opciones es la elección por defecto. Recuperar un proyecto de software fallido gana cuando puedes reclamar los accesos, la arquitectura aguanta una auditoría y el presupuesto restante no da para reconstruir. Empezar de cero gana cuando los cimientos bloquean activamente tu roadmap y puedes financiar meses de trabajo sin entregar nada.
El error es decidir desde la frustración antes de que alguien lea el código. La posición de Doomity, tras años asumiendo bases de código ajenas, es simple: una auditoría independiente cuesta días; equivocarse entre rescatar y reescribir cuesta meses. Compra primero la información.
¿Por qué el coste hundido te empuja hacia la decisión equivocada?
El coste hundido distorsiona esta decisión en ambos sentidos, y por eso merece sección propia. Quien ya ha invertido mucho se siente obligado a seguir con un proveedor que falla, porque parar sería «tirar» lo invertido. Ese dinero no vuelve de ninguna manera; solo el gasto futuro se puede optimizar.
La trampa inversa sale igual de cara. Tras meses de promesas rotas, arrasar con todo sabe a justicia, y un presupuesto de reescritura suena a empezar limpio. Doomity trata el código existente como un activo que hay que tasar, no como un símbolo del fracaso: es la auditoría la que dice cuánto vale.
¿Cómo se comparan recuperar y empezar de cero, punto por punto?
La tabla siguiente resume la comparación que Doomity repasa con cada propietario que duda entre recuperar y reconstruir. Cada fila es una dimensión que puedes puntuar hoy para tu proyecto.
| Dimensión | Recuperar el proyecto | Empezar de cero |
|---|---|---|
| Tratamiento del coste hundido | Recupera parte de lo ya pagado: código que funciona, integraciones, lógica de negocio | Da por perdido todo lo construido, incluidas las partes que funcionan |
| Tiempo hasta el valor | Semanas: la estabilización mejora el sistema en producción mientras el negocio sigue operando | Meses: no se entrega nada utilizable hasta igualar la versión actual |
| Riesgo | Deuda técnica heredada e incógnitas escondidas en el código existente | Riesgo de segundo sistema: bugs nuevos, casos límite perdidos y otra apuesta por un proveedor |
| Cuándo gana | El acceso es recuperable, la arquitectura es sólida y el presupuesto es limitado | El acceso se ha perdido, la arquitectura bloquea el roadmap y el presupuesto cubre una reconstrucción completa |
Ninguna fila decide por sí sola. Un proyecto puede puntuar mal en riesgo y aun así merecer la recuperación, porque el tiempo hasta el valor domina para el negocio.
¿Cuándo gana claramente la recuperación del proyecto de software existente?
La recuperación gana más veces de las que espera quien está en mitad del incendio. Si el repositorio y las cuentas cloud se pueden reclamar, y la auditoría encuentra un núcleo sólido bajo el desorden, estabilizar vence a reconstruir en coste y en tiempo hasta el valor.
La velocidad importa, porque un rescate debe mostrar avances con el negocio en marcha. Doomity ejecuta estas tomas de control con un proceso de entrega con IA integrada, hasta un 40% más rápido, con cada hallazgo verificado por un ingeniero sénior. Sus equipos han construido software para Holcim, Canon España e Indra, donde entrar en bases de código ajenas era el punto de partida.
¿Cuándo es empezar de cero la mejor decisión de verdad?
Empezar de cero es lo correcto en una minoría de casos, y un proveedor honesto los nombra. Los más claros: el código es irrecuperable porque el acceso se ha perdido legal o materialmente; la arquitectura no soporta el producto que ahora necesitas; o el stack está tan obsoleto que cada contratación futura se complica.
El presupuesto es la cuarta prueba. Reconstruir significa pagar dos veces por funcionalidades que ya compraste, con meses de trabajo en paralelo hasta igualar el sistema actual. Si, hechas las cuentas, los números siguen favoreciendo la reescritura, entonces es una decisión, no una reacción.
¿Cuáles son los cinco primeros movimientos cuando un proyecto se atasca?
Decidas lo que decidas después, la primera semana es la misma. Estos cinco movimientos protegen tus opciones antes siquiera de plantear rescatar o empezar de cero:
- Asegura primero los accesos. Repositorio, cloud, dominios y CI en cuentas propiedad de tu empresa. Todas las opciones posteriores dependen de este paso.
- Congela el gasto en funcionalidades nuevas. Deja de pagar por código que nadie ha revisado; una pausa corta cuesta menos que otro sprint roto.
- Reúne el rastro documental. Contratos, facturas, cláusulas de propiedad intelectual y correos antiguos establecen qué es legalmente tuyo.
- Encarga una auditoría independiente. Alguien sin interés en la respuesta lee el código y dice qué hay en realidad.
- Decide entre opciones con precio. Continuar, reestructurar o reconstruir: cada una con un número y un compromiso, no con adjetivos.
¿Qué haces si tu desarrollador te ha dejado tirado?
«Mi desarrollador me ha dejado tirado» es la frase con la que empiezan muchas recuperaciones, y cambia el orden del trabajo, no el desenlace. Si tu agencia ha desaparecido con el repositorio o las cuentas cloud, la recuperación arranca con lo que tienes: contratos, facturas, la URL de producción, correos antiguos.
Doomity comienza estos casos mapeando quién es el dueño legal de cuentas, licencias y propiedad intelectual, y ejecutando después los pasos de reclamación. El silencio de un proveedor es un problema de acceso con procedimiento, no una razón para dar el proyecto por perdido.
¿Cómo decides con datos en lugar de con frustración?
Dos herramientas sustituyen a la intuición. La primera es una autoevaluación estructurada: Doomity publica un diagnóstico de rescate gratuito que puntúa acceso, arquitectura y presupuesto en pocos minutos, antes de hablar con nadie.
La segunda es la referencia de mercado del lado de la recuperación. La estadounidense Saritasa indica que sus clientes de toma de control gastan un mínimo de 80.000 dólares al año, y la consultora alemana Groenewold IT publica 7.000–21.000 € por una toma de control completa. Compara esos rangos con tus presupuestos de reconstrucción y la niebla del coste hundido empieza a levantarse.
FAQ
Normalmente rescatar, cuando el acceso y la arquitectura lo permiten, porque conservas el valor ya pagado. Como referencia de mercado, Groenewold IT publica 7.000–21.000 € por una toma de control completa, mientras que reconstruir implica volver a comprar cada funcionalidad. Doomity presupuesta los dos caminos tras una auditoría de cinco días, para que la comparación use tus números y no medias del sector.
Sí, en la mayoría de los casos. Contratos, facturas y cláusulas de propiedad intelectual suelen establecer que el trabajo pertenece al cliente, y los proveedores cloud tienen procesos para recuperar la titularidad de las cuentas. Doomity trata la recuperación de accesos como el primer punto del mapa de riesgos y empieza con lo que tengas, aunque sea solo la URL de producción y el papeleo.
Días, no meses, si la auditoría tiene el alcance correcto. El Rescue Triage de Doomity responde a la pregunta rescatar-o-reescribir en cinco días, con un mapa de riesgos y opciones A, B y C, cada una con precio. Un diagnóstico que tarda dos meses es, en sí mismo, parte del problema que venía a resolver.
Sí, cuando los datos apuntan en esa dirección. El roadmap de Doomity incluye siempre la opción de reconstrucción con su coste y su plazo reales, y a veces esa opción gana: típicamente cuando el acceso es irrecuperable o la arquitectura bloquea el producto. Lo que Doomity se niega a hacer es recomendar una reescritura antes de leer el código, porque ese consejo vende comodidad, no recuperación.
Si tu proyecto está atascado y quieres la respuesta a rescatar-o-empezar-de-cero para tu código concreto, el siguiente paso es una auditoría de alcance fijo con entregables garantizados.