Por qué «custom o ya hecho» es la pregunta equivocada
Tienes una hoja de Excel para pedidos, un módulo de ERP que el equipo evita para la mitad de los pasos, o un SaaS que deja fuera justo la parte que más importa. En algún momento, alguien dice «hagamos un software propio». La pregunta que sigue está, casi siempre, mal planteada: software a medida o software ya hecho, como una única elección para todo el proceso.
De hecho, la decisión se toma pieza por pieza: qué parte del proceso es demasiado común como para merecer que se reinvente, y qué parte es específica de tu empresa, hasta el punto de que ningún paquete estándar la cubre. El artículo recorre los criterios que importan, muestra la variante híbrida que la mayoría de las empresas pasa por alto, y después una tabla de decisión y las señales de una oferta de desarrollo de software poco fiable.
El primer criterio: cuán estándar es el proceso y cuánto te diferencia
Una prueba sencilla de la ingeniería de software ayuda a decidir: si el proceso que quieres cambiar es algo que cualquier empresa de tu sector hace igual —contabilidad, onboarding, la emisión de una factura— compras una herramienta ya hecha y adaptas tu proceso a ella. Si el proceso es justamente el motivo por el que los clientes te eligen a ti, esa parte merece código escrito a propósito. Martin Fowler lo dice directamente: si el proceso forma parte de tu ventaja competitiva, construyes software a medida; si no, compras un paquete y te adaptas a él.
Contexto: a nivel de la UE, las herramientas ya hechas ya son la norma — el porcentaje de empresas con ERP varía del 41% en las empresas pequeñas hasta el 89% en las grandes, y el 53% de las empresas de la UE usa al menos un sistema ERP, CRM o BI, según Eurostat (2025). El núcleo estándar es casi siempre el punto de partida correcto; la pregunta útil es qué le falta, para ti.
El segundo criterio: qué debe hablar con qué
Pocas herramientas compradas «listas para usar» hablan de forma nativa con todo lo que ya tienes en la empresa. Un ERP como SAGA o SAP, un transportista con AWB diarios, el sistema RO e-Factura de ANAF — cada uno tiene un formato propio, y un SaaS genérico rara vez los cubre todos de fábrica, sobre todo para un flujo específico de una empresa rumana. La mayoría de las veces, esta fricción no se resuelve sustituyendo el núcleo, sino mediante aplicaciones web pequeñas, dedicadas, construidas exactamente para el puente entre sistemas.
Los plazos no son teóricos: la declaración B2B mediante RO e-Factura pasó a ser obligatoria desde el 1 de enero de 2024, y la facturación B2B a través del mismo sistema, desde el 1 de julio de 2024, según el Ministerio de Finanzas. Da igual si la facturación se queda en la herramienta comprada o termina en una pieza construida a medida, la integración con e-Factura no es opcional — es un requisito legal que se cumple de todas formas.
El tercer criterio: quién es el dueño del código, la infraestructura y los datos
Cuando compras una suscripción, tus datos suelen estar en el formato y en la infraestructura del proveedor. Mientras la relación va bien, no importa. Importa el día en que el proveedor cambia los precios, es comprado por otra empresa o cierra el producto — momento en el que negocias desde la posición de la empresa que no es dueña de nada de lo que ha construido.
De aquí también la trampa de la personalización agresiva de un paquete comprado. Thoughtworks advierte de que personalizar un software comprado trae los mismos riesgos que desarrollar desde cero —retrasos, costes imprevistos, competencias que no son parte de la actividad principal— pero sin la ventaja de ser, al final, dueño del código. Fowler recomienda lo contrario: en lugar de personalizar el núcleo comprado, construyes piezas separadas, conectadas mediante API, de las que eres dueño por completo — exactamente el principio detrás de la variante híbrida.
El cuarto criterio: el coste a tres años, no el precio de partida
Una suscripción parece barata el primer mes. En tres años, el coste crece con el número de usuarios, con el volumen de datos y, casi siempre, con las tarifas de exactamente las excepciones que necesitas — un módulo adicional, un plan superior, un add-on solo para tu flujo. Un build a medida cuesta más al principio y exige mantenimiento después, pero su curva es distinta: el esfuerzo grande está concentrado al principio, no se multiplica con cada usuario nuevo.
No existe un veredicto universal — ni «compra siempre», ni «construye siempre». Forrester lo describe como un péndulo: las empresas que van constantemente a un único extremo pierden control o velocidad, mientras que la combinación deliberada trae el resultado más estable. El time to value importa tanto como el precio — una herramienta comprada casi siempre se pone en marcha más rápido que un build desde cero, una razón más para no descartar el núcleo.
La variante que la mayoría de las empresas pasa por alto: el núcleo se queda, las piezas se construyen a medida
La discusión «custom o ya hecho» se estanca porque se plantea como una elección única, para todo el sistema. La variante híbrida — mantienes el núcleo estándar y construyes a medida solo las piezas que faltan — es la variante a la que llegan a menudo las empresas que analizan el coste a largo plazo, no solo el precio de partida. Las piezas construidas alrededor suelen ser tres: integraciones, paneles internos de administración y automatizaciones.
AutosWorld es un ejemplo concreto, todavía en fase de lanzamiento: una tienda online construida sobre WooCommerce, con la plataforma estándar intacta. Lo que se construye a medida es el panel de administración de detrás — dashboard, edición rápida de productos, campos propios para proveedor y margen, calculado automáticamente. Tras autenticarse, el equipo llega directamente a su panel, no a WordPress, para que la operación diaria del stock no dependa de alguien externo.
Tchibo GAME ON muestra la situación opuesta — el proceso realmente es el producto. La campaña exigía la carga de tickets fiscales desde el móvil, validación automática y reglas antifraude contra tickets duplicados. Ninguna herramienta ya hecha cubría esta combinación, así que la plataforma se construyó íntegramente a medida, por The Niche Society. La diferencia frente a AutosWorld no es de calidad, es de tipo de proceso.
La tabla de decisión: qué recomendamos, según la situación
Los criterios anteriores dan una respuesta distinta para cada empresa. La tabla reúne las situaciones frecuentes y la recomendación adecuada para cada una.
| Situación | Recomendación | Por qué |
|---|---|---|
| Proceso idéntico en cualquier empresa del sector | Compras la herramienta ya hecha | Nadie gana reinventando un proceso estandarizado |
| El equipo pierde tiempo copiando datos manualmente a otro sistema | Construyes una integración a medida sobre el núcleo | El problema está en la frontera entre sistemas, no en el núcleo |
| El proceso es el motivo por el que te eligen los clientes, no la competencia | Construyes software a medida para esa parte | Un paquete estándar te lleva al nivel del mercado |
| Necesitas un back-office sencillo sobre una plataforma estándar (ej. tienda online) | Mantienes el núcleo, añades un panel construido a medida | El núcleo se mantiene fácil de actualizar |
| Todavía no sabes qué proceso quieres automatizar | Empiezas con un discovery por escrito, no con un pedido de código | Un alcance equivocado cuesta más que un mes de análisis |
Cómo es un primer build serio — y qué buscas en una oferta
Un primer build serio no empieza con código, sino con un discovery breve que termina en un documento: qué se construye, qué no, cómo son las integraciones y quién hace qué. El primer lanzamiento es pequeño, deliberadamente — un único flujo, de principio a fin. El código y la infraestructura están, desde el primer día, en la cuenta de la empresa cliente.
El mantenimiento no se detiene en el lanzamiento: las dependencias envejecen, las integraciones se pueden romper cuando cambia el ERP o la especificación de e-Factura, y los parches de seguridad no son opcionales. Un software «olvidado» durante dos o tres años se convierte, en silencio, en un riesgo — el presupuesto de mantenimiento merece discutirse desde la primera oferta.
- 01Precio fijo antes de cualquier discovery el esfuerzo se adivinó, no se vio
- 02Alcance solo en conversaciones verbales, no por escrito los malentendidos no salen a la luz hasta la entrega
- 03El código se queda en la cuenta del proveedor sin acceso, quedas atado a él por tiempo indefinido
- 04Lanzamiento único, con todo de golpe los problemas salen a la luz demasiado tarde
- 05Ninguna conversación sobre qué pasa después del lanzamiento el primer problema se convierte en urgencia, no en tarea planificada
Fuentes y lecturas.
Preguntas frecuentes
¿Cuándo merece la pena construir software a medida en lugar de comprar una herramienta ya hecha?
Cuando el proceso es el motivo por el que los clientes te eligen a ti, no a un competidor, o cuando ninguna combinación de herramientas del mercado cubre el flujo exacto que necesitas. Para todo lo que es común en tu sector, normalmente es más barato comprar y adaptar tu proceso.
¿Qué significa la variante híbrida y por qué la pasan por alto la mayoría de las empresas?
Mantener la herramienta estándar que ya usas y construir a medida solo las piezas que faltan — integraciones, paneles internos, automatizaciones. Se pasa por alto a menudo porque la conversación empieza como una elección única entre «todo comprado» y «todo construido», cuando la decisión se toma por separado, pieza a pieza.
¿Cómo reconozco una oferta seria de desarrollo de software a medida?
Empieza con un discovery y un alcance por escrito, no con un precio fijo dado en la primera conversación. Propón un primer lanzamiento pequeño, no un «big bang» con todo lo que se imaginó alguna vez, y deja el código en la cuenta de tu empresa desde el primer día.
¿Quién debería ser dueño del código y la infraestructura en un proyecto de software a medida?
La empresa cliente, no la agencia que construye. El código está en la cuenta de tu organización, la infraestructura en tu cuenta de cloud, aunque la agencia la administre a diario. Así puedes cambiar de proveedor cuando quieras, sin perder lo que has construido.
Veamos qué se puede automatizar en tu empresa.
Una sesión gratuita de 30 minutos: te decimos qué se puede automatizar, cuánto se tarda y cuánto cuesta, con precio fijo tras el discovery.