Software atrasado: cómo retomarlo sin partir de cero

El sistema debería estar en línea hace meses. En cada reunión, la fecha se corre un poco más. El proveedor dice que falta poco, pero no logras ver qué está listo. Dan ganas de tirarlo todo y empezar de nuevo. Casi nunca es el mejor camino, y nunca es el primer paso.

El atraso es más común de lo que parece. En abril de 2024, BCG encuestó a ejecutivos de 25 sectores y casi la mitad dijo que más del 30% de los proyectos de tecnología de su empresa iban atrasados o por encima del presupuesto. Casi uno de cada cinco dijo que el resultado quedaba por debajo de lo esperado en más de la mitad de los casos. Lo que cambia el desenlace es el orden de las decisiones. Esta guía muestra ese orden.

Señales de que el atraso no es puntual

Todo proyecto se atrasa un poco en algún momento. El problema es cuando el atraso se vuelve la norma. Presta atención si:

• La fecha ya cambió más de una vez y nadie explica el motivo.
• Solo ves capturas y videos, nunca el producto funcionando.
• Cada entrega arregla una cosa y rompe otra.
• El proveedor no sabe decir qué falta, solo que “ya casi está”.
• La persona que programaba se fue y nadie sabe dónde están las cosas, como cuando el freelancer desaparece con el proyecto.
• No tienes acceso al repositorio del código.

Si más de un punto te suena, el atraso no se va a resolver solo.

Primer paso: todo a nombre de la empresa

Antes de cualquier conversación difícil, asegura los accesos. Si la relación con el proveedor se deteriora, son ellos los que sostienen el proyecto. Revisa:

• Código: el repositorio (GitHub, GitLab o Bitbucket) está en una cuenta de la empresa, contigo como propietario, no solo como invitado.
• Dominio: el titular registrado es el CNPJ de la empresa. Para dominios .br, el registro está en Registro.br.
• Hosting y nube: cuenta a nombre de la empresa, cobro en la tarjeta de la empresa.
• Base de datos y backups: dónde están, quién accede y cuándo fue el último backup.
• Servicios ligados al producto: e-mail transaccional, pasarela de pago, tiendas de apps, herramientas de analítica.
• Contraseñas y claves: en un gestor de contraseñas de la empresa, no en un chat de WhatsApp.

Sin esos accesos, cualquier decisión posterior queda a merced de una sola persona.

Qué pedir al proveedor actual

Sé directo y pídelo todo por escrito:

1. Lista de lo que está listo, de lo que está en curso y de lo que no ha empezado.
2. Acceso al producto funcionando en un entorno de pruebas.
3. Documentación mínima: cómo instalar, cómo publicar y qué servicios externos usa el sistema.
4. La causa del atraso, según su punto de vista.
5. Lo que falta, con una fecha para cada parte.

Su forma de responder ya dice mucho. Un proveedor que entrega lista, acceso y documentación está dispuesto a resolver. Uno que se resiste a mostrar el código está ocultando el estado real del proyecto.

Auditoría: lo que existe de verdad

Auditar es mirar el código, no las pantallas. Separa lo que funciona, lo que funciona mal y lo que solo parece funcionar. Una buena auditoría cubre:

• Flujos principales: probados de punta a punta, con datos reales.
• Seguridad: empezando por el control de acceso. En la edición 2025 del OWASP Top 10, la lista de riesgos en aplicaciones web que mantiene la fundación OWASP, el fallo de control de acceso es el riesgo número 1, y el 100% de las aplicaciones analizadas tenía alguna forma de él.
• Datos: estructura de la base, consistencia y copias de seguridad.
• Mantenimiento: ¿otro equipo puede entender y tocar el código?
• Infraestructura: cómo se publica el sistema, cuánto cuesta y qué pasa si se cae.

El resultado es una lista de lo que se queda, lo que se arregla y lo que se rehace. Esa lista se convierte en precio y fecha.

Arreglar o rehacer: cómo decidir

Arreglar tiene sentido cuando:

• La base de datos está bien modelada.
• Los flujos principales funcionan.
• Otro equipo puede leer y mantener el código.
• La tecnología usada todavía recibe actualizaciones.

Rehacer tiene sentido cuando:

• Cada corrección rompe otra parte.
• No se puede publicar una actualización sin miedo.
• La estructura de datos no aguanta lo que el negocio necesita.
• Corregir la seguridad obliga a tocar casi todo.

Muchas veces la respuesta es mixta. Se pueden conservar los datos, el diseño y las reglas de negocio, y reescribir solo las partes que traban. Rehacer una parte no significa perder lo que ya se pagó: lo que el proyecto enseñó sobre el negocio sigue valiendo.

Nueva fecha en el contrato, y cómo no volver a retrasarse

La nueva fecha tiene que venir con alcance por escrito. Una fecha sin alcance es solo otra promesa.

El mismo estudio de BCG señala dos prácticas que cambian el resultado. Las alertas tempranas de plazo y presupuesto aumentaron la tasa de éxito hasta 16 puntos porcentuales. Los equipos completos, sin puestos clave vacantes, rindieron un 76% más que los equipos con cargos importantes sin cubrir.

En la práctica, eso significa:

• Ver el producto funcionando con frecuencia, no solo en reuniones de seguimiento.
• Tener un responsable que avise antes de que se desborde, no después.
• Contar con un equipo completo, no con una sola persona.
• Recortar el alcance para caber en la fecha. Lo que no es esencial para el lanzamiento pasa a la siguiente fila.

Cómo lo hacemos en el Studio

El rescate empieza por los accesos y la auditoría. Leemos el código, probamos los flujos principales, revisamos seguridad y datos, y listamos lo que se queda, lo que se arregla y lo que se rehace. Esa lista se convierte en precio cerrado y plazo por escrito en el contrato. Código, archivos y accesos quedan a nombre de la empresa, y el equipo de desarrollo es del propio Studio.

También sabemos unir lo que ya existe en lugar de tirarlo. En LCX, empresa de turismo que opera en más de 10 países de Sudamérica, un sistema por país pasó a ser uno solo, en línea en 29 días. Y todo sistema sale con un agente de IA que funciona cada día, señala fallos, sugiere mejoras y comprueba que los datos tengan sentido. Es la alerta temprana que faltó en el proyecto que se retrasó.

Si tu proyecto de software está retrasado y quieres retomarlo sin tirar lo que ya pagaste, el rescate de proyectos del Studio empieza por la auditoría.