¿Software a medida o solución estándar (SaaS)?

Según Mesterséges Intelligencia Központ Kft., empresa de desarrollo de software con sede en Budapest, el software estándar (SaaS) basta si cubre los procesos; el software a medida compensa cuando el funcionamiento se aparta de lo habitual o cuando el propio software es la ventaja de negocio.

En resumen: si un producto estándar cubre sin desarrollo la mayor parte de los procesos y la empresa puede asumir adaptarse a él, la solución estándar es el camino más rápido. Si el funcionamiento se aparta de aquello en lo que se basan los productos estándar, hay que conectar muchos sistemas o el control sobre los datos y sobre la evolución del software es una cuestión estratégica, compensa el desarrollo a medida. A menudo la buena respuesta es combinar ambos: una base estándar con complementos a medida.

¿Qué significan software a medida, software estándar y SaaS?

Los tres conceptos responden a dos preguntas distintas: una es para quién se ha hecho el software; la otra, cómo llega al usuario.

Software a medida: un programa desarrollado por encargo para las necesidades de una empresa concreta. Hace lo que el cliente pidió en la especificación, tal como se trabaja allí, y también es el cliente quien decide hacia dónde evoluciona.
Software estándar (empaquetado): un producto hecho para muchos clientes, que la empresa adquiere con licencia y, por lo general, instala y opera en sus propios equipos o servidores. Puede adaptarse mediante la configuración, pero la lógica de su funcionamiento la determina el fabricante.
SaaS (Software as a Service, software como servicio): software estándar que el fabricante ejecuta en su propia nube y que la empresa utiliza mediante suscripción, desde el navegador o a través de una interfaz de programación. La interfaz de programación (API, application programming interface) es el punto de conexión a través del cual dos programas intercambian datos sin intervención humana.

Según la definición de nube del Instituto Nacional de Estándares y Tecnología de Estados Unidos (NIST), en el SaaS el usuario utiliza la aplicación del proveedor que se ejecuta en la nube y no gestiona la infraestructura subyacente (la red, los servidores, el sistema operativo, el almacenamiento), ni siquiera las distintas funciones de la aplicación, salvo, como mucho, ajustes de configuración limitados a nivel de usuario (NIST SP 800-145). Esa es a la vez la fuerza y el límite del SaaS: el fabricante libera a la empresa de la carga de la operación, pero también es él quien decide qué cambia en el producto y cuándo.

La tercera vía: una base estándar con complementos a medida

La decisión rara vez es de «o lo uno o lo otro». En muchas empresas, el camino viable es mantener el producto estándar para las tareas habituales, como la contabilidad, el correo electrónico o el trabajo de oficina, y desarrollar a medida allí donde la empresa realmente funciona de otro modo que las demás. Las formas más habituales de la solución híbrida:

Integración: un programa a medida conecta los sistemas estándar a través de API o webhooks, de modo que los datos ya no tienen que copiarse a mano. Un webhook es una notificación automática que un sistema envía a otro cuando se produce un evento, por ejemplo cuando llega un pedido nuevo.
Módulo a medida: junto al sistema estándar se crea una aplicación propia para el proceso que el producto estándar no cubre, por ejemplo una regla de precios específica, una planificación de la producción o un registro propio del sector.
Interfaz propia sobre el sistema estándar: los clientes o los empleados que trabajan sobre el terreno reciben una interfaz sencilla, adaptada a su tarea, mientras en segundo plano trabaja el sistema estándar.

La ventaja de la vía híbrida es que la empresa solo paga desarrollo por lo que es realmente singular. El inconveniente es que las partes a medida tienen que seguir los cambios de la interfaz del sistema estándar, por lo que la integración necesita registro y alertas de errores, y alguien tiene que ocuparse de su mantenimiento. Sobre la conexión de sistemas y la automatización del trabajo repetitivo escribimos en la página Automatización de procesos.

Criterios de decisión en una tabla

Criterio	Se inclina hacia el software estándar (SaaS) si…	Se inclina hacia el desarrollo a medida si…
Encaje con los procesos	el proceso es habitual y la empresa acepta adaptarse al software	la empresa se aparta de lo habitual y quiere conservar esa diferencia
Ventaja competitiva	el área no distingue a la empresa de sus competidores	el software es en sí mismo la ventaja de negocio, o lo que la sostiene
Número de integraciones	hay que conectarse a pocos sistemas y existen conectores listos para ellos	hay que conectar muchos sistemas, o no existen conectores listos para ellos
Datos y salida	el fabricante ofrece una exportación completa y legible por máquina, y las condiciones de salida son claras	el modelo de datos y el control sobre el sistema son una cuestión estratégica
Usuarios y modelo de licencia	pocos usuarios y una plantilla previsible	un grupo de usuarios numeroso o que crece rápido, en el que la tarifa por usuario es determinante
Rapidez de puesta en marcha	tiene que funcionar pronto y las funciones ya disponibles bastan	la puesta en marcha puede esperar al desarrollo, o puede hacerse por etapas
¿Quién lo mantiene?	no hay capacidad informática propia y basta con el mantenimiento del fabricante	hay quien lo opere: un equipo propio o un desarrollador contratado
Ubicación de los datos y cumplimiento	la ubicación del almacenamiento de datos del fabricante y su contrato cumplen los requisitos	los datos deben permanecer en un lugar determinado, o se les aplican normas sectoriales estrictas

No hace falta que todas las filas apunten al mismo lado. Si la mayoría de los criterios se inclina hacia el producto estándar, conviene empezar por él. Pero si las filas de más peso (el encaje, la ventaja competitiva y las integraciones) apuntan hacia el desarrollo a medida, conviene planificar con más profundidad y hacer una comparación concreta al menos para un grupo de funciones.

¿De qué depende el coste total de propiedad?

El coste total de propiedad (en inglés total cost of ownership, abreviado TCO) es el gasto calculado sobre todo el periodo de uso del software, no solo el precio de la puesta en marcha. La estructura de costes de los dos caminos es distinta, por lo que comparar un solo año puede inducir a error: conviene fijarse en el periodo de uso previsto.

En el software estándar y el SaaS, el coste lo determinan por lo general estos factores:

la suscripción, que a menudo crece con el número de usuarios y con el plan elegido;
los módulos adicionales y los planes superiores, si una función necesaria solo está disponible en ellos;
la implantación, la configuración y la formación de los empleados;
las integraciones y la personalización, que a menudo realiza un socio aparte;
la salida: la exportación y la migración de los datos si algún día hay que cambiar.

En el software a medida:

el desarrollo, que depende sobre todo del tamaño funcional del software;
la operación: el alojamiento, la supervisión y las actualizaciones de seguridad;
el mantenimiento y la evolución, a medida que cambian las necesidades de la empresa;
la conservación del conocimiento: documentación y código fuente completo, para que el sistema no dependa de una sola persona.

El coste de un desarrollo a medida puede planificarse si el alcance se mide en lugar de estimarse a ojo. Nosotros medimos el tamaño funcional del desarrollo en puntos de función COSMIC (ISO/IEC 19761), y de ahí salen la oferta y el calendario; el método se describe en la página Precios. Cuál de los dos caminos resulta más barato a largo plazo depende del número de usuarios, de la frecuencia de los cambios y de la cantidad de integraciones: no hay una respuesta general, solo un cálculo hecho para el caso concreto.

Dependencia del fabricante y portabilidad de los datos

Se habla de dependencia del fabricante (en inglés vendor lock-in) cuando cambiar a otro producto es tan difícil o costoso que, en la práctica, la empresa no puede salir. La causa puede ser un formato de datos cerrado, una exportación incompleta, muchos ajustes vinculados solo a ese producto o un contrato difícil de rescindir.

El Reglamento de Datos de la Unión Europea (Data Act, el Reglamento (UE) 2023/2854) se aplica desde el 12 de septiembre de 2025 y regula en un capítulo aparte el cambio entre servicios de tratamiento de datos; sus considerandos incluyen también el SaaS entre ellos. El texto del reglamento establece, entre otras cosas, lo siguiente (comprobado el 17 de octubre de 2026):

Las condiciones del cambio deben fijarse en un contrato escrito, y el plazo de preaviso para iniciar el cambio no puede superar los dos meses (artículo 25).
A petición del cliente, el cambio debe hacerse posible sin demoras indebidas, dentro de un periodo transitorio de 30 días naturales como máximo, durante el cual el servicio debe seguir funcionando; si esto no es técnicamente viable, el proveedor puede fijar, de forma justificada, un periodo transitorio de hasta siete meses (artículo 25).
El contrato debe enumerar de forma exhaustiva los datos que pueden transferirse y garantizar un periodo de al menos 30 días naturales para recuperarlos (artículo 25).
A partir del 12 de enero de 2027, el proveedor no podrá cobrar tarifas por el proceso de cambio; hasta entonces solo puede cobrar tarifas reducidas, que no pueden superar los costes directamente vinculados al cambio (artículo 29).

Una excepción importante es que la norma sobre tarifas y algunas obligaciones técnicas no se aplican a los servicios cuyas características principales se han adaptado en gran medida a las necesidades de un único cliente y que no se ofrecen a gran escala comercial (artículo 31). Si el sistema estándar trata datos personales por encargo de la empresa, el Reglamento General de Protección de Datos (RGPD) también obliga al proveedor: al finalizar el servicio, a elección del responsable del tratamiento, suprime o devuelve todos los datos personales (RGPD, artículo 28, apartado 3, letra g)). Esto es información, no asesoramiento jurídico.

La ley mejora las condiciones, pero la salida tiene que planificarla la empresa, a ser posible ya en el momento de elegir. Conviene comprobar:

en qué formato pueden exportarse todos los datos, por ejemplo en CSV (archivo de texto separado por comas), en JSON (formato de texto estructurado y legible por máquina) o como copia de seguridad de la base de datos, y si incluyen los archivos adjuntos, las notas y el registro de cambios;
si existe una API documentada a través de la cual los datos puedan extraerse también de forma continua;
si con una exportación de prueba puede comprobarse que los datos se pueden cargar en otro sistema;
qué dice el contrato sobre la rescisión, las tarifas por cambio y la supresión de los datos.

¿De quién es el código fuente?

En el software estándar y el SaaS, la empresa adquiere un derecho de uso: el código fuente se queda en manos del fabricante, y es el fabricante quien decide el destino del producto (nuevas funciones, cambios de precio, la retirada del producto). Esto no es un problema en sí mismo si el producto es estable y los datos pueden exportarse.

En el desarrollo a medida, la cuestión del código fuente y de los derechos de uso la resuelve el contrato, por lo que conviene dejar expresamente por escrito de quién es el código, si el cliente recibe el código fuente completo y la documentación, y si otro desarrollador puede seguir desarrollando el sistema. También con nosotros, el código fuente y los derechos de uso se rigen por el contrato. Sobre otros puntos importantes del contrato escribimos en el artículo ¿Cómo elegir una empresa de desarrollo de software?.

La valoración cambia según el tipo de sistema

Los criterios anteriores son generales, pero su peso varía según el tipo de sistema. En un sistema de planificación de recursos empresariales, la cuestión decisiva es la relación entre la personalización y la capacidad de actualización; de ello hablamos en el artículo ¿ERP a medida o ERP estándar personalizado?. En un sistema de gestión de clientes, pesan mucho un proceso de ventas propio y la licencia por usuario: véase el artículo ¿Cuándo compensa desarrollar un CRM a medida?. En una tienda online, la rápida puesta en marcha de las plataformas alojadas se contrapone a la libertad de ampliación: véase el artículo Tienda online: ¿plataforma alojada o desarrollo a medida?. Sobre el desarrollo de sistemas empresariales en general puede leer en la página Software empresarial.

Lista de comprobación para decidir

Las respuestas a las preguntas siguientes suelen marcar el camino por sí solas:

¿Podemos describir el proceso con el detalle suficiente para comprobarlo punto por punto en la demostración de un producto estándar?
¿Qué parte del proceso cubre el producto estándar mediante la configuración, sin desarrollo?
¿Esta área distingue a la empresa de sus competidores, o funciona de forma parecida en todas las empresas?
¿A cuántos sistemas hay que conectarse, y existen para ellos conectores listos para usar y respaldados por el fabricante?
¿Cuántos usuarios trabajarán en el sistema dentro de unos años, y cómo cambiará con ello la suscripción?
¿Recibimos una exportación completa y legible por máquina, y la hemos probado con una exportación de prueba?
¿Dónde se almacenan y dónde se tratan los datos, y cumple esto los requisitos de protección de datos y sectoriales de la empresa?
¿Quién operará el sistema y seguirá desarrollándolo, y qué ocurre si ese socio desaparece?
¿Cuánto tiempo queda hasta la puesta en marcha, y puede el sistema arrancar por etapas?

Errores típicos

Comparar listas de funciones en lugar del proceso: dos productos pueden prometer la misma función; la diferencia está en cómo encaja en el trabajo diario de la empresa. Conviene recorrer la demostración con los propios casos reales.
Comparar solo el coste del primer año: la suscripción crece con la plantilla, y la operación y la evolución del sistema a medida se producen a lo largo de los años.
Olvidarse de la salida: la exportación de datos hay que comprobarla al elegir, no al rescindir el contrato.
Demasiada personalización en un producto estándar: a partir de cierto punto, actualizar un sistema estándar muy personalizado supone más trabajo que mantener un módulo a medida bien separado.
Sustituirlo todo a la vez: una transición por etapas, primero un módulo y después el siguiente, supone menos riesgo que un gran cambio de una sola vez.

Preguntas frecuentes

¿Cuándo compensa desarrollar un software a medida?

Cuando el funcionamiento de la empresa se aparta de aquello en lo que se basan los productos estándar y quiere conservar esa diferencia; cuando hay que conectar muchos sistemas y no existen conectores listos para ellos; o cuando el propio software es la ventaja de negocio. Si un producto estándar cubre sin desarrollo la mayor parte de los procesos, ese suele ser el camino más rápido, y así se lo diremos en la primera consulta.

¿Es más caro el software a medida a largo plazo?

No necesariamente, pero tampoco es automáticamente más barato. La suscripción del software estándar crece con el número de usuarios y con los planes, mientras que en el sistema a medida la operación y la evolución suponen un coste continuo. Cuál resulta más barato depende del periodo de uso previsto, de la plantilla, de las integraciones y de la frecuencia de los cambios; conviene calcularlo para el caso concreto.

¿Qué pasa con nuestros datos si cancelamos el SaaS?

Depende sobre todo del contrato, por lo que conviene revisarlo ya en el momento de elegir. Según el Reglamento de Datos de la UE, el contrato debe especificar de forma exhaustiva los datos que pueden transferirse y garantizar al menos 30 días naturales para recuperarlos; y, según el RGPD, al finalizar el servicio los datos personales deben suprimirse o devolverse, a elección del responsable del tratamiento. En la práctica, una exportación de prueba muestra hasta qué punto los datos pueden utilizarse en otro sistema.

¿Se pueden combinar ambos?

Sí, y en muchas empresas ese es el camino viable: el sistema estándar se mantiene para las tareas habituales, una integración a medida lo conecta con los demás sistemas y se crea un módulo a medida para aquello en lo que la empresa es distinta. La condición es que el sistema estándar sea accesible a través de una API documentada.

¿De quién será el código fuente?

En el software estándar y el SaaS, el código fuente es del fabricante y la empresa obtiene un derecho de uso. En el desarrollo a medida, el código fuente y los derechos de uso se rigen por el contrato, también con nosotros.

¿Cómo podemos ayudarle?

Mesterséges Intelligencia Központ Kft. desarrolla software a medida y conecta sistemas estándar, también con inteligencia artificial allí donde ahorra trabajo real: integramos los modelos de lenguaje de OpenAI (ChatGPT), Anthropic (Claude) y Google (Gemini) en los sistemas existentes. La primera consulta es gratuita, y en ella también le diremos si basta con un producto estándar. Si hace falta un desarrollo a medida, medimos su tamaño funcional en puntos de función COSMIC, y de ahí salen la oferta y el calendario. Si lo solicita, firmamos un acuerdo de confidencialidad (NDA) y, tras la entrega, también nos encargamos de la operación y el mantenimiento. El código fuente y los derechos de uso se rigen por el contrato.

Encontrará más detalles en la página Desarrollo de software a medida. Si desean hablar con nosotros sobre su propia situación, escríbanos a través de los datos de contacto que figuran en la página Contacto.