En resumen
- El software estándar es el producto ya hecho, vendido a muchas empresas, normalmente por suscripción (SaaS). El software a medida se construye para el proceso, las reglas y las integraciones de una organización concreta.
- La regla de decisión más útil: compra lo que es común, construye lo que te diferencia. La nómina, el correo y la contabilidad son iguales en todas las empresas. Tu forma de atender, de fijar precios o de entregar puede no serlo.
- Compara por el coste total a cinco años, y no por el precio de entrada: licencias que crecen por usuario, personalizaciones, integraciones y trabajo manual por un lado, frente a desarrollo, mantenimiento y evolución por el otro.
- En la práctica, casi toda organización madura acaba en el modelo híbrido: herramientas del mercado para lo genérico, una capa propia para el núcleo del negocio e integraciones para que los datos circulen entre ambas.
- La IA ha abaratado la construcción, pero no ha cambiado la pregunta. Escribir código es ahora más rápido. Entender el problema, conseguir que la gente lo use y mantener el sistema vivo siguen siendo el trabajo de verdad.
Qué significa cada camino
El software estándar es el producto ya hecho, pensado para servir a muchas empresas a la vez. Hoy casi siempre llega como SaaS: una suscripción mensual, por usuario, a la que se accede desde el navegador. Los CRM, los ERP y las plataformas de atención al cliente, de correo y de gestión de proyectos son los ejemplos clásicos. Lo adoptas en días, pagas poco para empezar y heredas años de evolución del proveedor. A cambio, tu proceso se adapta al producto.
El software a medida, también llamado personalizado, se construye para una organización concreta: tus reglas, tus flujos, tus integraciones. Tarda semanas o meses en ponerse en marcha, exige una inversión inicial mayor y necesita mantenimiento continuo. A cambio, el producto se adapta a tu proceso, y la propiedad intelectual es tuya.
En inglés, la decisión se conoce como build vs. buy: construir o comprar. Planteada así, parece una elección binaria. Rara vez lo es.
La pregunta correcta: ¿dónde está tu ventaja?
Toda empresa tiene dos tipos de proceso.
Los procesos comunes son los que funcionan de forma parecida en cualquier organización: nóminas, contabilidad, correo, videollamadas, firma de documentos. Nadie elige a un proveedor porque sus nóminas sean distintas. Aquí, el mercado ya ha resuelto el problema mejor y más barato de lo que lo harías tú.
Los procesos que diferencian son aquellos por los que el cliente elige tu empresa y no a la competencia: la forma de atender, de preparar una propuesta, de fijar precios, de entregar, de rendir cuentas. Cuando esos procesos se meten a presión dentro de una herramienta genérica, la empresa se queda con la misma operación que todos los competidores que usan la misma herramienta.
Compra lo que es común. Construye lo que te diferencia.
Un ejemplo de cómo se ve esto en la práctica. Para Vértebra, agencia de marketing especializada en salud, el trabajo de Oliven Works se centró en el panel en el que cada cliente sigue presupuestos, aprobaciones, entregas y resultados en tiempo real. Es el tipo de pieza que las herramientas genéricas difícilmente ofrecen tal como trabaja cada empresa, y ahí la transparencia acabó convirtiéndose en un argumento comercial.
Comparativa directa: estándar y a medida
| Criterio | Software estándar | Software a medida |
|---|---|---|
| Tiempo para empezar | Días o semanas | Semanas o meses |
| Coste inicial | Bajo | Alto |
| Coste a lo largo del tiempo | Crece con usuarios, módulos y subidas de precio | Mantenimiento y evolución, más estable |
| Encaje con el proceso | La empresa se adapta al producto | El producto se adapta a la empresa |
| Diferenciación | Ninguna: la competencia tiene lo mismo | Alta, si se aplica al núcleo del negocio |
| Integraciones | Las que ofrece el proveedor | Las que necesita el negocio |
| Evolución | Al ritmo y en la dirección del proveedor | Al ritmo y en la dirección de la empresa |
| Dependencia | Del proveedor: precio, rumbo del producto, continuidad | De quien lo mantiene: exige documentación y buena ingeniería |
| Datos y propiedad | Datos en la plataforma del proveedor | Código y datos bajo control de la empresa |
| Riesgo principal | Pagar cada vez más por algo que encaja cada vez menos | Construir de más, o construir lo que no hacía falta |
Ocho criterios para decidir
1. Ventaja competitiva
¿El proceso forma parte del motivo por el que los clientes te eligen? Si es así, es candidato a construirse. Si no, cómpralo.
2. Encaje real
Prueba la herramienta del mercado con casos reales, también con los difíciles. Una regla práctica: si resuelve bien la gran mayoría de lo que necesitas, cómprala y adapta el resto del proceso. Si resuelve poco más de la mitad, pagarás la diferencia en hojas de cálculo paralelas, trabajo manual y personalizaciones frágiles.
3. Coste total a cinco años
Ponlo todo en la cuenta, en ambos lados, como mostramos en la siguiente sección. El precio de entrada engaña en los dos sentidos.
4. Integraciones
Los datos tienen que circular: de la web al CRM, de la propuesta al contrato, del contrato a la facturación y de todo ello al panel de la dirección. Comprueba si la herramienta se conecta con lo que ya usas, y a qué coste. Un producto excelente que se convierte en una isla crea trabajo en lugar de eliminarlo.
5. Velocidad de cambio
Si el proceso cambia a menudo, por regulación, por estrategia o por aprendizaje, depender del calendario de un proveedor puede salir caro. Si es estable, esa dependencia pesa poco.
6. Datos, seguridad y cumplimiento normativo
Dónde están los datos, quién tiene acceso, cómo salir llevándotelo todo si hace falta. En sectores regulados y con el RGPD de por medio, estas respuestas pueden decidir la cuestión por sí solas.
7. Capacidad de mantenerlo
El software propio es un compromiso de años. Sin un equipo interno o un socio estable que responda del mantenimiento, la seguridad y la evolución, el sistema envejece rápido. La documentación y las buenas prácticas de ingeniería son el seguro contra la dependencia de personas concretas.
8. Adopción
En los dos caminos, el sistema solo existe si se usa. Una herramienta del mercado mal implantada fracasa tanto como un sistema propio que nadie ha pedido. Quien lo va a usar tiene que participar en la elección o en el diseño, y estar preparado para el cambio.

El coste total a cinco años
La comparación honesta suma lo que cuesta de verdad cada camino a lo largo del tiempo.
| Software estándar | Software a medida | |
|---|---|---|
| Entrada | Implantación, migración de datos, formación | Descubrimiento, diseño, desarrollo, pruebas, implantación, formación |
| Recurrente | Licencias por usuario y por módulo, subidas anuales de precio | Alojamiento, mantenimiento, seguridad, evolución continua |
| Costes ocultos | Personalizaciones, conectores, hojas de cálculo y trabajo manual para lo que el producto no hace, planes superiores para desbloquear una función | Tiempo de la dirección en el proyecto, cambios de alcance, dependencia de quien conoce el código |
| Cómo crece la factura | Con el número de usuarios y con el éxito de la empresa | Con la ambición de las nuevas funcionalidades |
| Coste de salida | Migración, pérdida del histórico, volver a aprender | Bajo: el código y los datos ya son tuyos |
Hay dos efectos que suelen sorprender. El primero: las licencias por usuario crecen con la empresa, y lo que era barato con veinte personas pesa con doscientas. El segundo: el coste invisible del trabajo manual. Las horas que se van cada semana copiando datos de un sistema a otro no aparecen en ninguna factura, pero se pagan todos los meses.
El modelo híbrido: la respuesta más habitual
Las organizaciones maduras rara vez eligen un bando. Diseñan una arquitectura por capas.
Qué hacer con cada tipo de proceso. El área destacada es donde la inversión en software propio se amortiza.
Lo que une las capas son las integraciones. Es ahí donde está buena parte del valor: el contacto que entra por la web llega al CRM, la propuesta aceptada se convierte en contrato, el contrato en factura y todo aparece en el panel, sin que nadie introduzca nada dos veces. Esa cadena es también la base técnica de una operación de ingresos integrada (RevOps).
Lo que la inteligencia artificial ha cambiado en esta decisión
Ha cambiado el coste de uno de los platillos de la balanza. Con los asistentes de programación, escribir código es ahora bastante más rápido, y funcionalidades que antes no justificaban la inversión ahora pueden justificarla. Eso amplía el territorio de lo que merece la pena construir.
No ha cambiado el resto. El código siempre ha sido la parte más pequeña de un sistema. Entender el problema, diseñar la experiencia de quien lo usa, garantizar la seguridad, integrarlo con lo que ya existe, preparar a los equipos y mantenerlo todo en marcha siguen exigiendo gente con experiencia. La facilidad para generar código, de hecho, ha creado un riesgo nuevo: sistemas hechos deprisa, que nadie entiende por dentro y que nadie es capaz de mantener.
En el lado de la compra, la IA también ha llegado: los productos del mercado están incorporando asistentes y automatizaciones que cubren necesidades antes exclusivas de los proyectos a medida. Antes de construir, conviene revisar qué ha empezado a hacer tu herramienta actual. Y si el plan es construir algo con la IA en el centro, empieza por el diagnóstico de por qué fracasan los proyectos de IA.
Los errores más caros, en ambos lados
Construir lo que es común. Un sistema financiero propio, un CRM desde cero sin un motivo estratégico. Es una inversión alta para llegar, años después, adonde el mercado ya estaba.
Meter a presión lo que te diferencia en una herramienta genérica. El proceso que hacía que los clientes eligieran a la empresa pasa a ser el mismo que el de todos, sostenido por hojas de cálculo paralelas.
Decidir por el precio de entrada. La suscripción barata que se encarece con el crecimiento, o el proyecto propio aprobado sin presupuesto de mantenimiento.
Personalizar el software estándar hasta convertirlo en uno a medida. Tantas adaptaciones que cada actualización del proveedor rompe algo. Te quedas con lo peor de los dos mundos: el coste de uno y la rigidez del otro.
Construirlo todo de golpe. Los proyectos largos, sin entregas intermedias, descubren tarde que el problema era otro. Los ciclos cortos, con gente usándolo desde el principio, corrigen el rumbo mientras aún es barato.
Olvidarse de quién lo va a usar. La decisión se toma entre la dirección y el área de tecnología, y el equipo conoce el sistema el día del cambio.
Una hoja de ruta para decidir en cinco pasos
- MapearLos procesos implicados, tal como funcionan hoy
- ClasificarQué es común y qué te diferencia
- ProbarHerramientas del mercado con casos reales y difíciles
- CalcularCoste total a cinco años, de los dos caminos
- DecidirPor capas: comprar, integrar, construir o validar
La decisión no es única: se toma proceso a proceso.
- Mapea los procesos en cuestión tal como ocurren de verdad, hablando con quienes los llevan a cabo.
- Clasifica cada uno: ¿es común o te diferencia? Sé riguroso. La mayoría son comunes, y eso es una buena noticia.
- Prueba dos o tres herramientas del mercado con casos reales, incluidas las excepciones que hoy dan guerra.
- Calcula el coste total a cinco años de los caminos viables, con los costes ocultos incluidos.
- Decide por capas, y empieza por la pieza más pequeña que aporte valor. Una buena arquitectura permite cambiar una pieza sin tumbar las demás.
Preguntas frecuentes
¿Qué es el software estándar?
Es un software ya hecho, desarrollado para servir a muchas empresas con las mismas funcionalidades, que suele venderse como suscripción mensual por usuario (SaaS). Ejemplos: CRM, ERP, herramientas de correo, de atención al cliente y de gestión de proyectos. La ventaja es empezar rápido y con un coste inicial bajo. El límite es que el proceso de la empresa tiene que adaptarse al producto.
¿Cuándo merece la pena desarrollar software a medida?
Cuando el proceso en cuestión forma parte de la ventaja competitiva, cuando ninguna herramienta del mercado cubre las reglas del negocio sin parches, cuando las integraciones necesarias son demasiado específicas, cuando el coste de las licencias crece más rápido que los ingresos o cuando el propio software va a ser un producto que se ofrece a los clientes.
¿El software a medida siempre es más caro?
Al principio, casi siempre. A cinco años, no siempre. Las herramientas por suscripción cobran por usuario y por módulo, y la factura crece con la empresa. A eso se suman personalizaciones, integraciones y el trabajo manual para cubrir lo que el producto no hace. El software propio concentra el coste al principio y después exige mantenimiento y evolución, en general una fracción anual de la inversión inicial. La comparación justa es el coste total en el periodo.
¿Qué es el modelo híbrido en build vs. buy?
Es la combinación de los dos caminos: herramientas del mercado para los procesos genéricos, como finanzas, RR. HH. y comunicación, y desarrollo propio solo para el núcleo que diferencia el negocio, como un portal del cliente, un motor de precios o un flujo de atención específico. Las dos capas se conectan mediante integraciones, para que nadie tenga que introducir los mismos datos dos veces.
¿Las herramientas no-code y low-code sustituyen al software a medida?
Sustituyen una parte. Son excelentes para validar una idea, automatizar flujos internos y construir aplicaciones sencillas con rapidez. Los límites aparecen con la escala, las reglas complejas, los requisitos de seguridad, el rendimiento y la dependencia del proveedor de la plataforma. Un camino habitual es validar en low-code y reconstruir lo que ha demostrado valor cuando los límites empiezan a salir caros.
Con la IA generando código, ¿sigue teniendo sentido comprar software ya hecho?
Sí. La IA ha reducido el coste de escribir código, pero el código es la parte más pequeña de un sistema: entender el problema, diseñar la experiencia, garantizar la seguridad, integrar, preparar a las personas y mantenerlo todo funcionando siguen costando lo mismo. Para los procesos genéricos, un producto maduro sigue siendo imbatible. La IA amplía lo que merece la pena construir en el núcleo del negocio, pero no convierte todo en candidato a software propio.



