- La pregunta es qué parte de tu operación te diferencia de verdad, antes que a medida o de mercado. Esa parte se construye; el resto se compra.
- Compara a cinco años y con todo dentro: licencias, implantación, horas internas y el coste invisible de las excepciones frente a desarrollo, mantenimiento e infraestructura.
- El 20% que la herramienta no cubre se paga cada semana en hojas de cálculo paralelas y copiar y pegar. No aparece en ninguna factura, y suele decidir la comparación.
- La respuesta habitual en una pyme es mixta: estándar donde no te diferencias, a medida en la pieza que sí, conectadas por integraciones.
- Comprar tampoco es la opción sin sorpresas: más de una cuarta parte de las implantaciones se pasó de presupuesto y casi una cuarta parte de plazo, según el informe ERP 2026 de Panorama Consulting Group.
Si ya has decidido construir y lo que quieres son cifras, el artículo de precios es Cuánto cuesta un software a medida en España en 2026. Para el detalle del servicio, aplicaciones y software a medida.
El error de plantearlo como una guerra
En casi todas las llamadas donde aparece esta pregunta, viene formulada como un bando: "estamos decidiendo si comprar algo o hacerlo a medida". Y casi nunca es una decisión única. Es una decisión por proceso.
Una empresa de treinta personas tiene contabilidad, nóminas, correo, gestión de clientes, planificación de producción, control de calidad, atención posventa. Comprar todo lleva a una operación llena de apaños entre herramientas que no se hablan. Construir todo es un proyecto que ninguna pyme debería querer. Lo sensato es separar: dónde eres igual que tu competencia y dónde no.
En lo que eres igual (declarar impuestos, pagar nóminas, enviar correos) no hay ninguna ventaja en construir. Compra lo estándar, cuanto más aburrido mejor. En lo que eres distinto, que suele ser una sola cosa y a veces dos, la herramienta estándar te obliga a parecerte a los demás. Ahí es donde el desarrollo a medida devuelve algo más que ahorro.
Comprar, adaptar, integrar o construir
Decide por proceso antes de elegir tecnología. Esta tabla ayuda a distinguir cuatro encargos que pueden parecer iguales en la primera llamada:
| Situación | Opción que conviene estudiar | Qué comprobar antes de contratar |
|---|---|---|
| Una herramienta cubre el trabajo y sus excepciones | Comprar | Licencias, exportación de datos y configuración |
| La herramienta encaja, pero faltan campos o reglas disponibles en sus módulos | Adaptar | Qué cambios admite y quién los mantiene |
| El equipo copia información entre programas que ya funcionan | Integrar | Conexiones disponibles, datos que se mueven y tratamiento de errores |
| Hay un proceso propio que exige permisos, estados o pantallas que no existen | Construir una pieza | Alcance, responsable interno, pruebas y mantenimiento |
Ejemplo hipotético: una empresa ya factura con su programa habitual, pero recibe partes por correo y los copia a mano. Puede necesitar una conexión o una herramienta de partes, sin sustituir su contabilidad. En una empresa de reformas, ese hueco entre el parte de obra y la factura es el que cubre un software de gestión para obras y reformas, que lleva el coste de cada obra y se conecta al programa de facturación.
Una lista de funciones no basta para elegir. Pide que te expliquen cómo resolvería cada opción una excepción real de vuestro trabajo y qué quedaría todavía a mano.
Si las herramientas que estás comparando son Odoo y Holded, sus precios de lista, la implantación y lo que exige cada API están en Odoo, Holded o software de gestión a medida.
Tres señales para revisar tu software actual
La hoja de cálculo paralela. Casi todas las empresas que acaban en un proyecto a medida tienen un fichero compartido que nadie planificó y del que ahora depende media operación. Es el síntoma más fiable: significa que la herramienta oficial no cubre el proceso real y que alguien ha construido el parche a mano.
El trabajo de traslado. Personas que dedican horas a mover información de un sistema a otro, comprobar que cuadra y volver a teclear lo mismo en otro sitio. Si sumas esas horas al mes y las multiplicas por el coste hora cargado, tienes el primer número honesto de la comparación.
La cuota que ya no encaja. Las herramientas por usuario tienen sentido cuando eres pequeño y dejan de tenerlo a partir de cierto tamaño o cuando necesitas dar acceso a mucha gente que apenas la usa. Cuando la factura anual de licencias empieza a acercarse a lo que costaría construir la parte que de verdad usas, toca hacer el cálculo.
Cómo comparar de verdad: los dos totales a cinco años
Nadie compara bien porque se compara la cuota mensual con el precio del proyecto, y son cosas distintas. Esta es la lista mínima de cada lado.
| Comprar | Construir |
|---|---|
| Licencias por usuario y por año | Coste de desarrollo (una vez) |
| Módulos o funciones adicionales | Evolución y mantenimiento anual según cobertura |
| Implantación y configuración inicial | Infraestructura y servicios de terceros |
| Horas internas de administración | Horas internas de definición y pruebas |
| Coste de las excepciones no cubiertas | Coste de oportunidad hasta la primera versión |
| Riesgo de subida de precio | Riesgo de dependencia del proveedor técnico |
La fila que decide la comparación casi siempre es la quinta de la izquierda, y es la única que no aparece en ningún presupuesto. Ponle horas. Si tres personas dedican cuatro horas semanales a tapar lo que la herramienta no hace, eso son más de 600 horas al año.
Comprar también se sale de presupuesto: el dato
La comparación suele hacerse dando por hecho que comprar es la opción previsible y construir la arriesgada. El informe ERP 2026 de Panorama Consulting Group, con 170 organizaciones encuestadas entre enero de 2025 y enero de 2026, apunta a otro sitio: más de una cuarta parte de las implantaciones se pasó de presupuesto y casi una cuarta parte se pasó de plazo. El motivo más repetido de los sobrecostes fue la necesidad imprevista de tecnología adicional, o sea, comprar más piezas para tapar lo que el producto elegido no cubría.
Dos matices sobre ese dato antes de usarlo. La muestra son empresas grandes, con una facturación mediana de 200 millones de dólares y un plazo mediano de proyecto de nueve meses, así que las magnitudes no son las de una pyme española. Y quien publica el informe vende consultoría de selección de ERP, con lo que le conviene que el problema se vea grande. La dirección del hallazgo coincide con lo que se ve en las llamadas: la cuota se cierra al firmar y el coste total sigue moviéndose después.
La dependencia del proveedor técnico se cierra por contrato
La otra fila incómoda de la tabla es la última de la derecha. Construir a medida crea dependencia técnica, y se mitiga con contrato: código y accesos a tu nombre desde el primer día, documentación técnica y manual de operación escritos para tu equipo, y pruebas automáticas para que otro proveedor pueda tomar el relevo sin romper nada. El contrato ayuda a reducir esa dependencia, aunque el relevo seguirá necesitando tiempo y conocimiento del sistema.
El patrón que funciona en una pyme
Casi ningún proyecto sensato sustituye todo el software de una empresa. El patrón que funciona es más modesto: dejas en su sitio lo estándar, construyes solo la pieza que te diferencia y las conectas.
Esa conexión, muchas veces, se resuelve con una automatización que mueve datos entre sistemas, valida y avisa cuando algo no cuadra. Cuesta una fracción de una aplicación completa y elimina buena parte del trabajo de traslado. Es lo que cubrimos como IA y automatizaciones, y conviene descartarlo antes de plantear un desarrollo entero.
Cuando la pieza propia sí hace falta, el orden importa: primero se acota (qué hace, para quién, contra qué se conecta), después se presupuesta. Por eso nuestro diagnóstico técnico previo es una fase con precio propio, descontable si contratas el proyecto: sin esa definición, cualquier cifra es una apuesta.
Cuándo la respuesta correcta es no construir nada
Vale la pena decirlo porque nos ha tocado decirlo: si el problema es de proceso, el software no lo arregla. Automatizar un proceso desordenado solo consigue que los errores lleguen antes y en mayor volumen.
La prueba rápida es la de la persona extra. Si contratando a alguien más el problema desaparece, tienes un problema de capacidad. Si contratando a alguien más el mismo desorden se reproduce con más gente dentro, tienes un problema de proceso, y ahí primero se ordena y después se construye.
Y si existe una herramienta que cubre el 80% y ese 20% restante es una costumbre interna y no una ventaja, la decisión honesta es cambiar la costumbre.
Nosotros lo hemos hecho por los dos lados
Construimos software para clientes y también productos propios, y eso nos ha obligado a tomar esta decisión con nuestro propio dinero. Cuibo, un marketplace de cuidadores verificados con más de 1.000 usuarios, y SandiApp, un SaaS para logopedas, terapeutas y educadores con más de 4.000, existen porque no había nada en el mercado que hiciera lo que hacen. En todo lo demás usamos herramientas estándar como cualquiera. Para empresas de la región, la decisión se toma sentados con el equipo: así trabajamos el desarrollo de software en Cantabria desde Torrelavega.
Ese es exactamente el criterio que aplicamos cuando alguien nos pregunta si debería construir: si lo que necesita ya existe, se lo decimos.
Qué te llevas del diagnóstico técnico
En Ignira separamos la llamada de encaje del diagnóstico de software. La primera sirve para entender el problema y comprobar si podemos ayudar. El diagnóstico posterior es un trabajo de pago, con alcance acordado, y su coste se descuenta si contratas el desarrollo.
El documento recoge el proceso actual, sus excepciones, los sistemas que hay que conectar y qué proponemos construir. Incluye el orden de trabajo y un presupuesto cerrado. Te lo quedas aunque decidas continuar con otro proveedor.
El servicio de software de gestión a medida explica esa fase y las condiciones de propiedad. Para comparar cifras con alcances distintos, consulta también cuánto cuesta un software a medida.
Lleva un proceso concreto a la primera conversación
Prepara el nombre del programa que usáis, un ejemplo del trabajo que hacéis por fuera y quién lo realiza. Anota qué pasa cuando falta un dato o llega un pedido distinto de lo habitual.
Con esa descripción se puede discutir una decisión concreta: configurar mejor lo que existe, conectarlo o desarrollar la pieza que falta. El objetivo de la llamada es comprobar el encaje antes de encargar el análisis.