Software a medida o SaaS: cómo saber qué necesita tu empresa

La pregunta llega casi siempre formulada al revés: «¿nos conviene un sistema a la medida o compramos un SaaS?». Planteada así no tiene respuesta, porque el software no es la decisión. La decisión es qué parte de la operación vale la pena conservar tal como está y qué parte está costando dinero todos los meses.

A veces la mejor decisión es configurar una herramienta existente. Otras veces el costo de adaptar personas y procesos a un sistema genérico termina siendo mayor que construir una solución específica. Distinguir esos dos escenarios antes de escribir código es, en la práctica, el trabajo.

Cinco señales de que el proceso no cabe en una plantilla

No son reglas absolutas: son las situaciones en las que, por experiencia, un producto genérico empieza a devolver menos de lo que cuesta.

• La operación vive en hojas, chats y memoria. La información existe, pero cada paso depende de alguien que recuerde qué sigue o dónde buscar.
• Se captura lo mismo varias veces. Ventas, administración u operación repiten datos porque las herramientas no se comunican.
• El sistema actual obliga a trabajar fuera de él. El equipo termina creando Excel, WhatsApp o procesos paralelos para completar lo que el software no resuelve.
• No existe trazabilidad suficiente. Es difícil reconstruir quién hizo qué, cuándo cambió un estado, qué dato originó una decisión o dónde se detuvo un proceso.
• La lógica del negocio es específica. Rutas, reglas, permisos, cotizaciones, conciliaciones, cálculos o excepciones no caben bien en una solución estándar.

Una sola de estas señales rara vez justifica un desarrollo. Tres o cuatro a la vez, sobre un proceso frecuente, suelen significar que la empresa ya está pagando el sistema a medida —en horas, en errores y en reprocesos— sin tenerlo.

Cuándo un producto existente es la respuesta correcta

El desarrollo a medida funciona mejor cuando existe un problema operativo identificable. Cuando no lo hay, un SaaS bien configurado gana casi siempre. Conviene sospechar de un proyecto propio si la necesidad es genérica y un producto existente ya la resuelve razonablemente bien; si no hay dentro de la empresa un responsable que valide decisiones; si la prioridad real es una pieza visual o una campaña puntual; si el volumen no justifica automatizar ni dejar rastro; o si nadie puede dedicar tiempo a descubrimiento, validación y adopción.

Ese último punto se subestima siempre. Un sistema a medida se construye con la operación, no para la operación. Si nadie puede probarlo con usuarios reales, el mejor software posible se queda en una demo cara.

Si el problema puede resolverse configurando algo que ya existe, también debemos ser capaces de decirlo.

Hay una tercera salida: integrar en lugar de reemplazar

La conversación suele plantearse como si sólo hubiera dos caminos, y casi siempre hay un tercero. No todo lo que ya funciona tiene que tirarse.

Un sistema a medida puede convertirse en la capa que coordina herramientas existentes. Antes de proponer una sustitución completa revisamos qué plataformas contienen datos útiles, qué APIs ofrecen, qué procesos ya están adoptados y dónde conviene conectar en lugar de reemplazar. ERP, CRM, WhatsApp, correo, pagos, bases de datos, servicios de geolocalización, APIs de terceros o herramientas internas: cada uno puede quedarse donde está y aun así dejar de ser una isla.

Cambiar un sistema que la gente ya sabe usar tiene un costo de adopción que no aparece en ninguna cotización, pero se cobra igual.

Lo que decide el costo no es el número de pantallas

Dos sistemas con diez pantallas pueden tener complejidades completamente diferentes. Lo que mueve el costo son las reglas, las integraciones, la calidad de los datos, la migración, los permisos, la seguridad, el volumen, la disponibilidad, el soporte y el nivel de incertidumbre con el que se empieza.

Por eso antes del precio definimos problema, alcance, responsables, entregables, supuestos, dependencias, criterios de aceptación y soporte posterior. Una cotización hecha antes de eso no es un precio: es una apuesta con el dinero de alguien más.

Lo que se define antes de elegir tecnología

Cuando la decisión se inclina hacia un sistema propio, la interfaz es sólo una parte. Antes de elegir framework o proveedor hay que poder responder seis preguntas:

• Roles y permisos. Quién puede ver, crear, aprobar, corregir o cancelar.
• Datos y fuentes de verdad. Qué registro manda cuando dos sistemas muestran información distinta.
• Estados y reglas. Qué condiciones permiten avanzar, detener o escalar un proceso.
• Integraciones. Qué datos entran o salen de ERP, CRM, WhatsApp, pagos, correo, APIs o sistemas existentes.
• Trazabilidad. Logs, historial, versiones y evidencia suficiente para entender qué ocurrió.
• Operación y soporte. Quién monitorea, qué sucede ante una falla y cómo se corrige sin perder continuidad.

Si esas seis respuestas existen, la elección técnica se vuelve una consecuencia. Si no existen, ninguna tecnología las va a inventar.

Entonces, ¿cuál de los dos?

La forma útil de preguntarlo es otra: ¿el costo de adaptar la operación a un producto genérico es mayor que el de construir alrededor de las reglas que ya tiene? Cuando la respuesta es no, conviene configurar. Cuando es sí, conviene construir —y empezar por el incremento más pequeño que permita probar la parte más importante del sistema, no por todo el sistema—.

Y cuando no está clara, casi siempre falta describir el proceso antes de elegir la herramienta.