Software a medida o enlatado: cómo decidir sin equivocarse

Nosotros vendemos las dos cosas. Tenemos dos SaaS propios —productos enlatados, con licencia por uso— y también hacemos desarrollo a medida. Eso me pone en una posición cómoda para escribir esto: no tengo que empujarte hacia un lado.

Y voy a empezar con la conclusión, porque es la parte que casi nunca se dice:

La mayoría de las empresas no necesitan todo a medida, y la mayoría tampoco logra que un enlatado les sirva completo. La respuesta correcta casi siempre es una mezcla. El problema es que esa respuesta no le conviene comercialmente ni al que vende licencias ni al que vende horas de desarrollo.

Primero: la pregunta que casi nadie hace bien

Antes de comparar opciones, hay una pregunta que ordena toda la decisión:

¿Esta parte de mi operación es igual a la de cualquier otra empresa de mi sector, o es algo que hago distinto y me da ventaja?

Suena filosófico y es puramente práctico. Porque:

Lo que es igual en todas las empresas, cómpralo hecho. Contabilidad, facturación electrónica, nómina, correo, firma de documentos. No hay ninguna ventaja competitiva en tener una contabilidad hecha a la medida. Es un problema resuelto, hay productos maduros, cumplen normativa y alguien más se encarga de actualizarlos cuando la ley cambia. Construir esto a medida es quemar plata.

Lo que te diferencia, ahí sí evalúa construir. La forma particular en que despachas material a las obras, cómo controlas el avance de un contrato, cómo asignas cuadrillas. Si eso lo haces distinto y funciona mejor, un enlatado te va a obligar a hacerlo como todos los demás — y a perder justo la parte que te hacía bueno.

La mayoría de las empresas necesita enlatado para el 70% y desarrollo propio para el 30% que las hace distintas.

Software enlatado: lo bueno y lo que no dice el vendedor

Lo bueno es real. Arranca rápido —semanas, no meses. Cuesta menos al principio. Alguien más lo mantiene, lo actualiza y responde cuando cambia una norma. Ya está probado por otras empresas, así que los bugs obvios ya los encontró alguien más. Y tiene soporte, documentación y a veces comunidad.

Lo que no dice el vendedor:

El precio de lista no es el precio. Suma implementación, migración de datos, capacitación, y los módulos que “vienen aparte”. Es común que la factura del primer año sea el doble de lo cotizado inicialmente.

Vas a torcer tus procesos para que quepan. Este es el costo invisible, el más grande y el que jamás aparece en una cotización. Si tu forma de manejar remisiones no coincide con la del sistema, alguien va a hacer un paso manual todos los días, o va a mantener un Excel paralelo. Ese Excel paralelo es la señal más clara de que el enlatado no encajó.

El costo por usuario escala mal. Cuarenta mil pesos por usuario al mes suena razonable con diez usuarios. Con doscientos es un problema estructural, y crece justo cuando la empresa crece.

Lo que no está, no va a estar. Puedes pedirlo. Si no le sirve a los otros clientes del proveedor, no lo van a hacer. Y está bien: un producto que le dice sí a todos termina siendo malo para todos.

El dato es tuyo pero vive allá. Pregunta antes de firmar cómo se exporta todo si algún día te vas. Si la respuesta es vaga, ya sabes.

Software a medida: lo bueno y lo que no dice el desarrollador

Lo bueno es real también. Encaja con cómo trabajas, sin torcer nada. Sin licencias por usuario: doscientas personas cuestan lo mismo que veinte. Se integra con lo que ya tienes porque se diseñó para eso. Y puede llegar a ser una ventaja competitiva de verdad — es exactamente por eso que construimos nuestros propios SaaS en lugar de revender los de otro.

Lo que no dice el desarrollador:

Toma tiempo. Meses, no semanas. Y en ese tiempo tú sigues operando con lo que tienes.

Los requisitos nunca están completos al principio. Nadie logra especificar todo antes de ver algo funcionando. Esto no es un defecto del cliente ni del proveedor, es la naturaleza del trabajo. Por eso lo sano es entregar por partes y ajustar, no firmar un documento gigante y desaparecer tres meses.

El mantenimiento es tuyo. Cuando cambie una norma, cuando salga una versión de navegador que rompe algo, cuando quieras un reporte nuevo — eso lo pagas tú. Presupuéstalo desde el día uno, no cuando aparezca.

Dependes de quien lo construyó. Es el riesgo más real. Se mitiga, pero hay que exigirlo explícitamente:

• El código es tuyo y está en un repositorio al que tú tienes acceso. No negociable.
• Tecnologías estándar, no un framework raro que solo tres personas en el país conocen.
• Documentación mínima de cómo se despliega y cómo está armado.
• Entregas que funcionen desde la primera, para que si se rompe la relación, te quedes con algo usable y no con un 60% inservible.

Si un proveedor se pone incómodo con estas cuatro condiciones, ahí tienes tu respuesta.

La tabla de decisión

Esa última fila merece su propio párrafo, porque es la trampa más común: “eso se personaliza” puede significar cambiar un color, o puede significar un desarrollo cotizado aparte que tarda seis meses. Pide siempre verlo funcionando, no descrito.

Un caso concreto de nuestra experiencia

Lo cuento porque ilustra la mezcla mejor que cualquier teoría.

En Gextyon Proyectos, la parte de control de obra por APU —contratos, partidas, cortes, destajos— es a medida en su lógica. No porque quisiéramos construir cosas, sino porque la forma en que una constructora colombiana mide avance y liquida a un contratista no coincide con lo que hacen los productos internacionales de gestión de proyectos. Intentar meter eso en una herramienta genérica termina en el Excel paralelo del que hablé arriba.

Pero la contabilidad no la construimos. La facturación electrónica tampoco. Eso se integra con quien ya lo hace bien y cumple con la DIAN.

Ese es el criterio en la práctica: construye tu diferencia, compra tu obligación.

Cómo evaluar sin equivocarte

Cuatro pasos que evitan la mayoría de los errores caros:

1. Escribe cómo trabajas hoy, con lo malo incluido. Sin esto no puedes evaluar nada. Y en el ejercicio casi siempre aparecen pasos que no deberían existir — eliminarlos es gratis y a veces resuelve el problema completo.

2. Evalúa al menos tres enlatados de verdad. No por folleto: con tus datos, con tu gente, haciendo tu proceso real. Los demos siempre funcionan; lo que importa es qué pasa con tu caso raro.

3. Anota exactamente dónde no encaja cada uno. Y clasifica cada desencaje: ¿es un capricho nuestro, o es esencial? Muchas veces el “así lo hacemos siempre” no tiene ninguna razón detrás.

4. Recién ahí cotiza desarrollo, solo para lo esencial que no encajó. Vas a descubrir que es mucho menos de lo que pensabas al principio. Y que se puede construir sobre lo que ya compraste, en lugar de reemplazarlo. Para saber qué esperar de esas cifras, mira cuánto cuesta desarrollar software en Colombia.

Si sales de ese proceso con “compramos esto y desarrollamos solo este pedazo”, llegaste a la respuesta correcta.

La señal de alarma

Si estás considerando desarrollo a medida porque nadie en la empresa se puso de acuerdo en cómo debería funcionar el proceso, para. El software no resuelve eso — lo congela.

Un desarrollo a medida sobre un proceso que nadie tiene claro produce un sistema que nadie usa. Lo hemos visto, y ninguna cantidad de buen código lo arregla.

Ordena el proceso primero. Después conversamos de con qué lo operas.