Build vs Buy: la decisión tecnológica más cara de tu empresa
Una de las decisiones más importantes para cualquier negocio digital es si desarrollar una plataforma a medida o adoptar una solución SaaS. La respuesta incorrecta puede costar cientos de miles de euros en desarrollo innecesario o, al contrario, limitar tu crecimiento por depender de una herramienta que no se adapta a tu modelo de negocio.
Lo que hace difícil esta decisión no es la falta de información, es que casi siempre se toma con los datos equivocados. Se compara el presupuesto de un desarrollo contra el precio mensual de una licencia, cuando lo que hay que comparar es el coste total a cinco años de cada camino, incluido el coste de cambiar de opinión. Esta guía recoge los criterios que usamos en proyectos reales para decidir, el desglose de costes que suele quedar fuera de la hoja de cálculo y las señales que indican que te has equivocado de lado.
Un apunte previo: «a medida» y «SaaS» no son dos casillas, son los extremos de un espectro. Entre medias hay software libre autoalojado, plataformas configurables, frameworks verticales y arquitecturas híbridas. La mayoría de las decisiones acertadas que hemos visto no eligen un extremo, eligen un punto concreto de ese espectro para cada pieza del sistema.
Cuándo elegir SaaS
El SaaS es la opción correcta cuando tu necesidad es estándar y bien resuelta por el mercado. CRM (HubSpot, Salesforce), email marketing (Mailrelay, ActiveCampaign), contabilidad (Holded, Contasol), gestión de proyectos (Asana, Monday): estos son problemas resueltos. Desarrollar un CRM propio en 2026 solo tiene sentido si tu modelo de negocio requiere algo radicalmente diferente.
Ventajas del SaaS
Tiempo de implementación rápido, coste inicial bajo, mantenimiento incluido, actualizaciones automáticas, y soporte profesional. El TCO (Total Cost of Ownership) a 3 años suele ser menor que el desarrollo a medida para funcionalidades estándar.
La ventaja que casi nadie contabiliza: el coste de oportunidad
Mientras tu equipo construye un módulo de facturación, no está construyendo lo que te diferencia. En empresas pequeñas y medianas la capacidad de desarrollo es el recurso más escaso que existe, más que el dinero. Cada semana de desarrollo gastada en resolver un problema que ya tiene solución comercial es una semana que no se dedica al producto por el que te pagan. Este es, con diferencia, el argumento más fuerte a favor del SaaS y el que menos aparece en los comités.
Lo que ha cambiado en el modelo de precios
Durante 2026 el mercado ha acelerado el abandono del precio por usuario hacia modelos de consumo y de resultado, empujado por la llegada de funciones de IA cuyo coste marginal no es cero. Para el comprador esto tiene una consecuencia muy concreta: el presupuesto de SaaS deja de ser un coste fijo previsible y pasa a escalar con el uso. Si estás comparando alternativas a cinco años, ya no basta con multiplicar el precio por usuario por el número de empleados: hay que estimar volumen, y hay que releer la cláusula de revisión de precios del contrato.
Cuándo el SaaS deja de ser la opción barata
Hay un punto de cruce previsible en tres situaciones. La primera, cuando creces en usuarios: una herramienta a 40 € por usuario y mes es barata con 10 personas y muy cara con 200. La segunda, cuando necesitas tantos add-ons y conectores que el precio final triplica el de la lista. La tercera, cuando la adaptación al producto obliga a cambiar tu proceso de negocio de una forma que te resta competitividad. Ese tercer caso es el más peligroso porque no aparece en ninguna factura.
Cuándo desarrollar a medida
El desarrollo a medida tiene sentido cuando tu lógica de negocio es tu ventaja competitiva. Si tu plataforma ES tu producto (marketplace, configurador, herramienta vertical), si necesitas integraciones profundas entre múltiples sistemas que ningún SaaS resuelve bien, o si los datos y procesos son tan específicos que adaptarlos a un SaaS genérico cuesta más que desarrollarlos.
La zona gris
Muchos proyectos caen en una zona intermedia: 80% de funcionalidades estándar y 20% de lógica específica. Aquí la estrategia más inteligente suele ser adoptar un SaaS o framework como base y desarrollar a medida solo las piezas diferenciales, conectándolas vía APIs.
Cómo se monta bien un híbrido
La clave de un híbrido sano es que la frontera entre lo comprado y lo construido sea explícita y estable. En la práctica eso significa tres cosas: que la pieza propia hable con el producto comercial a través de su API pública y documentada (nunca tocando su base de datos), que exista una capa de traducción propia para que un cambio del proveedor no se propague por todo tu código, y que haya pruebas automáticas que detecten una rotura de contrato antes que un cliente. Es el mismo principio que aplicamos al conectar tiendas y sistemas de gestión en proyectos de integraciones entre ecommerce, ERP, logística y pagos.
Requisitos que obligan a construir aunque no quieras
Hay contextos donde la decisión viene dada desde fuera: requisitos de soberanía del dato, exigencias sectoriales de auditoría, obligaciones de desarrollo seguro bajo ISO 27001 o ENS, o los pliegos de una licitación pública que imponen condiciones que ningún producto de catálogo cumple. Antes de abrir el debate build vs buy conviene comprobar si estas restricciones ya lo han cerrado.
El TCO real a cinco años: qué se olvida en cada columna
El error de cálculo más común no es equivocarse en una cifra, es omitir una partida entera. Estas son las que faltan casi siempre en cada uno de los dos presupuestos.
Lo que falta en la columna SaaS
Implantación y consultoría inicial, integraciones con el resto de tus sistemas, formación, add-ons que descubres al tercer mes, incrementos de precio en cada renovación, coste de los usuarios que crecen con la plantilla y —la más olvidada— el coste de salida: exportar los datos en un formato usable, reconstruir los informes y migrar los procesos. Cuando ese coste de salida es alto, el proveedor lo sabe y su política de precios lo refleja.
Lo que falta en la columna a medida
Infraestructura, copias de seguridad y monitorización; actualizaciones de dependencias y parches de seguridad; el tiempo de dirección técnica; la evolución funcional que llegará sí o sí; y el riesgo de concentración de conocimiento en una o dos personas. Una plataforma propia sin plan de mantenimiento de software presupuestado no es un activo, es una deuda con fecha de vencimiento desconocida.
Cómo comparar sin engañarse
El método que funciona es simple: construir la tabla a cinco años con las mismas categorías de coste para las tres opciones —SaaS, a medida e híbrido—, escribir explícitamente los supuestos de crecimiento (usuarios, volumen, países) y, al final, añadir una fila que casi nadie pone: cuánto cuesta deshacer esta decisión en el año tres. Esa última fila es la que suele cambiar el resultado.
Lock-in y letra pequeña: qué ha cambiado con el Data Act europeo
Durante años, el argumento «si un día no nos gusta, nos cambiamos» era teórico: las comisiones de salida y las tarifas de extracción de datos hacían que cambiar de proveedor costase más que aguantar. El Reglamento de Datos europeo (Data Act) ha cambiado esa ecuación. Su capítulo de cambio de proveedor es aplicable desde el 12 de septiembre de 2025, sin periodo transitorio para los contratos ya firmados, y establece una retirada en dos fases de las comisiones de cambio: hasta el 12 de enero de 2027 el proveedor solo puede repercutir los costes en los que realmente incurra por el proceso de cambio y, a partir de esa fecha, no puede cobrar nada por ello, tarifas de salida de datos incluidas.
El reglamento va más allá del precio y fija condiciones contractuales mínimas: plazos de cambio acotados, preavisos máximos, listado completo de los datos exportables, asistencia durante la transición, ventana posterior para recuperar la información y calendario de borrado. Siguen siendo cobrables las cuotas ordinarias del servicio durante la transición, las penalizaciones por rescindir un contrato de duración determinada y el trabajo genuinamente adicional que se pacte por adelantado.
Para la decisión build vs buy esto tiene dos lecturas. La primera, que el riesgo de quedarse atrapado en un SaaS ha bajado, lo que refuerza la opción de comprar en todo lo que no te diferencia. La segunda, más práctica: al negociar una renovación conviene revisar si el contrato recoge ya estas obligaciones, porque muchos contratos heredados no lo hacen y siguen incluyendo cláusulas que hoy no son exigibles. Es una revisión que encaja de forma natural en una auditoría técnica del stack.
Ojo: el lock-in no desaparece con las comisiones. El bloqueo real rara vez es económico, es de modelo de datos y de proceso. Si llevas cuatro años adaptando tu operativa a las peculiaridades de una herramienta, el coste de salir no está en la factura de exportación, está en los meses de reaprendizaje. La defensa contra eso es documentar tus procesos con independencia del producto que los soporta.
Errores comunes
El error más frecuente es sobreestimar la especificidad de tus necesidades. Muchas empresas desarrollan plataformas a medida para resolver problemas que un SaaS configurado correctamente cubriría al 95%. El otro error es subestimar el coste de mantenimiento: una plataforma a medida necesita equipo técnico permanente para actualizaciones, seguridad y evolución.
Otros cuatro errores que se repiten
Decidir por precio de entrada. El primer año casi siempre gana el SaaS y casi siempre es irrelevante: la decisión se juega en los años tres, cuatro y cinco, cuando aparecen el crecimiento de usuarios, los add-ons y la evolución funcional.
Construir para un requisito que nadie ha validado. Es habitual descubrir que la funcionalidad «imprescindible» que descartó tres productos comerciales la usaba una persona, una vez al mes, y podía resolverse con una exportación. Antes de construir, conviene preguntar quién lo usa y con qué frecuencia.
Comprar un producto para luego reescribirlo por dentro. Adoptar una plataforma comercial y personalizarla hasta hacerla irreconocible es lo peor de los dos mundos: pagas licencia, pierdes las actualizaciones y mantienes código. Si vas a tocar el núcleo, plantéate seriamente si no estabas construyendo desde el principio.
No prever quién lo mantiene. Una plataforma a medida sin equipo asignado se degrada en dos años. Si no tienes ese equipo, hay salidas intermedias —un CTO externo que gobierne la arquitectura, o staff augmentation para cubrir picos— pero hay que presupuestarlas desde el principio, no cuando ya duele.
Cómo decidir: framework de evaluación
Evalúa estos criterios: ¿Tu ventaja competitiva depende del software? Si sí, desarrolla a medida. ¿Existe un SaaS que cubra el 90%+ de tus necesidades? Si sí, adopta SaaS. ¿Tienes equipo técnico para mantener una plataforma propia? Si no, cuidado con el desarrollo a medida. ¿Tu modelo de negocio cambiará frecuentemente? Si sí, la flexibilidad del desarrollo a medida puede ser clave.
Cinco preguntas más para afinar
¿Cuántos usuarios tendrá dentro de tres años? Es la variable que más mueve el TCO del SaaS y la que peor se estima. Haz el cálculo con el escenario optimista, no con el actual.
¿Qué pasa si el proveedor sube el precio un 30 % o discontinúa el producto? Si la respuesta es «no tendríamos alternativa», estás ante una dependencia crítica y hay que tratarla como tal, con plan B documentado.
¿Los datos son tuyos y exportables en un formato usable? No basta con que haya un botón de exportar. La pregunta es si lo exportado sirve para reconstruir el servicio en otro sitio.
¿Qué parte del proceso es realmente tuya? Dibuja el flujo completo y marca los pasos que un competidor no podría copiar. Esos son los candidatos a desarrollo propio; el resto, no.
¿Cuánto tardaríamos en revertir la decisión? Si la respuesta supera los seis meses, la decisión merece una semana más de análisis y probablemente una due diligence técnica de las alternativas.
Una forma sencilla de puntuarlo
Un método que funciona en comité: lista los requisitos, marca cada uno como imprescindible o deseable, y puntúa de 0 a 3 cómo lo cubre cada opción. Si un producto comercial cubre todos los imprescindibles, gana salvo que el coste a cinco años lo desmonte. Si falla un imprescindible que además es de los que te diferencian, ya tienes tu respuesta. Lo importante del ejercicio no es la puntuación final, es obligar al equipo a escribir qué es imprescindible antes de ver las demos.
Tres escenarios habituales y qué decidimos en cada uno
Startup que necesita salir al mercado en tres meses
Aquí la respuesta casi siempre es comprar todo lo que no sea el producto y construir solo el núcleo. Facturación, soporte, analítica y CRM, de catálogo; el motor que hace única a la empresa, propio. El error clásico en esta fase es construir el panel de administración perfecto antes de tener diez clientes. Lo tratamos con más detalle al hablar de cómo montar un MVP que pueda escalar después.
Pyme con procesos muy propios y un ERP que se le ha quedado corto
El reflejo es pedir «algo a medida que haga exactamente lo que hacemos ahora». Suele ser mala idea: se acaba pagando por replicar en código treinta años de excepciones que nadie recuerda por qué existen. El camino que mejor funciona es adoptar una base sólida —a menudo software libre autoalojado, tipo SuiteCRM o un ERP open source— y desarrollar encima solo lo diferencial, aprovechando el proyecto para limpiar procesos. Si vienes de un SaaS comercial, la migración de datos y procesos es la parte que hay que planificar con más cuidado.
Ecommerce que se plantea una plataforma propia
Salvo modelos de negocio muy atípicos, construir una tienda desde cero en 2026 rara vez compensa: el ecosistema de plataformas cubre catálogo, checkout, pagos, impuestos y cumplimiento con un nivel de madurez difícil de igualar. La decisión relevante no es build vs buy, es qué plataforma elegir y qué piezas —configurador, precios B2B, integración con producción— desarrollar encima.
Preguntas frecuentes
¿Cuánto cuesta desarrollar una plataforma a medida?
Depende tanto del alcance que cualquier cifra suelta engaña. Lo que sí se puede decir es qué la encarece: número de integraciones con sistemas externos, requisitos de cumplimiento, volumen de usuarios concurrentes y, sobre todo, la ambición del alcance inicial. La palanca más eficaz para controlar el coste es reducir el alcance de la primera versión, no negociar la tarifa por hora.
¿El desarrollo asistido por IA hace que salga a cuenta construir más cosas?
Ha bajado el coste de escribir código, pero el coste de un sistema no es escribirlo: es especificarlo, integrarlo, probarlo, operarlo y evolucionarlo durante años. La IA mueve algo la frontera a favor de construir, sobre todo en piezas pequeñas y bien acotadas, pero no convierte en buena idea reimplementar un ERP. Donde sí cambia el cálculo es en los conectores y utilidades internas que antes no se hacían por falta de tiempo.
¿Y el software libre autoalojado, dónde encaja?
En un punto intermedio muy útil: sin coste de licencia por usuario, con el código disponible para adaptarlo y sin la dependencia de un único proveedor, pero con la responsabilidad de operarlo, actualizarlo y asegurarlo. Es una buena opción cuando tienes —o contratas— capacidad técnica de mantenimiento, y mala cuando la organización espera que «funcione solo».
¿Puedo empezar con SaaS y migrar a medida más adelante?
Sí, y es una estrategia razonable siempre que se tomen dos precauciones desde el día uno: que los datos salgan en un formato completo y usable, y que la lógica de negocio importante no viva únicamente dentro de las automatizaciones del producto. Si tus reglas críticas están escritas solo en la interfaz de un SaaS, migrar significa redescubrirlas una a una.
¿Cómo sé que me equivoqué?
Las señales son bastante claras. Si compraste: tu equipo dedica horas a rellenar huecos con hojas de cálculo y exportaciones manuales. Si construiste: llevas dos años sin añadir nada nuevo porque todo el esfuerzo se va en mantener. En cualquiera de los dos casos, reconocerlo pronto es mucho más barato que sostener la decisión por coherencia.
🧭 ¿Build o buy? Ponemos números a tu decisión
En Keliam analizamos tus procesos, comparamos el TCO a cinco años de las alternativas reales y te decimos dónde comprar, dónde construir y dónde conviene un híbrido. Sin vender una respuesta decidida de antemano.
- Plataformas de negocio a medida — cuando construir es la respuesta correcta
- Auditoría Técnica — diagnóstico del stack actual y del coste de cambiar
- Mantenimiento de software — el equipo que sostiene lo que ya has construido
Conclusión
Build vs buy no es una decisión ideológica y rara vez es una decisión única: es un conjunto de decisiones, una por cada pieza del sistema, y la respuesta correcta casi siempre es mixta. Compra lo que no te diferencia, construye lo que sí, y diseña la frontera entre ambos con el mismo cuidado con el que diseñarías el producto.
Si tienes que quedarte con una sola regla, que sea esta: haz el cálculo a cinco años, con todas las partidas y con una fila para el coste de cambiar de opinión. Casi todas las decisiones tecnológicas caras que hemos visto corregir a posteriori se habrían evitado con esa tabla hecha a tiempo.
