En muchos comercios digitales, la tecnología ya representa una línea de OPEX difícil de mover.
Plataforma de ecommerce, CRM, atención, analítica, automatización, personalización, integraciones e infraestructura. Cada decisión puede haber tenido sentido por separado, pero con los años terminan formando una estructura recurrente difícil de reducir cuando el negocio necesita recuperar margen.
Lo he visto en operaciones digitales con rentabilidades muy ajustadas: el negocio puede seguir creciendo mientras una parte importante de su estructura tecnológica permanece prácticamente comprometida de antemano.
Cuando el software pasa a formar parte de la cadena de valor, alquilarlo indefinidamente deja de ser solo una decisión tecnológica. También se convierte en una decisión sobre rentabilidad.
SaaS resolvió velocidad. También convirtió tecnología en OPEX permanente
SaaS permitió contratar software que ya funcionaba sin financiar desarrollos largos, grandes equipos ni el mantenimiento completo de cada sistema. Eso aceleró ecommerce, CRM, marketing, atención al cliente y muchas otras capacidades.
Pero también modificó la estructura económica.
Una plataforma se sumó a otra. Luego llegaron integraciones y herramientas especializadas. Con el tiempo, parte de la arquitectura tecnológica terminó convertida en una línea recurrente de costos por usuarios, transacciones, contactos, capacidad o volumen.
Mientras el foco estaba en crecer, ese costo podía absorberse. Cuando el negocio necesita mejorar rentabilidad, algunas decisiones empiezan a verse distinto.
Reducir OPEX tecnológico puede requerir algo más que renegociar contratos: revisar qué capacidades necesitamos seguir alquilando y cuáles tendría sentido poseer.
La IA está cambiando el costo de construir
Durante años, comprar era la decisión racional. Desarrollar software propio exigía tiempo, especialistas, conocimiento funcional y una capacidad de mantenimiento difícil de justificar frente a una plataforma disponible.
Ese cálculo empieza a cambiar.
McKinsey & Company (2025) plantea que la inteligencia artificial puede intervenir en todo el ciclo de desarrollo: descubrir y validar oportunidades, prototipar, construir, probar, lanzar e iterar. Su análisis anticipa ciclos más cortos y mayor capacidad de experimentación.
Para un directorio, la implicancia va más allá de programar más rápido. Si disminuye el esfuerzo necesario para convertir una necesidad en software operativo, también disminuye una de las barreras económicas que durante años hicieron preferible alquilar.
Construir sigue exigiendo arquitectura, seguridad, mantenimiento y gobierno. Pero ya no resulta razonable asumir que una solución propia será siempre la alternativa más lenta y costosa.
El conocimiento que faltaba puede estar dentro del negocio
Otra barrera histórica fue el conocimiento funcional.
Contratar desarrolladores sirve de poco si resulta difícil traducir cómo funcionan realmente ventas, operaciones, logística, pricing o atención al cliente.
Ese conocimiento ya existe dentro de la organización.
La inteligencia artificial permite que un usuario experto participe mucho más directamente en la construcción: estructurar lógica, desarrollar prototipos, probar alternativas y trabajar junto con especialistas técnicos.
McKinsey & Company (2025) describe una evolución similar en product management, con mayor responsabilidad de punta a punta y capacidad para desarrollar prototipos y pruebas técnicas con menor intermediación inicial.
Eso no reemplaza al ingeniero. Reduce la distancia entre quien conoce el negocio y quien construye el software.
Comprar o construir pasa a ser una decisión de rentabilidad
No todo debería desarrollarse internamente.
Hay software cuya escala, seguridad y especialización hacen que comprar continúe siendo económicamente superior. Las capacidades genéricas probablemente seguirán encontrando una mejor solución en el mercado.
La evaluación cambia cuando el software ejecuta un proceso central, contiene conocimiento propio, condiciona la experiencia del cliente o representa una parte significativa del OPEX.
Un negocio digital con márgenes ajustados no debería evaluar su estructura tecnológica únicamente por funcionalidad. También necesita saber cuánto cuesta mantenerla, cómo escala ese costo con el revenue y cuánto margen consume.
Una arquitectura que funcionó para acelerar crecimiento puede no ser la mejor arquitectura para proteger rentabilidad.
El directorio también debería gobernar la economía de la tecnología
Esta discusión pocas veces se aborda con suficiente profundidad.
Se aprueban plataformas, iniciativas y presupuestos, pero no siempre se conecta la inversión tecnológica con la rentabilidad que el negocio espera producir.
No existe un porcentaje universal de ingresos que una empresa deba destinar a tecnología. Depende del sector, modelo de negocio, etapa de crecimiento, nivel de digitalización y de cuánto de su cadena de valor dependa del software.
Precisamente por eso conviene hacerlo explícito.
El directorio debería tener claridad sobre qué rentabilidad espera del negocio y qué proporción de su estructura económica puede destinar de manera sostenible a tecnología.
También debería distinguir cuánto de ese gasto genera ventaja competitiva, cuánto sostiene la operación y cuánto permanece porque reemplazarlo históricamente era demasiado complejo.
Un presupuesto tecnológico puede ser razonable como porcentaje de ventas y, al mismo tiempo, incompatible con el margen que la compañía necesita producir. También puede ocurrir lo contrario: reducir tecnología puede destruir capacidades que generan revenue o eficiencia.
La relación entre inversión tecnológica y rentabilidad necesita gobernarse de manera explícita.
Si diseñáramos nuestra arquitectura hoy
Una revisión ejecutiva debería comenzar comparando la rentabilidad esperada del negocio con la estructura tecnológica necesaria para sostenerla.
Después corresponde decidir qué capacidades conviene seguir contratando y cuáles empiezan a justificar propiedad.
La inteligencia artificial hace viable esa segunda alternativa en más casos que antes: reduce parte del esfuerzo de desarrollo y acerca el conocimiento del negocio al producto.
SaaS permitió acelerar durante una etapa en la que velocidad era una prioridad crítica. Muchas compañías necesitan ahora combinar crecimiento con rentabilidad.
Cuando el software se convierte en parte estructural de la cadena de valor, decidir qué comprar y qué construir también es decidir qué margen queremos conservar.
Referencias
McKinsey & Company. (2025). How an AI-enabled software product development life cycle will fuel innovation.