SaaS del mercado o software a medida: cómo decidir qué le conviene a tu empresa

Si una herramienta del mercado resuelve bien vuestro problema, lo normal es que sea mejor empezar por ahí que construir software propio. Os ahorráis el desarrollo, alguien la mantiene por vosotros y podéis probarla antes de comprometeros. Comprar suele ganar cuando la necesidad es la misma que tienen muchas otras empresas: gestionar clientes, facturar, organizar tareas, atender incidencias.

Construir empieza a tener sentido cuando la forma de operar es una parte importante del negocio y ninguna herramienta la recoge sin forzarla: cuando el equipo trabaja alrededor del programa en lugar de con él, cuando la información vive duplicada en varios sitios o cuando la parte que no encaja es justo la que os diferencia.

Entre comprar y construir hay más opciones de las que parece. Esta guía es para una empresa con un problema operativo concreto que debe decidir qué hacer con él; no trata de crear un producto SaaS para venderlo, sino de resolver un proceso interno.

Qué entendemos aquí por «SaaS del mercado»

Un SaaS (software como servicio) es un programa al que se accede por internet, normalmente pagando una suscripción, y que mantiene un tercero: el proveedor se ocupa de los servidores, las actualizaciones y la seguridad del producto.

Hay SaaS para casi cualquier proceso común: CRM, facturación, reservas, soporte, recursos humanos, proyectos, planificación, firma de documentos o automatización. El software a medida, en cambio, se desarrolla para la operación de una empresa concreta.

En inglés esta decisión se conoce como buy vs build: comprar o construir. Pero, como se verá, casi nunca es solo eso.

No son dos opciones: son al menos cinco caminos

Plantearlo como «herramienta del mercado o programarlo todo» deja fuera las soluciones intermedias. Hay al menos cinco caminos, de menos a más trabajo propio:

1. Usar el SaaS tal cual. Se contrata, se dan de alta los usuarios y el equipo trabaja como la herramienta propone. Funciona cuando el proceso es estándar o cuando adoptar la forma de trabajar de la herramienta es, de hecho, una mejora.
2. Configurar el SaaS. Se ajusta a fondo con lo que la propia herramienta permite: campos, estados, permisos, automatizaciones internas, plantillas e informes. Sigue siendo el mismo producto, pero adaptado. Antes de descartar una herramienta, conviene comprobar todo lo que permite configurar.
3. Integrar varios SaaS. Cada herramienta hace bien su parte —CRM, facturación, soporte, firma— y se conectan entre sí para que el dato entre una sola vez. La complejidad está en las conexiones y en decidir cuál manda sobre cada dato.
4. Mantener el SaaS y construir una capa propia. La herramienta del mercado sigue siendo el núcleo, y se desarrolla solo lo que no existe: un portal, una aplicación para un rol concreto, un motor de reglas, un cuadro de mando.
5. Construir software a medida. El proceso central vive en un sistema diseñado para vuestra operación, normalmente conectado con las herramientas estándar que siguen teniendo sentido (contabilidad, correo, pagos).

Antes de llegar al quinto, conviene descartar el segundo, el tercero y el cuarto. Y existe una sexta respuesta, que trataremos al final: todavía no hacer nada.

Lo que aporta un SaaS

• Puesta en marcha más rápida en muchos casos, y menor inversión inicial: se paga una cuota, no un proyecto.
• Mantenimiento, infraestructura y actualizaciones a cargo del proveedor.
• Producto probado por empresas con necesidades parecidas, a menudo con buenas prácticas incorporadas.
• Integraciones ya hechas, documentación y acompañamiento inicial.
• Posibilidad de probar antes de decidir.

No significa que sea siempre barato, fácil o rápido: una herramienta compleja mal implantada puede costar meses. Pero, para necesidades comunes, el punto de partida es muy favorable.

Lo que limita un SaaS

• Dependéis de su hoja de ruta: podéis pedir una función, pero no decidís si se hace ni cuándo.
• Hay límites funcionales que no se superan configurando, y cuanto más se fuerza la herramienta, más frágil se vuelve.
• El coste suele crecer con el uso: por usuario, módulo, volumen, almacenamiento o plan.
• La API tiene sus reglas: qué datos expone, cuántas llamadas admite y qué exige un plan superior.
• El modelo de datos, los permisos y los informes son los suyos. Lo que no encaja acaba en campos de notas o en hojas paralelas.
• Cambiar de proveedor cuesta. Es lo que en inglés se llama vendor lock-in: cuanto más proceso, datos e integraciones acumuláis en una herramienta, más caro y arriesgado es salir de ella, aunque ya no os convenga.

La normativa europea ayuda en parte. Desde el 12 de septiembre de 2025 es aplicable la Ley de Datos de la UE (Reglamento 2023/2854), que incluye expresamente los servicios SaaS: obliga a que el contrato recoja por escrito cómo cambiar de proveedor y llevarse los datos exportables, y establece que a partir del 12 de enero de 2027 no se podrá cobrar al cliente por el proceso de cambio. Tiene matices, y la propia Unión está negociando modificaciones, así que conviene revisar cada contrato. Lo que ninguna norma resuelve es el trabajo de migrar: integraciones, procesos y formación.

Lo que aporta el software a medida, y lo que exige

Un sistema propio puede:

• seguir vuestro proceso, con vuestras reglas, estados y excepciones;
• dar a cada rol la pantalla que necesita, incluido el cliente;
• integrarse a fondo con lo que ya tenéis, sin depender de lo que un tercero haya decidido exponer;
• automatizar lo específico y centralizar los datos con una estructura pensada para vuestro negocio;
• evolucionar según vuestras prioridades, no según el roadmap de un proveedor;
• ser vuestro, en la medida en que el contrato recoja la propiedad del código y de los datos.

Y exige:

• más inversión inicial y más plazo: análisis, diseño, desarrollo y pruebas antes de que nadie lo use;
• mantenimiento, seguridad, infraestructura y evolución continuos, porque nada se actualiza solo;
• un análisis serio, porque el error más caro no es técnico: es construir con precisión un proceso equivocado;
• arquitectura y documentación pensadas para que otro equipo pueda continuarlo; si no, la dependencia del fabricante se cambia por la dependencia de quien lo desarrolló.

Un sistema propio no da independencia total: necesita un equipo técnico, interno o externo, que lo conozca. Tampoco es la versión «premium» de una herramienta del mercado. Es otra respuesta, para otro tipo de problema.

Una tabla para situar el problema

Es orientativa: el producto concreto y el caso pueden cambiar cualquier fila.

Situación	SaaS	A medida
Necesidad común en muchas empresas	Mejor encaje	Peor encaje
Hay que arrancar pronto	Mejor encaje	Peor encaje
Poca inversión inicial	Mejor encaje	Peor encaje
Reglas y estados propios	Depende	Mejor encaje
Integraciones habituales	Mejor encaje	Depende
Integraciones críticas o poco comunes	Depende	Mejor encaje
Controlar cómo evoluciona	Peor encaje	Mejor encaje
Muchos usuarios a la vez	Depende	Depende
Mantenimiento sin equipo técnico	Mejor encaje	Peor encaje
Proceso que os diferencia	Depende	Mejor encaje

El número de usuarios no decide por sí solo: el precio por usuario de un SaaS crece con el equipo, pero un sistema propio también tiene costes que suben con el uso. Y el proceso que os diferencia no siempre exige desarrollo: a veces basta con configurar bien o con construir solo la parte propia.

La pregunta clave: ¿qué parte del proceso es realmente vuestra?

Es fácil sentir que la propia empresa trabaja de forma distinta. La pregunta útil no es si lo hacéis diferente, sino por qué:

• «Lo hacemos así porque siempre se ha hecho así.» Es una costumbre. Adaptarse a una herramienta puede ser una oportunidad para ordenar el proceso; construir para conservar la costumbre es pagar por mantener un problema.
• «Lo hacemos así porque ahí está nuestra ventaja.» Es parte del negocio. Si la herramienta obliga a renunciar a ello, o a hacerlo fuera del sistema, el coste es real aunque no aparezca en ninguna factura.

Algunos procesos rara vez son diferenciales: la facturación estándar, la gestión de vacaciones y ausencias, la firma de documentos o un CRM comercial básico. Hacerlos como los hace el mercado suele ser suficiente, y reinventarlos no aporta nada.

Otros pueden serlo: un motor de precios propio, un flujo sectorial con muchos pasos, la asignación de técnicos con reglas complejas, una logística especial, una planificación con muchas variables, reglas de aprobación propias o un modelo operativo que la competencia no tiene. No significa que siempre exijan desarrollo, sino que merecen un análisis antes de aceptar lo que trae la herramienta.

Una prueba práctica: si el cliente no notaría la diferencia y el margen no cambia, probablemente es costumbre. Si cambiarlo os haría perder clientes, rapidez o margen, probablemente es vuestro.

La zona gris: mantener el SaaS y construir lo que falta

No siempre hace falta reemplazar nada. A veces basta con que lo que ya funciona deje de tener huecos. Algunas combinaciones habituales:

• CRM del mercado + portal propio para que los clientes consulten el estado de sus pedidos o expedientes.
• ERP en la nube + aplicación operativa para técnicos, almacén o equipo de campo.
• SaaS de facturación + flujo interno de aprobaciones, presupuestos o validaciones previo a facturar.
• Tienda online + motor de precios propio que aplica las condiciones de cada cliente.
• Software de gestión + cuadro de mando que junta los datos de varias herramientas sin exportar a mano.
• Varias herramientas SaaS + automatizaciones que mueven el dato de una a otra y avisan cuando algo se atasca.

La herramienta sigue haciendo lo que hace bien y se construye solo la parte propia, conectada a ella: no se tira lo que funciona, se puede hacer por partes y el equipo conserva lo que ya conoce. Si el ERP es una de las piezas, en ERP a medida o ERP estándar explicamos cómo aplicar este mismo razonamiento al sistema de gestión.

Integraciones: la herramienta puede bastar y aun así fallar

Una herramienta puede cubrir todas las funciones que necesitáis y fallar igualmente porque no habla con el resto del negocio. Antes de contratarla, conviene revisar:

• API: qué datos permite leer y escribir, y en qué plan.
• Webhooks: si avisa a otros sistemas cuando algo cambia.
• Exportaciones: si los datos salen completos, en qué formato y de forma automatizable.
• Límites: cuántas llamadas, registros o automatizaciones admite cada plan.
• Conectores: si existen ya para vuestras herramientas y quién los mantiene.
• Sincronización: si es inmediata o periódica, y qué pasa si dos sistemas cambian el mismo dato.
• Propiedad del dato: qué sistema manda sobre clientes, precios, stock o estados.

Este último punto merece atención especial cuando conviven varias herramientas. En quién manda en el stock y en el precio entre la web y el ERP lo desarrollamos para el caso de una tienda online y un sistema de gestión.

Qué se paga en cada camino, a varios años

En un SaaS hay que mirar bastante más que la cuota de la web: el plan necesario para las funciones que de verdad usaréis, los usuarios de hoy y de dentro de unos años, módulos y complementos, volumen de registros, almacenamiento, nivel de soporte, integraciones y automatizaciones externas, implantación y migración inicial, y el coste de salida si algún día hay que cambiar. En un software a medida se paga análisis, diseño, desarrollo, pruebas, infraestructura, mantenimiento y evolución; los rangos orientativos del mercado español están en cuánto cuesta un software a medida.

Por ejemplo, una cuota de 20 € por usuario y mes no se compara directamente con un presupuesto de desarrollo de 50.000 €: una es recurrente y crece con la empresa; la otra es una inversión inicial a la que se suman mantenimiento y evolución. Para compararlas se usa el coste total de propiedad, lo que cuesta cada opción durante tres o cinco años. En los dos lados hay que sumar:

• licencias o infraestructura, y cómo crecen si se duplica el equipo o el volumen;
• implantación, personalización e integraciones, y su mantenimiento;
• las horas internas que dedicará el equipo;
• el trabajo manual que seguirá existiendo con cada opción, el coste que menos se ve y el que más dura;
• y el coste de cambiar de sistema más adelante.

Con pocos usuarios y un proceso estándar, el SaaS suele ganar con claridad. Con muchos usuarios, un proceso muy propio y mucho trabajo manual alrededor de la herramienta, la cuenta puede cambiar. Hay que hacerla con vuestros números, no con la cuota del primer mes.

Cuatro situaciones habituales

Son escenarios inventados para ilustrar el razonamiento; no son clientes de Bolmia.

Una empresa de servicios que necesita un CRM para oportunidades, tareas comerciales y un embudo sencillo. Es una necesidad común y bien cubierta: lo razonable es contratar un SaaS, configurarlo bien y dedicar el esfuerzo a que el equipo lo use.

Una empresa que ya usa un CRM del mercado y está contenta con él, pero necesita que sus clientes consulten el estado de sus servicios y que las solicitudes sigan un flujo de aprobación propio. Cambiar de CRM no resuelve nada. Lo sensato es mantenerlo y construir un portal y un flujo conectados a él.

Una empresa cuyo valor está en una operativa sectorial: muchos estados por expediente, varios roles en orden y reglas que cambian según el cliente. Hoy la sostienen dos herramientas, varias hojas de cálculo y mucho correo. Aquí sí tiene sentido estudiar software a medida para ese núcleo, conectado con lo estándar.

Una empresa que cambia su forma de trabajar cada pocas semanas porque todavía está encontrando su modelo. Ni comprar algo complejo ni construir: lo prudente es una herramienta sencilla y flexible durante un tiempo, hasta que el proceso se estabilice.

Señales de que conviene comprar

Cuantas más se cumplan, más probable es que una herramienta del mercado sea la mejor opción:

• La necesidad es la misma que tienen muchas empresas de vuestro tamaño o sector.
• Existen herramientas maduras que la cubren, con clientes parecidos a vosotros.
• El proceso no es lo que os diferencia.
• Los requisitos especiales son pocos y se pueden asumir.
• Las integraciones que necesitáis ya existen.
• Hay urgencia, el presupuesto es limitado o no hay quien mantenga un sistema propio.
• Todavía necesitáis probar qué funciona.

Señales de que conviene construir (o estudiarlo)

• El equipo usa varios atajos para hacer lo que la herramienta no permite.
• El mismo dato se introduce en varios sitios, o hay hojas de cálculo paralelas que sostienen parte del proceso.
• Los permisos o el flujo de trabajo que necesitáis no encajan en ninguna herramienta.
• Hay una integración crítica que nada resuelve bien, o automatizaciones muy propias del negocio.
• La lógica de negocio es compleja: reglas, cálculos o excepciones que cambian según el caso.
• Los informes que necesita la dirección son imposibles sin exportar y cruzar a mano.
• El coste de la herramienta crece con fuerza a medida que crece la empresa.
• El proceso propio es una fuente de ventaja.

Una sola señal no justifica un desarrollo. Varias a la vez, sobre todo en el proceso que da margen, justifican analizarlo con calma. Si muchas de estas señales se manifiestan en hojas de cálculo, en cuándo dejar Excel están desarrolladas una por una.

Señales de que todavía no conviene hacer nada

A veces la mejor decisión es no comprar ni construir, al menos por ahora:

• El proceso no está definido. Si nadie sabría explicar cómo debería funcionar, cualquier herramienta lo fijará mal.
• El problema no está claro. «Necesitamos un sistema» no es un problema; «tardamos tres días en confirmar un pedido» sí lo es.
• No hay volumen suficiente. Automatizar algo que pasa pocas veces al mes rara vez compensa.
• El problema es humano u organizativo. Si falta un responsable o cada persona trabaja a su manera, el software reproduce el desorden con mejor aspecto.
• Nadie va a liderar la adopción. Una herramienta que nadie usa no resuelve nada.
• Los requisitos cambian cada semana. Primero hay que dejar que el proceso se asiente.

El trabajo previo es organizativo: definir el proceso, nombrar a un responsable y medir el problema. Servirá después para elegir herramienta o para preparar los requisitos si hay que construir.

Una matriz rápida

Elige un SaaS si… la necesidad es común, la herramienta cubre lo esencial sin forzarla, las integraciones existen y el proceso no es lo que os diferencia.

Elige un camino híbrido si… la herramienta funciona en lo central, pero falta una pieza concreta con peso en la operación.

Estudia el software a medida si… el proceso es vuestro, da ventaja, ninguna combinación de herramientas lo cubre sin hojas paralelas y está lo bastante estable.

Espera si… el proceso aún no está definido, falta un responsable o el problema todavía no se puede describir con claridad.

Doce preguntas antes de decidir

1. ¿Existe una herramienta que cubra lo esencial del proceso?
2. ¿Qué falta exactamente, descrito como tareas concretas y no como sensaciones?
3. ¿Lo que falta es diferencial o es costumbre?
4. ¿Puede resolverse con configuración o con una integración?
5. ¿Cuántos atajos y hojas paralelas seguirían existiendo con la herramienta?
6. ¿Cuánto costaría el SaaS a tres años, con el crecimiento previsto?
7. ¿Cuánto costaría construir y mantener la alternativa en el mismo plazo?
8. ¿Qué pasa con cada opción si duplicamos usuarios o volumen?
9. ¿Necesitamos decidir nosotros cómo evoluciona la herramienta?
10. ¿El proceso es lo bastante estable como para fijarlo en un sistema?
11. ¿Hay una persona responsable dentro de la empresa que vaya a impulsar el cambio?
12. ¿Podríamos sacar nuestros datos completos si mañana quisiéramos cambiar?

Errores frecuentes al decidir

• Construir por orgullo. Querer «algo nuestro» no es un motivo; el proceso tiene que justificarlo.
• Elegir por la cuota mensual, la parte más visible del coste.
• Comprar por la lista de funciones, en lugar de comprobar cómo cubre vuestro proceso real.
• Personalizar el SaaS hasta romperlo: cada ajuste parece pequeño; juntos la vuelven frágil.
• Llevar a software un proceso mal diseñado: es pagar por automatizar un problema.
• No calcular el mantenimiento de lo que se construye o personaliza, ni cómo crece el coste por usuario.
• Decidir sin probar: si la herramienta ofrece una prueba, un piloto pequeño con casos reales enseña más que cualquier comparativa.

Cómo lo planteamos en Bolmia

En Bolmia no empezamos decidiendo qué hay que construir, sino comprobando si hace falta construir algo. Primero entendemos el proceso: quién interviene, qué datos se mueven, dónde están las excepciones y qué herramientas ya funcionan. Después decidimos con vosotros si conviene configurar lo que tenéis, integrar lo que necesita hablarse, construir solo la parte que falta o, cuando el proceso lo justifica, desarrollar un sistema propio.

A veces la herramienta que buscáis ya existe, y lo decimos. Cuando no, el desarrollo de software a medida que planteamos parte de conectar lo que ya funciona antes que reemplazarlo. Cuéntanos qué proceso os preocupa y vemos qué camino encaja.