Subcontratar TI no es lo mismo que tener un tech partner: la diferencia importa
Muchas empresas subcontratan TI y siguen sintiéndose solas frente a sus problemas tecnológicos. La diferencia no está en el contrato — está en cómo trabaja el equipo que contratas.
Equipo Andevs
El síntoma que nadie nombra bien
Tienes un proveedor de desarrollo. Te entregan lo que pides, en el tiempo acordado, al precio pactado. Y aun así, cada vez que aparece un problema tecnológico importante, te sientes solo tomando la decisión.
Eso no es un problema de tu proveedor. Es un problema de modelo. Estás trabajando con una factory, no con un partner.
La distinción no es semántica. Cambia lo que puedes esperar, lo que deberías exigir, y cómo deberías evaluar si la relación está funcionando.
Qué es una software factory (y por qué no es malo)
Una software factory es una empresa que ejecuta requerimientos de desarrollo. Tú defines qué construir, ellos lo construyen. El modelo es transaccional: hay un scope, un plazo y un precio.
Eso tiene valor real. Si sabes exactamente qué necesitas, tienes un equipo técnico interno que puede definirlo bien, y el proyecto es acotado, una factory es probablemente la opción más eficiente.
El problema aparece cuando la empresa no tiene claridad técnica interna, cuando los requerimientos cambian con el negocio, o cuando el sistema que se construye pasa a ser crítico para la operación. En esos casos, el modelo transaccional empieza a crujir.
Contratar una factory para un problema estratégico es como contratar a un taxista para que te ayude a decidir a dónde ir. Te lleva donde le digas, pero la decisión sigue siendo tuya.
Una factory ejecuta bien. Un partner piensa contigo antes de ejecutar.
Qué hace diferente a un tech partner
La diferencia no está en el tamaño del equipo ni en el precio. Está en tres comportamientos concretos.
1. Cuestiona el requerimiento antes de desarrollarlo
Una factory recibe un requerimiento y lo cotiza. Un partner pregunta: ¿esto resuelve el problema real, o solo el síntoma que viste?
Ejemplo concreto: una empresa pide un módulo de reportes porque el equipo comercial se queja de que no tiene visibilidad. Un partner pregunta antes de cotizar: ¿el problema es que no hay datos, o que los datos existen pero nadie los está usando? La respuesta puede cambiar completamente la solución — y el costo.
2. Tiene contexto acumulado de tu negocio
Cada proyecto nuevo con una factory parte de cero. Un partner acumula contexto: conoce tu arquitectura, tus integraciones, tus decisiones pasadas y por qué se tomaron.
Ese contexto tiene valor económico directo. Menos tiempo explicando, menos errores por desconocimiento, menos riesgo al hacer cambios en sistemas existentes.
3. Alerta cuando algo va a salir mal
Una factory entrega lo que se pidió. Un partner te avisa cuando lo que pediste va a generar un problema más adelante — aunque eso signifique una conversación incómoda.
Eso incluye cosas como: "este diseño no va a escalar si el volumen crece", "esta integración tiene un punto de falla que deberías conocer", o "el costo de mantenimiento de esta solución va a ser alto en 12 meses".
La diferencia entre una factory y un partner se nota sobre todo cuando algo sale mal o cuando el negocio cambia — no cuando todo va bien.
Los dos mundos donde esto aplica distinto
Esta distinción importa de forma diferente según en qué etapa estés.
Si estás construyendo algo nuevo: el riesgo de trabajar con una factory pura es que construyas lo correcto técnicamente pero lo incorrecto estratégicamente. Un partner te ayuda a validar el enfoque antes de invertir.
Si estás manteniendo sistemas existentes: aquí el contexto acumulado es todo. Cada vez que cambias de proveedor, pierdes ese contexto y pagas el costo de reconstruirlo. Un partner que conoce tu sistema es un activo, no un gasto.
Esto no significa que debas tener un solo proveedor para todo. Significa que para los sistemas críticos de tu operación, el modelo de relación importa tanto como la capacidad técnica del equipo.
Cómo evaluar si tu proveedor actual es una factory o un partner
Tres preguntas concretas:
- ¿Alguna vez te han dicho que no a un requerimiento, explicándote por qué? Si siempre dicen que sí, probablemente estás trabajando con una factory.
- ¿Tienen documentación actualizada de tu arquitectura y tus decisiones técnicas? Si no, el contexto vive en la cabeza de una persona — y eso es frágil.
- ¿Te han alertado alguna vez sobre un riesgo antes de que se materializara? Si solo reaccionan a problemas, no los anticipan.
Ninguna de estas respuestas es un juicio de valor sobre tu proveedor. Es información sobre qué modelo de relación tienes — y si ese modelo sirve para lo que necesitas. Si tu proveedor nunca te ha dicho algo que no querías escuchar, probablemente no está actuando como partner.
Qué hacer ahora
- Identifica qué sistemas de tu operación son críticos — aquellos donde un fallo o una mala decisión técnica tiene impacto directo en el negocio. Para esos sistemas, el modelo de relación con tu proveedor debería ser revisado.
- Evalúa el contexto que tiene tu proveedor actual — ¿pueden explicarte las decisiones de arquitectura que tomaron hace 18 meses y por qué? Si no, hay un riesgo latente.
- En la próxima reunión con tu equipo técnico o proveedor, lleva un problema de negocio, no un requerimiento — observa si te ayudan a definir la solución o solo esperan que tú la definas para cotizarla.