Pocas inversiones fallan con tanta regularidad como los proyectos de software. El gobierno de Estados Unidos invierte más de 100,000 millones de dólares al año en tecnología y, aun así, su órgano auditor, la Government Accountability Office (GAO), mantiene la adquisición de TI en su lista de alto riesgo desde 2015, porque los proyectos fracasan o exceden costos y plazos con demasiada frecuencia. Si eso ocurre a esa escala, la pregunta que enfrenta cualquier empresa que necesita un sistema —¿desarrollarlo internamente o contratar una plataforma existente?— dejó de ser un asunto exclusivo del área de sistemas. Es una decisión de inversión.
Una decisión de inversión, no una preferencia técnica
La disyuntiva entre construir y comprar suele plantearse en términos de control: el desarrollo propio ofrece un sistema a la medida, mientras que la plataforma de terceros implica adaptarse a lo que ya existe. Ese enfoque omite lo esencial. El software es un activo que compromete capital durante años y, como cualquier otro activo, debe evaluarse con las herramientas clásicas de la evaluación de proyectos: estudio de mercado, análisis técnico y análisis financiero, con horizonte de recuperación y escenarios de riesgo definidos antes de comprometer recursos. Son los mismos componentes que este portal ha descrito al explicar los elementos básicos de un proyecto de inversión, y aplican al software con la misma rigurosidad que a una planta o a una línea de producción.
Los costos que no aparecen en la cotización inicial
El presupuesto de desarrollo es apenas la primera línea del costo total de propiedad. La propia GAO reporta que las agencias federales estadounidenses destinan cerca del 80% de su gasto anual en TI a operar y mantener sistemas ya existentes, no a construir nuevos. La proporción ilustra lo que las empresas medianas suelen subestimar: el desembolso inicial es la parte menor del compromiso. A él se suman el mantenimiento correctivo y evolutivo, la seguridad, la infraestructura y el talento — un equipo interno capaz de sostener un sistema crítico exige perfiles escasos y caros en toda América Latina, y la rotación de ese personal se convierte en un riesgo operativo directo.
El tiempo tampoco es neutro. Mientras el sistema propio se construye, el competidor que contrató una plataforma ya está operando y aprendiendo del mercado. Ese costo de oportunidad rara vez figura en la evaluación inicial, aunque suele ser el más alto de todos.
El modelo llave en mano gana terreno en industrias reguladas
Los proveedores llave en mano entregan una operación completa —tecnología, integraciones y soporte— lista para operar bajo la marca del cliente. El comercio electrónico lo normalizó hace años con plataformas como Shopify, y la banca lo replicó con el modelo de banking as a service, que permite a empresas no financieras ofrecer productos bancarios sobre infraestructura de terceros.
Donde el modelo muestra su mayor ventaja es en las industrias reguladas, porque el proveedor no solo entrega tecnología: entrega cumplimiento normativo incorporado. El caso más reciente en la región es el de las apuestas en línea en Brasil. Desde el 1 de enero de 2025 opera allí un mercado regulado en el que cada autorización cuesta 30 millones de reales, cubre hasta tres marcas por cinco años y obliga a tributar sobre el ingreso bruto de juego, según detalla el medio especializado iGaming Brazil. Con costos de entrada de esa magnitud, la mayoría de los operadores nuevos no destina capital adicional a construir tecnología propia: contrata una solución de casino llave en mano que integra los juegos, los pagos y la reportería exigida por el regulador, y concentra su inversión en la licencia y la adquisición de clientes. La lógica es idéntica a la del comercio minorista que abre su tienda sobre una plataforma existente en lugar de programarla desde cero.
Cinco criterios antes de decidir
La decisión se ordena al responder cinco preguntas:
- Diferenciación: ¿el software es parte del producto que distingue a la empresa, o es una función estándar del sector?
- Horizonte de recuperación: ¿en cuántos años el desarrollo propio se paga frente al costo acumulado de la plataforma?
- Talento: ¿existe capacidad interna real para construir y sostener el sistema durante todo su ciclo de vida?
- Carga regulatoria: ¿cuánto del costo total corresponde a cumplimiento normativo que un proveedor especializado ya resolvió?
- Costo de salida: ¿qué tan costoso sería migrar a otro proveedor o retomar el control del sistema más adelante?
Construir sigue teniendo sentido cuando el software es el negocio mismo. Para todo lo demás, la evidencia acumulada de sobrecostos y plazos incumplidos indica que la pregunta correcta no es qué opción da más control, sino cuál devuelve el capital invertido con menos riesgo y en menos tiempo.