Casi todas las organizaciones se han visto en la siguiente encrucijada en algún momento: ¿compramos un producto que ya existe o desarrollamos algo a medida? La conversación se suele plantear como una comparación de presupuestos, el típico cuánto cuesta la licencia frente a cuánto cuesta construirlo, y esa es, justamente, la parte de la decisión que menos importa a diez años vista.
Elegir entre producto, software a medida o un enfoque híbrido no es, en el fondo, una decisión técnica. Es una decisión sobre quién va a gobernar la evolución de una parte de tu negocio. El coste inicial se nota un trimestre; las consecuencias se pagan durante años. Y, como casi todas las decisiones que envejecen bien, la buena se reconoce por una propiedad sencilla: te deja cambiar de opinión más adelante sin tener que rehacerlo todo.
La pregunta no es «construir o comprar», es «qué control conservas»
Un producto estándar es una apuesta por la velocidad: alguien ya ha resuelto un problema general y tú te subes a ese trabajo. Un desarrollo a medida es una apuesta por el encaje: el software se adapta a tu operación, y no al revés. Por supuesto, las dos opciones son legítimas. El error habitual no es escoger una u otra, sino escogerla por los motivos equivocados.
En otras palabras, comprar un producto «porque sale más barato», sin mirar qué ocurre cuando tu proceso se desvía del que el producto da por supuesto, es tan arriesgado como construir a medida «porque somos especiales» sin haber comprobado antes si el mercado ya cubre el 90 % de lo que necesitas. En ambos casos, la factura real llega después, y rara vez llega sola.
Cuatro ejes para decidir con criterio
Y si el precio no es tan importante, ¿qué es lo que hay que tener en cuenta? Conviene evaluar la decisión sobre cuatro ejes. Son los que de verdad explican el coste a largo plazo.
- Coste total de propiedad, no precio inicial. El precio de una licencia o de un desarrollo es solo la primera línea de la cuenta. El coste real incluye integración, mantenimiento, formación, personalizaciones, renovaciones, migraciones y el coste de oportunidad de no poder cambiar algo cuando lo necesitas. Un producto barato que obliga a rehacer tres procesos internos deja de ser barato muy pronto.
- Gobierno: ¿quién decide el roadmap? Con un producto, el roadmap lo marca el fabricante; sus prioridades pueden coincidir con las tuyas hoy y dejar de hacerlo mañana. Con software a medida, el roadmap es tuyo, pero también lo es la responsabilidad de mantenerlo vivo. La pregunta clave es directa: cuando necesites un cambio que es crítico para ti pero irrelevante para el resto del mercado, ¿quién decide si se hace y cuándo?
- Evolución: ¿cómo cambia el software cuando cambia tu negocio? Ninguna operación se queda quieta. El software que elijas tendrá que acompañar cambios de proceso, de regulación, de volumen y de modelo de negocio. Un producto evoluciona en la dirección de su mercado; un desarrollo a medida evoluciona en la tuya. El riesgo de elegir mal aparece justo cuando más prisa tienes por cambiar.
- Dependencia: ¿qué pasa el día que quieras salir? Toda decisión de software crea algún grado de dependencia. La pregunta no es si existe, sino cuánto cuesta deshacerla. Formatos de datos cerrados, integraciones propietarias o conocimiento que vive solo dentro de un proveedor son formas de lock-in que no figuran en el contrato pero sí en la siguiente negociación de renovación. Esta es, por cierto, la misma dependencia invisible que vemos en otros terrenos: lo contamos a propósito de la IA conversacional en la Administración Pública, donde elegir «al proveedor más visible» y desplegar rápido acaba hipotecando decisiones que deberían seguir siendo tuyas.
Producto, a medida o híbrido: cómo se comportan en la práctica
Si proyectamos esos cuatro ejes sobre las tres opciones, el cuadro se ordena solo.
El producto estándar gana en arranque y coste inicial, pero su coste sube con cada personalización que lo aleja de la versión soportada, su roadmap no es tuyo y su dependencia puede ser alta si el formato de datos es cerrado. Encaja bien cuando el problema es común y tu diferencial está en otra parte.
El desarrollo a medida invierte la ecuación: arranque más lento y coste inicial mayor, a cambio de encaje total, roadmap propio y una dependencia baja, siempre que se construya evitando crear tu propio lock-in. Tiene sentido allí donde está tu ventaja competitiva, lo que de verdad te distingue.
El enfoque híbrido, comprar lo que es commodity y construir a medida lo que es diferencial, suele ser el que mejor envejece, porque reparte el gobierno por capas: velocidad donde no aporta diferenciarse, control donde sí.
Señales de que un producto estándar ha dejado de encajar
Muchos proyectos empiezan con un producto que encaja y terminan en un problema silencioso de deuda técnica. Conviene reconocer las señales a tiempo:
- Cada nueva necesidad se resuelve con una personalización que aleja el producto de su versión soportada, hasta que actualizar se convierte en un riesgo.
- El equipo dedica más tiempo a pelearse con las limitaciones de la herramienta que a sacarle partido.
- Los procesos del negocio se han ido adaptando al software en áreas que sí son diferenciales.
- Integrar el producto con el resto del ecosistema exige capas de pegamento cada vez más frágiles.
- Renovar la licencia ya no es una decisión, sino una factura inevitable, porque salir cuesta demasiado.
Ninguna de estas señales obliga a tirar nada por la borda. Pero todas indican que la decisión original merece revisarse antes de que la deuda técnica decida por ti.
Dónde encaja el open source
En la práctica, la mejor respuesta rara vez es purista, y aquí es donde el software libre y los estándares abiertos cambian la ecuación. Una base open source bien elegida ofrece la velocidad de un producto sin el lock-in de un formato cerrado: adoptas lo que ya está resuelto y conservas la capacidad de evolucionarlo, auditarlo o cambiar de proveedor sin reescribir tu operación. No es «gratis»; es capacidad de decisión, que es justo lo que protege tu inversión a diez años.
Es la forma en que entendemos la ingeniería en Irontec: desarrollamos software a medida cuando el diferencial lo justifica, nos apoyamos en producto y en open source donde aporta velocidad, y diseñamos cada sistema con separación de responsabilidades para que se pueda mantener y cambiar pieza a pieza. La misma lógica que aplicamos cuando ayudamos a una organización a migrar a la nube sin perder soberanía sobre sus datos, o cuando construimos arquitecturas auditables en lugar de cajas negras. La decisión técnica sólida no es la que parece más moderna hoy, sino la que sigue siendo reversible mañana.
