Qué pasa cuando contratas una software factory y recibes código que nadie puede mantener

El entregable que nadie quiere heredar

La situación es más común de lo que parece: una empresa contrata una agencia o factory para construir un sistema a medida. El proyecto se entrega, el equipo interno lo recibe, y durante los primeros meses todo parece funcionar. Después llega el primer cambio de negocio — un nuevo flujo, una integración adicional, una regla de precios que cambió — y ahí aparece el problema real.

Nadie del equipo interno entiende el código lo suficiente como para modificarlo con confianza. El proveedor original ya no está disponible, o cobra por cada hora de soporte como si fuera cirugía de corazón abierto. Y el sistema, que técnicamente "funciona", se convierte en una caja negra que el negocio no puede evolucionar.

Eso no es un problema de mala suerte. Es el resultado predecible de una relación con un proveedor que priorizó la entrega sobre la transferencia de conocimiento.

---

Por qué ocurre esto con tanta frecuencia

La raíz del problema está en cómo se estructura la mayoría de los contratos de desarrollo a medida: el proveedor tiene incentivo para entregar rápido y cerrar el proyecto. No tiene incentivo para que el cliente entienda lo que recibió, ni para que el sistema sea fácil de mantener por alguien más.

Eso produce tres patrones que se repiten:

Código sin contexto. La lógica de negocio está implementada, pero no hay documentación que explique por qué se tomaron ciertas decisiones. Cambiar algo sin entender el "por qué" original es apostar a que nada más se rompe.

Dependencias sin criterio. El sistema usa librerías, versiones de frameworks o servicios externos que el proveedor conocía bien pero que el equipo receptor nunca eligió ni evaluó. Cuando esas dependencias quedan sin soporte, el problema cae del lado del cliente.

Arquitectura pensada para la entrega, no para el cambio. Un sistema construido para "quedar listo" tiene una forma distinta a uno construido para evolucionar. La diferencia no siempre es visible en el primer mes — aparece cuando el negocio necesita cambiar algo.

El resultado es un sistema que técnicamente cumplió el contrato, pero que operacionalmente es una deuda desde el día uno.

---

Cómo se ve el riesgo en números concretos

No es fácil cuantificar el costo de un sistema inmantenible hasta que algo falla. Pero hay señales medibles antes de llegar ahí:

• Tiempo de diagnóstico ante errores en producción. Si un bug tarda más de un día en ser diagnosticado por el equipo interno, el sistema ya no está bajo control real.
• Costo por cambio. Si cada modificación menor requiere contratar al proveedor original o a un consultor externo, el costo de operación del sistema es estructuralmente más alto de lo que aparece en el presupuesto.
• Concentración de conocimiento. Si solo una persona del equipo entiende cómo funciona el sistema, ese conocimiento es un punto único de falla. Cuando esa persona se va, el problema se vuelve urgente.

Estos no son indicadores técnicos abstractos. Son señales de que el sistema está gobernando al negocio en lugar de servirlo.

---

Qué distingue a un proveedor técnico de uno transaccional

La diferencia no siempre es visible en la propuesta inicial. Ambos tipos de proveedor pueden presentar un stack moderno, un equipo con experiencia y un precio competitivo. La distinción aparece en cómo se comportan durante el proyecto y después de él.

Un proveedor transaccional entrega lo que se acordó en el contrato y cierra el ciclo. Un partner técnico acumula contexto del negocio del cliente, cuestiona el requerimiento cuando parece atacar un síntoma en lugar del problema real, y construye el sistema de forma que el cliente pueda entenderlo, operarlo y modificarlo sin depender de nadie en particular.

Eso implica cosas concretas:

• Documentación que explica decisiones de arquitectura, no solo cómo usar el sistema.
• Transferencia activa de conocimiento al equipo interno durante el desarrollo, no al final.
• Elección de stack con criterio de mantenibilidad a largo plazo, no solo de velocidad de entrega.
• Disponibilidad para tener conversaciones incómodas cuando el requerimiento original no es la mejor solución al problema.

Ninguna de estas cosas aparece en un contrato estándar. Son parte de la cultura de trabajo del proveedor, y la única forma de evaluarlas es mirando cómo opera en proyectos anteriores.

---

El momento en que conviene revisar la relación con tu proveedor actual

No hace falta esperar a que el sistema falle para hacer esta evaluación. Hay situaciones concretas que indican que la relación con el proveedor actual no está funcionando como debería:

• El equipo interno no puede responder preguntas básicas sobre cómo funciona el sistema.
• Cada cambio requiere involucrar al proveedor, aunque sea pequeño.
• El proveedor entrega funcionalidades pero no explica las decisiones detrás de ellas.
• Hay resistencia a que otro equipo revise el código o tome el mantenimiento.

Cualquiera de estas señales, por separado, puede tener una explicación razonable. Todas juntas indican un problema estructural en la relación, no en el sistema.

---

Qué hacer ahora

1. Auditá el nivel de comprensión interna de tu sistema actual. Preguntale a tu equipo: ¿pueden explicar cómo funciona el sistema sin consultar al proveedor? ¿Pueden modificar un flujo sin miedo a romper algo más? Si la respuesta es no, ya tenés el diagnóstico.

2. Revisá las dependencias del sistema. Identificá qué librerías y versiones de framework está usando el sistema. Verificá cuáles tienen soporte activo y cuáles no. Esto toma menos de un día y puede revelar riesgos de seguridad que llevan meses acumulándose.

3. Antes de contratar el próximo desarrollo, pedí un criterio de transferencia. No alcanza con que el proveedor entregue el código. Pedí que expliquen cómo van a asegurarse de que tu equipo pueda operar y modificar el sistema sin depender de ellos. La respuesta a esa pregunta dice mucho sobre cómo trabajan.