Hay un patrón silencioso en empresas B2B mid-market que pocos discuten en público: el proyecto de software que arrancó hace 18 meses, ha consumido 200.000€+ y está parado. El equipo original se marchó, el proveedor anterior no contesta, o las prioridades cambiaron. El proyecto vive en limbo: ni desplegado ni cancelado.
Rescatar ese proyecto rara vez se hace bien. Suele intentarse asignando a otro equipo interno o contratando a un nuevo proveedor que empieza «de cero» descartando el trabajo previo. Ambas opciones desperdician valor existente y suelen reproducir el bloqueo.
Este artículo describe las seis fases de un rescate ordenado que recupera el proyecto sin tirar lo construido.
Por qué un proyecto se para
Cinco causas habituales, casi siempre combinadas.
Causa 1 — Equipo original que se marcha. El developer senior que llevaba el proyecto cambia de empresa. Nadie más conoce la arquitectura. El proyecto queda huérfano técnicamente.
Causa 2 — Cambio de prioridades estratégicas. Una decisión de dirección reorienta presupuesto y atención hacia otra iniciativa. El proyecto se aparca formalmente o informalmente.
Causa 3 — Proveedor anterior que no entrega. Subcontratado a un estudio externo que ha incumplido plazos, dejado de responder o ha cerrado. El cliente se queda con código parcial sin documentación. Si estás en este caso, hay decisiones urgentes que tomar en las primeras 72 horas.
Causa 4 — Deuda técnica acumulada que paraliza. El proyecto técnicamente funciona pero cada cambio nuevo introduce 3 bugs. El equipo dedica más tiempo a arreglar que a evolucionar. Llega un punto en que se opta por parar antes de seguir gastando.
Causa 5 — Pivote del negocio que invalida el alcance. El proyecto se construyó para resolver un problema que ya no es prioritario porque el negocio cambió. Sigue ahí pero ya no encaja.
Identificar qué combinación es responsable del parón es el primer paso. Sin diagnóstico de causa, el rescate se convierte en parche.
Las 6 fases de un rescate ordenado
Fase 1 — Inventario completo de lo que existe
Lo primero es saber qué hay.
- Repositorio de código (¿existe? ¿está accesible? ¿completo?).
- Infraestructura desplegada (¿qué hay en producción, qué hay en staging, quién paga el cloud?).
- Documentación (¿existe? ¿está actualizada?).
- Datos (¿qué bases de datos viven, con qué información, accesibles desde dónde?).
- Contratos (¿hay licencias activas, suscripciones SaaS, dependencias contractuales con el proveedor anterior?).
Esta fase dura 1-2 semanas y termina con un dossier de inventario que muchas veces sorprende al cliente. Casi siempre hay activos olvidados.
Fase 2 — Evaluación técnica de viabilidad
Sobre el inventario, evaluación honesta. ¿El código existente es retomable o el coste de mantenerlo supera al de reescribir? ¿La arquitectura encaja con las necesidades actuales o ha quedado obsoleta? ¿Las dependencias técnicas (librerías, frameworks, servicios externos) siguen vigentes y mantenidas?
Esta fase requiere dos perfiles: senior técnico que evalúe el código, senior arquitecto que evalúe el encaje funcional. Una semana de trabajo concentrado.
El resultado es una decisión binaria con argumentación: rescatar o reescribir. Y en caso de rescatar, qué partes mantener y qué partes refactorizar.
Fase 3 — Negociación contractual con el proveedor anterior
Si el proyecto venía de proveedor externo, hay un paso contractual ineludible. Acceso completo al código y la documentación. Cierre limpio de la relación. Liberación de cualquier cláusula de propiedad intelectual ambigua. Acuerdo de transición si quedan tareas pendientes que solo el proveedor original puede hacer.
Esta fase es delicada. Si el proveedor anterior no colabora, hay procedimientos legales pero alargan meses. Si colabora, puede resolverse en 2-4 semanas.
Fase 4 — Plan de recuperación o reescritura
Con inventario claro, evaluación técnica y situación contractual resuelta, se construye el plan. Qué se mantiene, qué se descarta, qué se reescribe, qué se añade. Con presupuesto cerrado por fases y fechas comprometidas.
Aquí es importante una regla: el plan de rescate debe ser conservador. Mejor entregar un MVP recuperado en 8-12 semanas que prometer recuperación + nueva funcionalidad en 6 meses. Después de un proyecto parado, lo que la empresa necesita primero es confianza recuperada en la ejecución.
Fase 5 — Ejecución del rescate
Con el plan acordado, ejecución por fases visibles. Cada 2 semanas, entrega tangible al cliente: módulo funcionando, parte de la infraestructura estabilizada, documentación generada. La cadencia rápida y visible es clave porque un cliente que viene de un proyecto parado necesita ver progreso, no esperar a la entrega final.
Plazo típico de la fase de rescate operativo: 8-16 semanas según complejidad.
Fase 6 — Transición a operación recurrente
Una vez recuperado, la pregunta es cómo se mantiene a partir de ahora. Equipo interno (si existe capacidad). Contrato de mantenimiento evolutivo con quien hizo el rescate. Plan híbrido. La decisión correcta depende de la madurez interna y el peso estratégico del sistema.
Sin una transición a operación recurrente bien definida, el proyecto rescatado se vuelve a parar en 6-18 meses.
Cuándo conviene rescatar y cuándo descartar
Tres criterios para decidir.
Criterio 1 — Coste de oportunidad de los activos existentes. Si el código existente tiene valor recuperable significativo (>30% del coste de reescribir), rescatar suele ganar. Si está tan degradado que conviene tirar, descartar sale más barato.
Criterio 2 — Encaje funcional con la necesidad actual. Si el sistema original resolvía un problema que sigue vigente, rescatar. Si el negocio cambió y el sistema ya no encaja con las prioridades actuales, descartar.
Criterio 3 — Capacidad de operar lo recuperado. Si la empresa tiene cómo mantener lo rescatado después, vale rescatar. Si no, mejor una decisión arquitectónica que no repita el mismo patrón de parón.
Cuándo NO contratar rescate y mejor reescribir desde cero
Honestidad estratégica. Hay tres situaciones donde el rescate es más caro que reescribir.
Código construido con tecnologías obsoletas o sin futuro de soporte (frameworks descontinuados, librerías sin mantenimiento). Mantener obliga a forks propios; reescribir con stack moderno sale más barato a 3 años.
Arquitectura fundamental que no encaja con la escala actual (monolito que no soporta el volumen, base de datos no relacional con necesidad de transaccionalidad fuerte). El refactor estructural cuesta lo mismo que reescribir.
Equipo original que dejó código sin tests, sin documentación y con prácticas malas. Cada hora de mantenimiento cuesta más que la equivalente en código nuevo bien hecho. Sobre esta decisión, profundizamos en cuándo refactorizar y cuándo reescribir desde cero.
Coste y plazo realistas de un rescate
Para un proyecto B2B mid-market parado de tamaño medio (50.000-150.000€ originalmente invertidos):
- Fases 1-3 (inventario, evaluación, negociación): 8.000-18.000€, 4-6 semanas.
- Fases 4-5 (plan + ejecución del rescate): 30.000-80.000€, 8-16 semanas.
- Fase 6 (transición a operación recurrente): incluida en el mantenimiento posterior, ~3.000-5.000€/mes según peso.
Total típico de un rescate completo: 40.000-100.000€ en 4-6 meses. Habitualmente más barato que reescribir desde cero, siempre que las fases 1 y 2 confirmen viabilidad.
Cómo decide el equipo de Nexus si acepta un rescate
No aceptamos cualquier rescate. Tras la auditoría inicial (fases 1-2), si concluimos que rescatar es más caro o más arriesgado que reescribir, lo decimos al cliente y le sugerimos la alternativa. Si aceptamos el rescate, asumimos el compromiso de entregar el MVP recuperado en plazo y presupuesto cerrado.
El rescate de proyectos está pensado para empresas que ya han invertido en software (incluyendo proyectos de IA y migraciones de ERP/CRM) y necesitan retomar sin tirar lo construido. La conversación inicial bajo el NDA confirma si el caso encaja en 24-48 horas.