Software a la medida o software comercial: cómo decidir qué le conviene a tu empresa

La pregunta correcta no es "¿cuál es mejor?"

Casi todas las discusiones sobre software a la medida versus software comercial empiezan mal, porque se plantean como una preferencia: "nosotros preferimos desarrollar" o "nosotros compramos todo". Esa es una conversación de gustos, no de negocio.

La pregunta útil es otra: ¿este proceso es una fuente de diferenciación para tu empresa o es una función de soporte que todos los competidores hacen más o menos igual? Nómina, contabilidad, firma electrónica, correo y control de accesos son funciones de soporte. Nadie gana clientes porque su módulo de nómina sea especial. En cambio, el motor de cotización de una aseguradora, el algoritmo de ruteo de una distribuidora o el flujo de aprobación de crédito de una fintech sí definen el margen.

Regla práctica: compra lo que te iguala, construye lo que te diferencia. Suena simple, pero disciplinarse a seguirla evita la mayoría de los proyectos fallidos que vemos.

Tres opciones, no dos

Plantear la decisión como binaria empobrece el análisis. En realidad tienes al menos tres caminos, y la mayoría de las empresas terminan combinándolos.

• Comprar y usar tal cual: tomas un SaaS comercial y adaptas tu proceso al software. Es la vía más rápida y barata en costo total, pero exige disciplina para no pedir excepciones.

• Comprar y extender: usas la plataforma como núcleo y construyes encima lo específico, vía APIs, webhooks o módulos propios. Es el modelo dominante hoy: Shopify + lógica propia de precios, Salesforce + integraciones a medida, un ERP estándar + un portal de proveedores propio.

• Construir: desarrollas el sistema desde cero porque no existe nada que resuelva tu caso o porque lo que existe te impone un modelo de negocio distinto al tuyo.

Siete criterios para decidir, en orden de peso

Cuando acompañamos a un comité de TI en esta decisión, evaluamos de forma explícita estos puntos. Lo importante no es el resultado numérico, sino obligar a la organización a responder con datos en vez de intuiciones.

• Diferenciación: ¿el proceso es una ventaja competitiva o una obligación operativa? Si es obligación, compra.

• Ajuste funcional real: toma tus 20 requisitos críticos y verifica cuántos resuelve el producto comercial sin personalización. Por debajo de 70% de ajuste, el costo de forzarlo suele superar al de construir.

• Volumen y escala: si procesas 500 transacciones al mes, el costo por licencia es irrelevante; si procesas 5 millones, el modelo de precios por transacción puede volverse insostenible y la economía cambia a favor del desarrollo propio.

• Velocidad requerida: un SaaS está operando en semanas; un desarrollo serio toma meses. Si tu ventana comercial es de un trimestre, la decisión ya está tomada.

• Capacidad de mantenimiento: el software a la medida es un activo que requiere equipo, no un proyecto que termina. Si no puedes sostener al menos dos personas dedicadas (o un contrato de soporte real), no construyas.

• Regulación y datos: sectores con requisitos estrictos de residencia de datos, auditoría o trazabilidad a veces no encuentran producto comercial que cumpla, o el que cumple cuesta tres veces más.

• Riesgo de dependencia: evalúa qué pasa si el proveedor sube precios 40%, es adquirido o descontinúa el producto. Pregunta siempre: ¿puedo exportar mis datos en un formato usable?

Los costos que nadie pone en la hoja de cálculo

La comparación típica enfrenta el precio de las licencias contra la cotización del desarrollo. Esa comparación casi siempre está mal hecha, en ambas direcciones.

Del lado del software comercial se olvidan: la implementación y migración de datos (que suele costar entre una y tres veces la licencia anual del primer año), la capacitación, los conectores e integraciones, los módulos adicionales que descubres que necesitas en el mes cuatro, el crecimiento de usuarios y el incremento anual de precio, que en la industria ronda el 5-10%. También el costo silencioso de adaptar tu operación al software: si tu equipo de ventas pierde 20 minutos diarios capturando dos veces lo mismo, eso es dinero.

Del lado del desarrollo a la medida se olvidan: el mantenimiento evolutivo (presupuesta entre 15% y 25% anual del costo de construcción), la deuda técnica, las actualizaciones de seguridad y dependencias, la infraestructura, el monitoreo, la documentación y —el más caro de todos— el riesgo de concentración de conocimiento en una o dos personas que algún día renunciarán.

Haz el ejercicio a cinco años, no a uno. Es sorprendente cuántas decisiones se invierten cuando se extiende el horizonte.

Tres escenarios concretos

Caso 1. Distribuidora de consumo masivo, 180 empleados. Querían un CRM a la medida porque "su proceso de venta es único". Al mapear los 20 requisitos, 17 los cubría un CRM comercial de mercado medio. Los otros tres —cálculo de cuotas por combo promocional, visibilidad de inventario en tiempo real y cobranza en ruta— se resolvieron con integraciones y una app móvil ligera propia. Resultado: en producción en 10 semanas, con un costo cercano a un tercio del desarrollo completo.

Caso 2. Empresa de logística de última milla. Evaluaron cinco plataformas de ruteo. Ninguna manejaba su restricción clave: ventanas de entrega negociadas en WhatsApp que cambian durante el día. Era precisamente su promesa comercial. Ahí construir tenía sentido, y se construyó solo ese motor, dejando facturación, contabilidad y nómina en productos comerciales.

Caso 3. Institución financiera regional. Tenía un core bancario propio de 15 años, mantenido por tres personas. El sistema funcionaba, pero cada cambio normativo tomaba meses y el riesgo de personal era crítico. La decisión no fue reemplazar todo de golpe, sino encapsular el core con APIs y migrar módulos por etapas hacia productos especializados. Tres años de plan, no tres meses.

Cómo reducir el riesgo, elijas lo que elijas

Independientemente del camino, hay prácticas que separan las implementaciones que sobreviven de las que se abandonan.

• Haz una prueba de concepto con datos reales antes de firmar. Una demo guiada por el vendedor no prueba nada; carga tu catálogo real, tus casos raros y mide.

• Define el modelo de datos como activo propio. Tus datos deben poder salir. Exige exportación completa y documentada por contrato.

• Diseña con fronteras claras: si construyes, hazlo modular y con APIs, para poder reemplazar piezas sin rehacer todo.

• Nombra un responsable de negocio, no solo de TI. Los proyectos sin dueño funcional derivan en catálogos de requisitos sin prioridad.

• Evita la personalización profunda de productos comerciales. Cada customización rompe actualizaciones y crea una versión huérfana que nadie quiere mantener.

• Empieza por el proceso, no por la herramienta. Automatizar un proceso malo solo lo hace fallar más rápido.

Una decisión que se revisa, no se graba en piedra

Ninguna elección de este tipo es definitiva. Las condiciones cambian: el volumen crece, aparece un producto que antes no existía, el modelo de precios del proveedor se vuelve hostil o el proceso que era diferenciador se estandariza en la industria. Lo sano es revisar el portafolio de aplicaciones una vez al año y preguntarse, sistema por sistema, si sigue siendo la opción correcta.

También conviene aceptar que la mayoría de las arquitecturas maduras son híbridas: un núcleo comercial sólido para lo estándar, piezas propias donde está el valor y una capa de integración bien pensada que las une. La discusión "comprar o construir" suele resolverse en "comprar esto, construir aquello, integrar bien".

Si estás en medio de esta decisión y quieres contrastar tu análisis con alguien que ha visto cómo terminan ambos caminos, en Da2 Group podemos revisar contigo el ajuste funcional, los costos a cinco años y las opciones de arquitectura. Sin compromiso: a veces la conversación más útil es la que confirma que ya ibas bien encaminado.