Elegir entre SaaS y software a medida no es una discusión entre rapidez y control. Es una decisión sobre qué parte de la operación puede adaptarse a un producto estándar, qué parte diferencia al negocio y quién asumirá el coste y la responsabilidad de mantenerla durante años.
Un SaaS puede resolver antes una necesidad común. Una solución a medida puede encajar mejor en un proceso singular. Y muchas decisiones sensatas terminan en un modelo híbrido: comprar la capacidad básica y construir solo la capa que aporta diferenciación, integración o control.
1. Empieza por el proceso, no por una lista de funciones
Describe el resultado que necesita el negocio, las personas que participan, los sistemas implicados y las excepciones que hoy requieren criterio. Después separa lo esencial de lo accesorio. Una función llamativa en una demostración no compensa que el flujo principal obligue a copiar datos, cambiar de herramienta o trabajar fuera del sistema.
Pregunta también si el proceso es realmente diferencial. Facturación, firma, soporte o gestión documental suelen tener patrones maduros en el mercado. La forma en que una empresa configura una oferta, coordina una operación especializada o aplica sus reglas de negocio puede ser mucho más propia.
La primera hipótesis puede resumirse así: compra lo común cuando encaje de verdad; construye aquello que sea difícil de sustituir y merezca una capacidad propia.
2. Compara seis dimensiones con evidencia
La decisión mejora cuando cada alternativa se evalúa con los mismos criterios y sobre casos reales, no sobre promesas comerciales.
- Encaje con el proceso. ¿Qué porcentaje del flujo funciona mediante configuración y dónde aparecen cambios, hojas paralelas o trabajo manual? Distingue una preferencia interna de una necesidad que afecta al resultado.
- Tiempo hasta obtener valor. Incluye selección, contratación, configuración, migración, integración, formación y adopción. En un desarrollo, incluye descubrimiento, diseño, construcción y estabilización; no solo la programación.
- Coste total durante el ciclo. Suma licencias, usuarios, consumo, implantación, integraciones, soporte, evolución, seguridad, migraciones y salida. En software propio, añade operación, observabilidad, infraestructura, pruebas y capacidad de producto.
- Integración y datos. Comprueba APIs, límites, autenticación, sincronización, exportación, calidad del dato y comportamiento cuando otro sistema falla. La integración no es un apéndice: puede determinar el coste real.
- Control y capacidad de cambio. Evalúa quién decide el roadmap, cuánto tarda un cambio, qué restricciones existen y qué ocurre si el proveedor modifica precio, funcionalidad o condiciones.
- Responsabilidad operativa. En ambos modelos alguien debe gestionar accesos, incidencias, continuidad, privacidad, seguridad y soporte a usuarios. Comprar software no elimina esa responsabilidad; cambia su reparto.
El Service Standard del Gobierno británico recomienda entender el coste total de propiedad y conservar la posibilidad de cambiar de dirección, por ejemplo mediante estándares abiertos y evitando dependencias contractuales innecesarias.
3. Señales de que SaaS puede ser la mejor opción
- La necesidad es común y el producto cubre el flujo principal sin alterar cómo opera el negocio.
- La configuración disponible resuelve las diferencias importantes sin crear una capa frágil de excepciones.
- El proveedor demuestra una operación, seguridad, soporte y evolución que sería costoso reproducir internamente.
- Las integraciones necesarias están documentadas, se pueden probar y no dependen de exportaciones manuales.
- Los datos pueden recuperarse en un formato utilizable y existe un procedimiento de salida asumible.
El riesgo aparece cuando se compra por la demostración y se descubre después que el equipo debe deformar el proceso o personalizar el producto más allá de su propósito. La guía oficial británica sobre estrategia de compra advierte que incluso modificaciones pequeñas en software estándar pueden reducir las ventajas de utilizarlo, dificultar el mantenimiento y limitar futuras actualizaciones.
4. Señales de que merece explorar software a medida
- El proceso es una parte real de la ventaja competitiva o de la experiencia que se quiere ofrecer.
- Las alternativas comerciales obligan a renunciar a reglas esenciales, multiplicar pasos manuales o mantener sistemas paralelos.
- La solución debe coordinar varios sistemas, fuentes de datos o perfiles con una lógica propia difícil de configurar.
- El roadmap necesita responder a prioridades del negocio y no al calendario de un proveedor de producto.
- La organización dispone —internamente o con un partner— de capacidad para gobernar el producto después del lanzamiento.
A medida no significa construir todo desde cero. Un producto propio también se apoya en servicios gestionados, bibliotecas y plataformas existentes. La decisión útil consiste en identificar qué capa merece ser propia y qué componentes deben seguir siendo estándar.
5. El enfoque híbrido suele ser una opción, no un compromiso débil
Un modelo híbrido puede combinar identidad, facturación, almacenamiento o comunicaciones como servicios consolidados con una aplicación propia que orquesta el proceso diferencial. Así se evita recrear capacidades comunes y se conserva control sobre la experiencia, las reglas y los datos que importan.
La condición es diseñar límites claros. Define qué sistema es la fuente de cada dato, qué contrato tiene cada integración, cómo se gestionan los fallos y qué componente puede sustituirse sin reconstruir el conjunto. Sin esos límites, el híbrido puede convertirse en una red de dependencias difícil de operar.
6. Haz un experimento de decisión antes de comprometer presupuesto
No necesitas decidir solo con documentos. Diseña una prueba pequeña que exponga la parte difícil de cada alternativa.
- Selecciona tres escenarios: el caso frecuente, una excepción relevante y una situación de fallo o indisponibilidad.
- Prueba el SaaS con datos representativos y una integración realista, no únicamente con el recorrido preparado por ventas.
- Para la opción a medida, construye un prototipo o una prueba técnica que valide la mayor incertidumbre, no una versión reducida de todo el producto.
- Mide esfuerzo de configuración, calidad del resultado, intervención manual, comportamiento de la integración y facilidad para recuperar los datos.
- Registra supuestos, límites y costes pendientes. Una prueba no convierte una estimación en garantía.
Si cualquiera de las opciones va a producir o integrar software, la seguridad debe formar parte del alcance. El marco SSDF de NIST ofrece prácticas de desarrollo seguro y un vocabulario común que también pueden utilizar compradores y proveedores para concretar expectativas durante una adquisición.
7. Utiliza una matriz ponderada, no una suma automática
Asigna a cada criterio un peso de 1 a 5 según su importancia para el negocio y puntúa cada alternativa con evidencia. Añade una columna para la confianza de la estimación: una puntuación basada en una prueba vale más que otra basada solo en una presentación.
- Encaje del flujo y de las excepciones.
- Tiempo hasta el primer resultado utilizable.
- Coste total a tres años y sensibilidad al crecimiento.
- Integración, calidad y portabilidad de datos.
- Seguridad, continuidad y trazabilidad.
- Capacidad de evolución y coste de salida.
- Equipo disponible para operar y mejorar la solución.
La cifra final no sustituye la conversación. Sirve para hacer visibles los supuestos y detectar qué dato podría cambiar la decisión.
Preguntas que deben quedar respondidas
- ¿Qué necesidad no puede sacrificarse y por qué?
- ¿Qué parte del proceso es común y cuál es diferencial?
- ¿Qué integraciones y migraciones son imprescindibles?
- ¿Quién será propietario del servicio y de su roadmap?
- ¿Qué costes aumentan con usuarios, volumen o complejidad?
- ¿Cómo se exportan los datos y cómo se cambia de proveedor?
- ¿Qué capacidad de soporte, seguridad y evolución existe después del lanzamiento?
La mejor decisión mantiene abiertas las opciones importantes
SaaS es una buena compra cuando resuelve una necesidad común con poca fricción y una salida razonable. El software a medida tiene sentido cuando el proceso necesita una capacidad propia y existe compromiso para mantenerla. El enfoque híbrido funciona cuando cada límite está diseñado y operado de forma explícita.
Si estás comparando alternativas, en Codiloop podemos ayudarte a preparar un diagnóstico de software a medida centrado en el proceso, las integraciones, el coste total y el experimento que reduzca la incertidumbre antes de comprometer el presupuesto.