No hay una respuesta universal
Un SaaS existente puede implantarse rápido, repartir costes entre muchos clientes y ofrecer mantenimiento continuo. El software a medida puede ajustar el flujo, integrarse profundamente y dar mayor control sobre evolución y datos. Ninguna opción gana por definición.
La decisión depende de cuánto diferencia ese proceso a la organización, qué requisitos son realmente específicos, cuánto cambio se espera y qué capacidad existe para operar la solución. También hay alternativas intermedias: configurar un SaaS, añadir una integración, desarrollar un módulo alrededor de una plataforma o construir sólo la parte diferencial.
Antes de comparar productos o pedir presupuestos conviene describir el problema y acordar criterios.
Definir el resultado esperado
Una lista de funciones no basta. “Gestión de clientes”, “dashboard” o “automatización” pueden significar cosas muy distintas. Es mejor describir resultados y escenarios:
- un usuario registra una solicitud con campos obligatorios;
- un responsable la aprueba con historial;
- el sistema recibe datos de una fuente concreta;
- una persona consulta el estado por permisos;
- se genera un informe antes de una hora límite;
- una incidencia puede revertirse sin perder operaciones.
Los escenarios permiten demostrar un SaaS y estimar un desarrollo con la misma referencia. También ayudan a separar requisitos imprescindibles, deseables y futuros.
Qué ofrece un SaaS
NIST define SaaS como el uso de aplicaciones del proveedor ejecutadas sobre infraestructura cloud, accesibles mediante cliente o interfaz de programa, sin que el consumidor gestione la infraestructura subyacente salvo configuraciones limitadas.
En la práctica, el proveedor opera una solución compartida o estandarizada, publica funcionalidades, mantiene infraestructura y cobra una suscripción o tarifa de uso. El cliente configura dentro de los límites del producto.
Sus ventajas habituales son velocidad de implantación, funcionalidades ya probadas, actualizaciones incluidas y menor necesidad de equipo técnico propio. Sus límites son adaptación, dependencia del roadmap, reglas de precio, exportación e integraciones disponibles.
Qué implica software a medida
El software a medida se diseña para requisitos de una organización o proceso. Puede ser propiedad del cliente o prestarse bajo distintas condiciones contractuales; “a medida” no determina por sí solo propiedad intelectual ni alojamiento.
Permite modelar flujos específicos y priorizar integraciones. A cambio, alguien debe asumir análisis, diseño, desarrollo, pruebas, seguridad, despliegue, soporte y evolución. El coste no termina al publicar la primera versión.
El control adicional sólo aporta si existe gobierno: responsable de producto, presupuesto de mantenimiento y capacidad para decidir prioridades.
Comparación por criterios
| Criterio | SaaS existente | Software a medida | Pregunta decisiva |
|---|---|---|---|
| Coste inicial | Normalmente menor | Normalmente mayor | ¿Qué configuración y migración faltan? |
| Coste recurrente | Suscripción por usuarios o uso | Operación, soporte y evolución | ¿Cómo crece a tres años? |
| Implantación | Rápida si hay ajuste | Más lenta por construcción | ¿Cuál es la fecha real necesaria? |
| Personalización | Dentro del producto | Alta, con coste | ¿El requisito es diferencial o preferencia? |
| Mantenimiento | Principalmente proveedor | Responsabilidad acordada | ¿Quién atiende seguridad y cambios? |
| Propiedad | Licencia de uso | Depende del contrato | ¿Qué activos y código se entregan? |
| Integraciones | Catálogo y API disponibles | Pueden diseñarse | ¿Los sistemas críticos están soportados? |
| Escalabilidad | Parte del servicio, con límites | Debe diseñarse y operarse | ¿Qué volumen y picos son reales? |
| Dependencia | Producto, precios y roadmap | Equipo, tecnología y conocimiento | ¿Cómo se cambia de opción? |
| Seguridad | Controles del proveedor y configuración del cliente | Responsabilidad compartida del proyecto | ¿Qué evidencia y obligaciones existen? |
La tabla describe tendencias, no garantías. Un SaaS complejo puede exigir una implantación larga; un desarrollo pequeño puede salir rápido. Hay que verificar cada alternativa.
Coste total, no sólo presupuesto inicial
Para un SaaS deben sumarse:
- licencias y crecimiento de usuarios;
- módulos adicionales;
- implantación y configuración;
- migración y limpieza de datos;
- integraciones;
- formación;
- soporte premium;
- almacenamiento o uso;
- salida y exportación al terminar.
Para software a medida:
- descubrimiento y diseño;
- desarrollo y pruebas;
- infraestructura;
- monitorización;
- seguridad y actualizaciones;
- soporte;
- cambios funcionales;
- documentación y transferencia;
- recuperación y continuidad.
La comparación debe usar un horizonte razonable, por ejemplo tres o cinco años, y varios escenarios de crecimiento. No debe asumir que el desarrollo queda “terminado” ni que la tarifa SaaS permanecerá igual.
Personalización: necesidad o hábito
Muchas peticiones de personalización reproducen la forma actual de trabajar, no una ventaja. Si un SaaS obliga a simplificar un proceso sin perder valor, adaptarse puede ser positivo.
Sin embargo, cuando la lógica es diferencial, está regulada, combina fuentes poco comunes o afecta directamente al servicio ofrecido, forzarla dentro de un producto puede generar trabajo paralelo y exportaciones manuales.
Una clasificación útil:
- requisito legal o contractual;
- requisito operativo crítico;
- diferenciador del negocio;
- preferencia de usuario;
- herencia del proceso actual.
Los tres primeros merecen más peso. Los dos últimos deben cuestionarse.
Velocidad de implantación
Un SaaS puede estar disponible hoy, pero implantado significa datos migrados, permisos configurados, integraciones probadas y usuarios formados. Una prueba gratuita no representa el esfuerzo completo.
El software a medida necesita más tiempo inicial, aunque un alcance pequeño puede entregar valor por fases. La comparación debe enfrentar fechas realistas para el primer proceso operativo, no “crear cuenta” frente a “construir todo”.
Si la urgencia es alta y el proceso estándar, el SaaS tiene ventaja. Si una solución temporal crea una migración costosa pocos meses después, conviene incluir ese coste.
Integraciones y portabilidad
La demostración debe probar las integraciones críticas. “Tenemos API” no confirma que incluya recursos, permisos, frecuencia o volumen necesarios. Hay que revisar documentación, límites y acceso contractual.
También se evalúa la salida:
- formatos de exportación;
- frecuencia y volumen;
- acceso a adjuntos e historial;
- identificadores conservados;
- plazo tras cancelar;
- coste de extracción;
- documentación del esquema.
En software a medida, la portabilidad debe diseñarse. Controlar el código no garantiza disponer de una exportación útil si nadie la construye.
Escalabilidad
Escalar no es sólo soportar más registros. Incluye usuarios concurrentes, equipos, países, permisos, integraciones, soporte y ritmo de cambio.
El SaaS suele repartir infraestructura y operación, pero puede imponer límites o cambiar de plan. El software a medida puede optimizarse para la carga real, pero requiere medir y ampliar recursos.
No conviene pagar hoy por una escala hipotética ni ignorar un crecimiento ya contratado. Los escenarios deben usar datos: usuarios actuales, previsión, tamaño por operación y picos.
Seguridad y cumplimiento
En un SaaS se evalúan controles del proveedor, ubicación y tratamiento de datos, subencargados, autenticación, registros, copias, respuesta a incidentes y compromisos contractuales. El cliente sigue siendo responsable de configurar accesos y usarlo correctamente.
En software a medida, esas capacidades deben especificarse y mantenerse. Elegir desarrollo propio no concede seguridad automática; aumenta decisiones bajo control y también responsabilidades.
La profundidad de la evaluación depende de datos e impacto. Una herramienta para material público no exige el mismo nivel que un sistema con información sensible.
Dependencia de proveedor y de equipo
El SaaS crea dependencia de precio, continuidad, roadmap y formatos. El software a medida crea dependencia de personas, documentación, tecnología e infraestructura. La pregunta no es eliminar dependencia, sino hacerla visible y gestionable.
Medidas útiles:
- contrato y niveles de servicio proporcionados;
- exportación probada;
- documentación;
- credenciales bajo control de la organización;
- repositorio y despliegue acordados;
- varios responsables con conocimiento;
- plan de continuidad;
- revisión de alternativas.
Una puntuación ponderada
Puede asignarse peso a cada criterio y puntuar opciones con evidencia. Por ejemplo:
| Criterio | Peso | Evidencia esperada |
|---|---|---|
| Ajuste a procesos críticos | 25 % | Demostración con escenarios |
| Coste total | 20 % | Modelo a tres años |
| Implantación | 15 % | Plan, dependencias y responsables |
| Integraciones | 15 % | Documentación y prueba técnica |
| Seguridad | 15 % | Controles y contrato |
| Portabilidad | 10 % | Exportación de prueba |
Los pesos cambian según organización. Lo importante es no decidir por una única demostración ni manipularlos después para justificar una preferencia.
Estrategias híbridas
No siempre hay que elegir extremos.
- SaaS estándar más integración propia.
- SaaS con un portal específico alrededor.
- Software a medida para el núcleo diferencial y herramientas existentes para funciones comunes.
- Automatización temporal mientras se valida el proceso.
- Desarrollo progresivo que sustituye módulos concretos.
Estas combinaciones reducen alcance, pero añaden fronteras que deben mantenerse.
Señales para cada opción
Un SaaS suele encajar si el proceso es común, la herramienta cubre requisitos críticos, el tiempo importa, las integraciones existen y la organización acepta sus límites.
El desarrollo a medida merece estudio si el proceso diferencia realmente, las reglas específicas son estables, la integración es central, ninguna alternativa cubre el núcleo y existe capacidad de mantenerlo.
Si todavía no se entiende el proceso, ninguna compra ni desarrollo debería comenzar. Un prototipo o una fase de descubrimiento puede ahorrar una decisión costosa.
Tomar una decisión reversible
Documentar supuestos, revisar la salida de datos y dividir la implantación reduce el coste de equivocarse. Un piloto debe probar el caso más representativo, no sólo el más fácil.
La decisión final puede ser SaaS, software a medida, combinación o incluso mantener la herramienta actual. Si el punto de partida es una operación sostenida en hojas, la guía para migrar de Excel a un SaaS sin detener la operación concreta las pruebas, el periodo de convivencia y el rollback. El criterio es el coste total para alcanzar el resultado con un nivel de control y riesgo aceptable, no favorecer de antemano una forma de construir software.