El lunes había demo con clientes y el login seguía fallando. El repositorio estaba bajo la cuenta de la agencia anterior, el servidor no tenía documentación y nadie en la empresa podía responder una pregunta simple: si hoy se cae producción, ¿quién lo levanta? Cuando necesitás retomar un desarrollo que otra agencia dejó a medias, el problema nunca es solo el código. También hay accesos perdidos, decisiones sin contexto, prioridades mezcladas y bastante desgaste interno.
Lo más común en ese punto es querer apurar una solución: contratar otro equipo y pedirle que “termine lo que falta” cuanto antes. El problema es que esa urgencia suele empeorar todo. Si no entendés qué está sano, qué está roto y qué ni siquiera debería seguir construyéndose, terminás pagando dos veces por el mismo proyecto.
La buena noticia es que un proyecto trabado no siempre necesita empezar de cero. Muchas veces se puede rescatar con una auditoría seria, un plan de continuidad técnica y una priorización brutalmente honesta. Ahí es donde cambia la conversación: dejás de hablar de promesas y empezás a tomar decisiones con evidencia.
Retomar un proyecto frenado no consiste en programar más rápido: consiste en recuperar control antes de volver a invertir.
Frená el impulso de seguir desarrollando sin diagnóstico
Cuando una empresa cambia de proveedor en medio de un proyecto, suele venir de varias semanas o meses de frustración. Hay tickets que no se resuelven, demos que no representan el avance real y un backlog que crece mientras la confianza cae. En ese contexto, acelerar parece lógico. Pero seguir construyendo sin diagnóstico es una forma bastante cara de tapar incertidumbre.
Antes de pedir estimaciones nuevas, necesitás responder tres preguntas:
- Qué está efectivamente hecho y qué solo existe en presentaciones, ramas incompletas o entornos que nadie usa.
- Qué tan mantenible es lo que ya existe, tanto a nivel código como infraestructura, despliegue y datos.
- Qué impacto real tiene terminar este proyecto para el negocio hoy, no para el plan de hace seis meses.
Ese corte inicial evita dos errores frecuentes. El primero es seguir invirtiendo en una arquitectura que ya nació mal. El segundo es tirar todo por la borda por cansancio, cuando quizás hay piezas valiosas que sí conviene conservar.
Si en tu caso el problema empezó mucho antes de la ejecución, te puede servir revisar qué debe incluir una etapa de discovery antes de desarrollar software. Muchos rescates de proyecto en realidad exponen una discovery incompleta o directamente inexistente.
Hacé una auditoría técnica y funcional antes de tocar el código
La auditoría es el punto de partida real. No es una formalidad para justificar horas: es la forma de bajar la ansiedad y convertir un proyecto opaco en algo que se pueda evaluar. Una buena auditoría combina mirada técnica y mirada funcional, porque un código prolijo que no resuelve el proceso tampoco sirve.
Qué revisar en el código y la arquitectura
En la parte técnica, el nuevo equipo debería inspeccionar:
- Estado del repositorio, ramas, convenciones y frecuencia real de cambios.
- Calidad del código: duplicación, deuda técnica, acoplamiento y nivel de consistencia.
- Dependencias críticas: librerías desactualizadas, servicios externos, credenciales y APIs de terceros.
- Forma de despliegue: ambientes, pipelines, rollback, backups y monitoreo.
- Riesgos de seguridad y puntos donde una falla puede dejar el sistema inutilizable.
No hace falta perseguir perfección. Hace falta identificar si el proyecto es continuable, si requiere una refactorización parcial o si alguna pieza específica conviene rehacerla.
Qué revisar fuera del código
La mayoría de los rescates no se traban por una clase mal escrita, sino por la falta de contexto. Por eso también hay que revisar:
- Objetivo de negocio actual del proyecto.
- Flujos críticos que el sistema debería cubrir en esta etapa.
- Diferencia entre lo prometido, lo construido y lo realmente necesario.
- Stakeholders que aprueban, usan o dependen del sistema.
Esa lectura funcional permite detectar si el problema es técnico, de alcance o de alineación. Y muchas veces es una mezcla de los tres. No es casual que los proyectos de software fallen más por problemas de alcance y alineación que por razones técnicas. Si no ordenás eso al inicio, cualquier rescate queda condenado a repetir el mismo patrón.
Recuperá accesos, documentación e infraestructura desde el día uno
Un proyecto no está bajo control porque alguien tenga el código en un ZIP. Está bajo control cuando la empresa puede acceder a todo lo que necesita para operarlo y evolucionarlo sin depender de favores. En un cambio de agencia, este punto suele aparecer tarde y duele más de lo que debería.
Los accesos críticos que hay que recuperar o validar cuanto antes son:
- Repositorios y permisos de administración.
- Hosting, cloud, DNS, CDN y certificados.
- Bases de datos, backups y políticas de restauración.
- Cuentas de analytics, error tracking, emails transaccionales y servicios externos.
- Diseños, documentación funcional, tableros de gestión y credenciales compartidas.
Señales de riesgo que no conviene relativizar
Hay alarmas que justifican frenar hasta aclararlas:
- El deploy depende de una sola persona.
- Nadie puede replicar el entorno fuera de la notebook del proveedor anterior.
- Las credenciales están mezcladas en chats o archivos sueltos.
- No existe inventario de servicios contratados ni de vencimientos.
Cuando aparece alguno de estos puntos, el problema ya no es solo continuidad técnica. Es riesgo operativo. En Gambit Lab solemos insistir bastante con esto porque un sistema puede estar a 80% de avance y aun así ser inviable para producción si la infraestructura quedó atada a un proveedor o a una forma de trabajo imposible de sostener.
Priorizá el backlog para salir del bloqueo sin reescribir todo
Después de la auditoría llega una decisión incómoda: aceptar que no todo lo que estaba en el plan original merece seguir vivo. Un proyecto rescatado no se ordena agregándole tareas; se ordena recortando, separando y priorizando con criterio de negocio.
La pregunta correcta no es “qué falta para terminar”. La pregunta correcta es “qué necesita estar estable para que el proyecto vuelva a generar valor”. Esa diferencia cambia por completo la hoja de ruta.
Cómo definir un backlog de rescate
Un backlog de continuidad técnica debería dividirse, como mínimo, en cuatro grupos:
- Bloqueantes: todo lo que impide usar, desplegar o mantener el sistema.
- Críticos de negocio: funcionalidades sin las cuales el proyecto no cumple su objetivo.
- Mejoras necesarias: puntos que no bloquean, pero generan fricción real.
- Pendientes post-lanzamiento: ideas valiosas que no justifican seguir demorando la salida.
Este ejercicio suele mostrar que una parte del alcance original puede esperar y que otra parte directamente fue mal planteada. Ahí aparece una verdad que a veces cuesta aceptar: rescatar un proyecto no es respetar cada decisión anterior. Es quedarte con lo recuperable y cortar lo que solo agrega complejidad.
Cuándo conviene reescribir una parte
No siempre hace falta reescribir todo. Pero sí conviene rehacer un módulo cuando:
- Resolver la deuda técnica cuesta más que reconstruirlo bien.
- La lógica actual no representa el proceso real del negocio.
- El componente quedó tan acoplado que cualquier cambio rompe tres cosas más.
- No hay tests, documentación ni forma segura de intervenirlo.
Tomar esa decisión con evidencia le ahorra al negocio meses de discusión improductiva. Si venís de una experiencia mala con proveedores, probablemente ya viste lo que pasa cuando nadie pone este límite a tiempo.
Armá un plan de continuidad técnica con hitos cortos y visibles
Una vez auditado y priorizado el proyecto, hace falta un plan de rescate. Pero no un Gantt optimista de 40 tareas. Lo que funciona mejor en este escenario son hitos cortos, visibles y verificables, donde cada entrega reduzca incertidumbre concreta.
Un esquema razonable para retomar un proyecto suele incluir:
- Hito 1: estabilización. Recuperar accesos, documentar arquitectura, asegurar ambientes y corregir riesgos críticos.
- Hito 2: vertical funcional. Llevar un flujo importante de punta a punta para validar que el sistema realmente puede operar.
- Hito 3: endurecimiento. Testing, monitoreo, performance básica, seguridad y ajustes de UX en puntos sensibles.
- Hito 4: salida controlada. Lanzamiento con soporte cercano, métricas y backlog de evolución posterior.
Qué debería ver el cliente en cada etapa
Si el nuevo proveedor habla de continuidad, debería entregar evidencia, no solo tranquilidad verbal:
- Informe de auditoría con hallazgos y riesgos priorizados.
- Recomendación clara sobre qué seguir, qué pausar y qué rehacer.
- Cronograma por hitos con criterios de aceptación.
- Lista de dependencias del lado del cliente y responsables.
- Supuestos explícitos para evitar sorpresas más adelante.
Esto también sirve para recomponer confianza interna. Después de un proyecto golpeado, el negocio ya no quiere discursos técnicos largos; quiere saber qué va a pasar, en qué orden y cómo se va a medir el avance. En ese tipo de transiciones, la claridad pesa tanto como la capacidad técnica.
Qué debería entregarte un equipo serio al retomar tu proyecto
No todas las agencias están preparadas para entrar en un proyecto empezado. Retomar un desarrollo heredado exige criterio para auditar, comunicar malas noticias sin maquillaje y decidir dónde conviene intervenir sin romper lo rescatable.
Si estás evaluando a un nuevo partner, prestá atención a estas señales:
- Te explican el estado actual con lenguaje claro y sin dramatizar.
- Pueden justificar técnicamente por qué continúan, refactorizan o rehacen una parte.
- Separan urgencia operativa de alcance deseable.
- Piden acceso a la información correcta antes de estimar.
- Dejan por escrito riesgos, supuestos y límites de la propuesta.
También conviene desconfiar de dos extremos. Uno es el proveedor que promete “en dos semanas lo resolvemos” sin haber visto nada. El otro es el que propone tirar todo y empezar de cero como respuesta automática. Ninguna de las dos posturas es seria si no viene acompañada de auditoría y fundamentos.
El handover tiene que quedar por escrito
En proyectos heredados, la continuidad también depende de cómo se transfiere la información. Si el cambio de agencia ocurre con apuro, es fácil que queden conversaciones clave en mails, decisiones técnicas sin registrar o pendientes abiertos que nadie asume como propios. Por eso conviene exigir un handover concreto: repositorios transferidos, inventario de servicios, estado de ambientes, issues abiertos, deuda conocida y próximos pasos recomendados.
No es burocracia. Es la diferencia entre arrancar con contexto o arrancar reconstruyendo memoria. Cuando ese traspaso no existe, el nuevo equipo tiene que dedicar parte del presupuesto a descubrir decisiones pasadas que podrían haberse documentado en una tarde.
En Gambit Lab trabajamos este tipo de rescates con una lógica simple: primero recuperar visibilidad, después reducir riesgo y recién ahí acelerar. Ese orden puede parecer menos vistoso, pero es el que evita volver a entrar en el mismo pozo unos meses más tarde.
El rescate del proyecto empieza con un diagnóstico honesto
Cuando otra agencia dejó el desarrollo a medias, la tentación de resolverlo con urgencia es entendible. Pero lo que más protege tu inversión no es cambiar de proveedor sin más, sino recuperar contexto, accesos y prioridades antes de decidir el próximo paso.
Un buen rescate no siempre implica reescribir. A veces implica ordenar, podar y retomar con un alcance mucho más claro. Otras veces confirma que cierta base no sirve y que conviene reconstruir una parte crítica. En ambos casos, la diferencia está en decidir con evidencia y no con cansancio.
Si tenés un proyecto frenado y necesitás una segunda mirada técnica, en Gambit Lab podemos hacer una auditoría de continuidad y proponerte un plan de rescate realista: qué se puede salvar, qué riesgos hay y cómo volver a poner el producto en movimiento sin seguir acumulando deuda. Si querés, coordinamos un diagnóstico inicial y lo bajamos a próximos pasos concretos.