Software a medida o estándar: cómo elegir

Las tres preguntas que deciden la respuesta

La discusión sobre software a medida o estándar suele empezar por el precio, y el precio es justo lo último que hay que mirar: no puedes comparar dos opciones hasta que sabes cuál de las dos resuelve tu problema. Hay tres preguntas que ordenan la decisión mucho mejor que cualquier presupuesto. La primera es incómoda: tu forma de trabajar, ¿es una ventaja competitiva o solo una costumbre? Casi todo el mundo cree que su proceso es especial, y muchas veces es simplemente el proceso que montó alguien hace años y que nadie ha vuelto a revisar. Si cambiando el orden de dos pasos podrías usar una herramienta del mercado, no tienes un proceso propio: tienes una inercia, y las inercias no se pagan a precio de desarrollo. La segunda: ¿cuánta gente lo va a usar y con qué frecuencia? Una herramienta que usan dos personas media hora al día y otra que usa un equipo entero a jornada completa no se deciden igual. La tercera: ¿qué pasa dentro de cinco años? Cuántos seréis, qué otros sistemas tendréis que conectar y, sobre todo, quién va a mantener lo que decidas hoy. Cuando planteamos un proyecto de software a medida para empresas, esa tercera pregunta es la que más tiempo lleva contestar y la que más disgustos evita después.

Cuándo una herramienta estándar es la respuesta correcta

Para procesos que hacen igual todas las empresas del mundo (correo, firma de documentos, contabilidad, un CRM sencillo, gestión de proyectos, control horario) el mercado ya tiene productos maduros y no hay ninguna gloria en reinventarlos. Los pagas por uso, se actualizan solos, tienen soporte, hay gente en el mercado laboral que ya sabe usarlos y, si no te convencen, te das de baja. Ese último punto es el más infravalorado de todos: una suscripción se cancela, un desarrollo ya pagado no se devuelve. Elegir estándar es la opción reversible, y la reversibilidad vale mucho cuando todavía no tienes claro cómo va a funcionar tu negocio dentro de dos años. Antes de decidir conviene echar cuentas del coste recurrente, porque cambia la ecuación entera: lo que parece barato el primer mes se convierte en una nómina pequeña cuando lo multiplicas por usuarios y por años. La regla práctica es sencilla: si tu proceso es idéntico al de cualquier otra empresa de tu sector, adapta el proceso a la herramienta y no al revés, aunque las primeras semanas te chirríe. La resistencia interna a cambiar una costumbre suele disfrazarse de requisito técnico.

Cuándo compensa construir algo propio

Construir compensa cuando la forma en que gestionas la información es parte de lo que te hace ganar el trabajo, no un trámite. Un taller que ha montado su propio sistema de peritaje, una empresa de servicios con un modelo de rutas que ningún ERP contempla, un negocio con obligaciones de trazabilidad que ninguna herramienta genérica cubre sin encadenar módulos de pago: ahí el software propio deja de ser un capricho. El otro caso claro es el de la suma. Cuando pagas varias suscripciones que hacen media cosa cada una, no se hablan entre sí y obligan a alguien a copiar datos de una a otra, ya estás pagando un software a medida; solo que lo estás pagando en horas de tu equipo en vez de en desarrollo, y encima sin quedarte con nada. Un detalle que vale por todo el análisis: si tu equipo mantiene un Excel paralelo para arreglar lo que el programa no hace, ese Excel es la especificación de tu software. Ahí está escrito, gratis, lo que de verdad necesitas.

• El proceso que te distingue no cabe en ninguna herramienta sin retorcerla, y retorcerla ya cuesta horas cada semana
• Pagas varias suscripciones que hacen media cosa cada una y no se comunican entre ellas
• Alguien de tu equipo mantiene un Excel paralelo para tapar lo que el programa no hace
• Necesitas que un dato se introduzca una sola vez y llegue solo a presupuesto, almacén y factura
• Tienes obligaciones de trazabilidad o auditoría que solo se cubren encadenando módulos de pago
• El proveedor sube la cuota en cada renovación y no tienes ninguna palanca para negociar

Los costes ocultos que no salen en el presupuesto

Las dos opciones tienen facturas que no aparecen en el presupuesto. En el lado estándar: licencias por usuario que crecen cada vez que contratas a alguien, funciones que resultan estar en el plan superior, módulos de pago para lo que dabas por incluido, y sobre todo los datos, que viven en casa del proveedor. Mientras todo va bien no lo notas; lo notas el día que quieres irte, cambian las condiciones, suben el precio o los compra otra empresa y el producto cambia de rumbo. También cuenta el coste invisible de adaptar a tu equipo al software en lugar de al revés: es real, se paga en horas, y nadie lo apunta. En el lado del desarrollo propio los costes ocultos son otros dos. El mantenimiento, que no es opcional: un programa no se termina, se cuida, y las actualizaciones de seguridad y de dependencias hay que hacerlas aunque no aporten ninguna función nueva. Y la dependencia de quien lo programó, que es el riesgo serio. Si el código no está documentado, si el repositorio está en la cuenta del proveedor y no en la tuya, si nadie más entiende cómo funciona, no tienes un activo: tienes un rehén. Esa dependencia no se arregla con tecnología, se arregla con contrato.

La opción intermedia: conectar lo que ya tienes

La decisión no es binaria, y la tercera vía se descarta demasiado pronto. Muchas veces no necesitas construir un sistema: necesitas que los que ya usas dejen de estar incomunicados. El formulario de la web que crea la ficha en el CRM, el presupuesto aceptado que genera la factura, el cobro que actualiza la contabilidad sin que nadie teclee nada. Es lo mismo que contamos en cómo automatizar la facturación en una pyme: conservas herramientas que tu equipo ya sabe usar, el cambio es reversible y no hay que formar a nadie de cero. Tiene dos límites que conviene conocer antes de enamorarse de la idea. El primero es que dependes de las conexiones de terceros: si el proveedor cambia su versión o retira un punto de conexión, el puente se rompe y alguien tiene que arreglarlo ese mismo día. El segundo es de tamaño. Cuando las conexiones empiezan a acumular reglas, excepciones y condiciones, ya estás construyendo software, solo que sin diseño, sin documentación y repartido entre varias cuentas distintas. La señal para dar el salto es esa: cuando el pegamento pesa más que las piezas que une, toca sentarse a diseñar de verdad.

Quién lo mantiene dentro de cinco años y qué exigir por contrato

Todo software envejece, y la diferencia real entre las dos opciones es quién se encarga de ese envejecimiento. Con una herramienta estándar se encarga el proveedor y tú no decides cuándo: te actualiza la interfaz un martes y tu equipo se entera al abrirla. Con desarrollo propio decides tú, y por eso mismo tienes que pagarlo. El ejemplo más claro está en la seguridad: las librerías criptográficas que usa cualquier programa tienen fecha de caducidad y toca renovarlas. Con un producto estándar eso lo hace el fabricante; con software propio, si nadie está pendiente, no lo hace nadie. La conclusión práctica es que el contrato importa tanto como la tecnología, y cambia según la opción. Si encargas desarrollo, pon por escrito que el código fuente es tuyo, que el repositorio y los servidores están a tu nombre, que se entrega documentado y en qué condiciones puede continuarlo otro equipo. Si contratas una herramienta del mercado, exige poder exportar todo tú mismo, cuando quieras y en formato estándar. La ley te ayuda: el Reglamento de Datos europeo se aplica desde el 12 de septiembre de 2025 y, a partir del 12 de enero de 2027, los proveedores no podrán cobrarte por cambiar de servicio ni por sacar tus datos. Y si el proveedor trata datos de tus clientes, el artículo 28 del RGPD obliga a formalizar esa relación en un contrato.