Producto estándar o software a medida: cuándo elegir cada uno

Usted compra un CRM porque el responsable de ventas ya no da abasto con las notas y, al cabo de tres meses, al lado del sistema hay un Excel con tres listas de precios y una carpeta de facturas que alguien copia a contabilidad. El producto no es peor de lo que se vendió, porque conoce al cliente, la operación y la siguiente llamada, pero no conoce su proceso, porque ese proceso no era el que el fabricante construyó para cientos de empresas, y ese hueco es el tema de todo este artículo: si usted compra una herramienta para su proceso o un proceso para su herramienta, y no un hueco en la lista de funciones que se cierra con un solo ajuste. Si el hueco es una conexión entre sistemas que ya hacen su trabajo, eso no es un argumento para construir: primero conectamos lo que ya existe.

Producto estándar o software a medida: cuándo elegir cada uno no es una pregunta sobre qué botón parece más moderno, ni sobre si usted «es lo bastante grande para construir por su cuenta». Nuestra respuesta es la misma que hemos escrito en la página del servicio: si su proceso encaja en una herramienta estándar, tome la herramienta estándar, saldrá más barato, y un sistema a medida se justifica cuando el proceso forma parte de su ventaja competitiva o las soluciones estándar exigen demasiadas concesiones, y esta frase no es un truco de venta para acabar vendiéndole de todos modos una construcción, sino la prueba con la que perdemos las filas en las que habría que escribir otro CRM y nos quedamos con aquellas en las que el proceso es parte de la competitividad o las herramientas estándar exigen demasiadas concesiones.

Este artículo no es una comparación de plataformas de tienda online, porque esa ya la hemos escrito en otro sitio, y tampoco es una tarifa de software a medida, porque un artículo así no lo tenemos ni lo tendremos, ya que no nos inventamos los precios, y tampoco es la promesa de que un sistema propio gana siempre. Vendemos tanto la implantación de un producto estándar como la construcción desde cero, y un texto honesto empieza por esto: a veces el servicio más caro que podemos venderle es el que usted no necesita, así que más abajo está el límite con el que se puede tomar esta decisión antes de que alguien le venda un sprint.

Producto estándar o software a medida: cuándo elegir cada uno

Tome el producto estándar si el proceso encaja en él, y encargue software si el proceso es su competitividad o las herramientas estándar exigen demasiadas concesiones: esa es toda la respuesta, y el resto de este artículo es cómo comprobar esa frase contra un trabajo concreto, no contra una presentación. La comparación que arranca con una tabla de funciones termina antes de empezar, porque la tabla muestra lo que el fabricante ha nombrado, no quién decidirá dentro de un año su próximo cambio.

Las consecuencias del lado equivocado no son simétricas, porque la herramienta estándar en la que usted ha metido su proceso a la fuerza se convierte en una suscripción más un Excel más una persona que mantiene juntos los dos, y esa persona, al cabo de un año, es más cara que cualquier licencia, pero un sistema a medida para un proceso que ya vive en la contabilidad, en el correo y en un CRM estándar es una construcción que usted mantendrá solo, aunque en el mercado ya la mantiene otro. En el primer caso ha comprado un producto y después ha escrito un segundo sistema a su lado; en el segundo ha escrito un sistema donde bastaba una licencia, y los dos errores cuestan más tiempo del que parece en la oferta.

Nombramos este límite porque hemos visto los dos extremos en una misma semana: una empresa que quería «su HubSpot» cuando lo que necesitaba era HubSpot, y una empresa que durante tres años retorció un ERP estándar alrededor de su tabla de precios y al final vino a pedir esa misma tabla como un proyecto nuevo, no porque «el ERP no sepa», sino porque las concesiones ya eran más que la configuración. Ninguno de esos estados es fruto de mala fe, porque los dos empiezan con la frase «necesitamos un sistema», que todavía no es una prueba, y la prueba empieza solo cuando usted escribe el proceso en una sola página, sin el nombre de ninguna herramienta, y después busca qué herramienta ya hace esa página.

Antes de comprar, escriba qué tiene que hacer el sistema el primer día, qué no puede olvidar el segundo año y quién puede cambiar ese segundo año sin un lanzamiento ajeno, porque si las respuestas caben en un producto que se puede configurar, tome el producto. Si la pregunta es el catálogo, los precios, el pedido y la entrega en una tienda online, esa es la prueba de la tienda y no la reescribimos; si las respuestas son un proceso que el competidor no puede comprar como herramienta estándar, solo entonces tiene sentido hablar de un sprint. Este artículo, a partir de aquí, vende ese orden, no una herramienta.

Qué es un producto estándar y qué es el software a medida

Un producto estándar es software que alguien ya ha escrito para muchos y que usted adquiere o contrata por suscripción para usarlo sin una reconstrucción sustancial. La Ley 40/2015 del Régimen Jurídico del Sector Público pide consultar, antes de adquirir o desarrollar una aplicación, si el Directorio de aplicaciones ya tiene una solución reutilizable. COTS lo tomamos aquí como software comercial listo que se puede adquirir y usar sin una adaptación sustancial, y SaaS como una aplicación disponible en internet como servicio de suscripción. Son definiciones para la planificación, no una obligación de una empresa privada, y aquí las tomamos como palabras que ya están nombradas, no como una ley que le imponga a usted un visto bueno de la Administración.

El software a medida es un sistema que se escribe para su proceso, y en esas mismas directrices el software especializado es software desarrollado de forma individual para las necesidades de un organismo o de un sector concretos. También lo llamamos sistema a medida, en la página del servicio sistema no estándar y en el título software a medida, y no son tres productos, sino un solo trabajo: código que parte de su proceso, no de la hipótesis del fabricante sobre qué es un cliente, un pedido o una factura, de modo que la diferencia no es «mejor» contra «peor», sino quién puede cambiar después esa hipótesis.

Un producto estándar no es una construcción a medida fallida, y una construcción a medida no es un CRM mejor, porque WooCommerce es un producto de comercio electrónico ya hecho, Moodle es una plataforma de aprendizaje ya hecha, WordPress es una plataforma de contenidos ya hecha, y los tres los vendemos como implantación, no como una construcción escondida bajo otro nombre. Laravel no es un producto en este sentido: es un framework sobre el que escribimos sistemas a medida desde la versión 4.0, en 2013, y no da un catálogo, un carrito ni un CRM hasta que alguien los escribe, de modo que confundir el framework con el producto es imaginar que «sobre Laravel» ya es una respuesta, cuando solo es el modo de escribirla.

La tercera cosa que aquí se suele mezclar es la suscripción frente a la propiedad, porque SaaS significa que usted paga por el uso y los datos los guarda el proveedor, una licencia perpetua significa que ha pagado el derecho a usar una versión y las actualizaciones suelen ser una línea aparte, y el código a medida que nosotros entregamos significa que el código fuente, la documentación y la configuración de la infraestructura son suyos. En ninguna de esas líneas hay una victoria automática; solo hay claridad sobre lo que compra, porque si no, al cabo de un año discute si «el sistema es nuestro» cuando en realidad es una suscripción que se puede cancelar.

La prueba con la que tomamos esta decisión

La prueba no es «si nos gusta esta pantalla», sino si el proceso que usted no puede ceder a un competidor encaja en una herramienta que el competidor puede comprar en la misma tienda: si encaja, la herramienta es la respuesta correcta, porque saldrá más barato y la mantendrá alguien cuyo único trabajo es esa herramienta, pero si no encaja, porque la tabla de precios, la aprobación del pedido o las condiciones de entrega son aquello con lo que usted se diferencia, entonces el producto estándar se convierte en una concesión, y concesión aquí significa que el proceso empieza a vivir en un Excel al lado del sistema.

La otra cara de la misma prueba se olvida con demasiada frecuencia, porque las necesidades son más a menudo comunes que únicas, y un programa de correo no se construye, una contabilidad que ya hace lo que pide la ley no se construye, y un embudo de ventas estándar en el que un trato es un trato tampoco se construye. Las administraciones que gastan su dinero según criterios escritos han nombrado esa misma forma de otro modo: primero se pregunta si en el mercado ya existe la cosa, y se construye cuando los productos disponibles no cubren el núcleo o cuando hay que gestionarla uno mismo, y eso no es una obligación de una empresa privada, y nosotros no la convertimos en tal, pero es la misma forma con la que decimos no a una construcción que se puede comprar.

El tercer error es reconstruir el producto hasta que deja de ser un producto, porque la configuración se queda dentro de los límites admitidos (campos, roles, flujos que el fabricante ha previsto), pero la adaptación que reescribe el núcleo para que el proceso «por fin encaje» gasta precisamente la ventaja por la que se compró el producto: las actualizaciones, la documentación, el hecho de que el fallo lo encuentre otro. Lo hemos visto en implantaciones de Moodle, donde primero comprobamos si el plugin ya existe y solo entonces escribimos el nuestro, y en sitios WordPress, donde no ponemos un tema ya hecho porque trae decenas de funciones que usted no necesita y que se convierten en un riesgo de seguridad, de modo que un producto con un núcleo ajeno no es un sistema a medida, sino un producto al que usted ha quitado el núcleo del fabricante.

Hacemos esta prueba en el taller de descubrimiento, no en una diapositiva de oferta, porque en la diapositiva siempre gana la construcción que parece preocuparse por usted, y en el taller gana el proceso que se puede nombrar. Si a los dos días resulta que el proceso encaja en una herramienta estándar, lo decimos, también cuando eso significa que el encargo de esta semana no es nuestro sistema no estándar, porque un artículo que siempre termina en «le construiremos el suyo» no es una prueba, sino una oferta escondida detrás de una pregunta.

Cuándo el producto estándar es la respuesta correcta

El producto estándar es la respuesta correcta allí donde el proceso ya tiene nombre en el sector y usted no es quien inventó ese nombre, porque el correo, la contabilidad que emite la factura como pide la ley, un CRM de ventas estándar, una plataforma de aprendizaje que registra el curso y su realización, y una tienda pequeña con un solo precio y un solo almacén son sitios donde construir no da nada por lo que merezca la pena pagar la diferencia entre la licencia y el sprint. Estas líneas no las vendemos como «solución provisional hasta que esté listo para el sistema de verdad», porque son los sistemas de verdad para esos procesos.

Estos productos también los vendemos, y eso no es la promesa encubierta de que dentro de un año vendrá la construcción: WordPress sigue siendo una plataforma de contenidos con un tema que escribimos nosotros, no con un tema ya hecho de una tienda; para una tienda pequeña con procesos estándar nosotros mismos decimos WooCommerce; Moodle sigue siendo una plataforma de aprendizaje que configuramos, migramos y personalizamos, no que inventamos de nuevo. Los precios de estas líneas están en las páginas de servicio y, más abajo en este artículo, en el sitio donde hace falta mostrar que el precio de partida del software a medida no es automáticamente la línea más cara, y aquí basta decir que el producto sigue siendo producto.

La consecuencia, si aun así encarga aquí una construcción, no es «un control mejor», sino un mantenimiento que ya no comparte con miles de otros, porque el parche de seguridad del programa de correo lo publica alguien para todos, y el parche de su propio programa de correo lo publica usted, y eso suena a libertad hasta la segunda noche en la que hay que corregir lo que el fabricante ya ha corregido en su producto. Esa libertad la vendemos donde el proceso la merece, no donde basta una licencia, porque de lo contrario le vendemos un trabajo que dentro de un año odiará como un duplicado caro.

Por eso lo más honesto que podemos decir antes de cualquier presupuesto no estándar es una lista de productos que le recomendaríamos en su lugar: si el proceso es formación, empiece por Moodle; si el proceso es contenido, empiece por WordPress; si el proceso es una tienda pequeña, empiece por WooCommerce; y si el proceso son facturas y la contabilidad que marca la ley, empiece por la contabilidad que ya tiene, y solo entonces pregunte si algo de eso tiene que convertirse en un sistema propio. Esta lista no es un acuerdo de colaboración; es la prueba que nos aplicamos a nosotros mismos.

Cuándo se justifica el software a medida

El software a medida se justifica cuando el proceso forma parte de su ventaja competitiva o las soluciones estándar exigen demasiadas concesiones, y el proceso puede seguir siendo un apoyo a lo que usted vende y aun así entrar en esta prueba, porque la prueba es el número de concesiones, no si usted vende software. Si el producto estándar empieza a pedirle que se convierta en el cliente medio, y el cliente medio no es su competitividad, la construcción es por fin una prueba que el proceso ha superado, no el deseo de una pantalla propia.

La integración no es aquí un argumento por sí sola, porque los productos también tienen interfaces y nosotros las conectamos, y el argumento empieza solo cuando la interfaz no basta y el proceso exige que la verdad sobre el stock, el precio o el estado viva en un solo sitio que usted controla. El portal de mapas de Sadales tīkls, que hemos construido sobre Laravel y Leaflet, muestra cortes, capacidad libre y la tarifa de conexión, y no es «un mapa más un plugin», porque la tarifa y la capacidad son el proceso del operador, no un campo de un producto de mapas; en el portal de Elektrum la sesión SSO se adhiere a cada petición antes de que el configurador Vue dibuje, y eso no es «un tema de energía en WordPress», porque la sesión es parte del servicio, no decoración.

El color, el logotipo y el orden del menú no son esta prueba, porque se pueden hacer en el producto, y los hacemos en el producto: un tema de Moodle con su paleta, un tema de WordPress sin lo de más, una tienda WooCommerce que se parece a usted. Si lo único que no se puede hacer en la herramienta estándar es «que se parezca a nosotros», usted no ha llegado al software a medida, sino a un tema, y mezclar estas dos cosas es pagar una construcción donde basta el diseño y después extrañarse de que el mantenimiento sea caro para un sistema cuya única diferencia es el color.

Tampoco decimos que cada sector exija automáticamente su propia plataforma, porque el nombre del sector no es una prueba, y la prueba es si el proceso de ese sector, en su empresa, es el mismo que el fabricante ya ha puesto en el paquete, o es su modo de trabajar el sector, y ese modo no se puede comprar al lado. Si se puede comprar, cómprelo; si no, entonces se trata de un sistema de negocio a medida, y solo entonces merece la pena hablar de un taller de descubrimiento, no de un tema.

El tercer camino: un producto con nuestro código encima

Entre el producto estándar y la construcción desde cero hay un tercer camino, que también vendemos y que las comparaciones suelen saltarse: el producto sigue siendo producto, y encima escribimos lo que el producto no hace, y eso no es «un poco de software a medida», sino la decisión de dejar el núcleo donde lo mantiene el fabricante y escribir solo la capa que es suya. El portal de servicios de Sadales tīkls está sobre October CMS, y las calculadoras, los calendarios y el aviso de avería son trabajo sobre el producto, no un motor de contenidos nuevo; en una implantación de Moodle primero comprobamos si el plugin de evaluación o de informes ya existe, y solo entonces escribimos el nuestro, porque de lo contrario le vendemos un duplicado.

Si la pregunta es el catálogo, los precios, el pedido y la entrega, esa es la prueba de la tienda, y ya está escrita en el artículo sobre la elección entre WooCommerce y Laravel, así que aquí no la reescribimos ni la convertimos en el valor por defecto de un sistema no estándar. Si la pregunta es un CRM, un ERP, un panel interno o un proceso de sector, quédese aquí, porque la tienda es un caso de la misma prueba, no el contenido entero de la elección.

En el lado de WordPress el tercer camino parece un rechazo, porque no ponemos temas ya hechos, traen funciones que se convierten en un riesgo de seguridad, y construimos un tema limpio solo con lo necesario, y eso sigue siendo un producto: el editor escribe en WordPress, no en un editor inventado por nosotros, y las actualizaciones vienen de WordPress, no de un solo lanzamiento nuestro. La diferencia entre esto y un sistema a medida es que el proceso de contenidos encaja en el producto, pero el proceso del tema no encaja en un tema de ThemeForest, y mezclarlos es o bien poner un tema ajeno y después extrañarse de los plugins, o bien construir un CMS propio para un contenido para el que el CMS ya existe.

Este límite es también el sitio donde decimos no a «una pequeña reconstrucción» que al tercer mes ya es el núcleo, porque si los ajustes superan a la configuración, si cada actualización exige primero nuestro código, si el campo del fabricante ya no es la verdad, usted ya no está en el tercer camino. Está en una construcción escondida detrás del nombre del producto, y entonces es más honesto nombrar la construcción y facturarla como construcción, porque de lo contrario paga un producto que ya no se puede actualizar y un sistema que todavía no se puede tomar.

El dinero y el tiempo son una forma, no una tarifa

Un sistema a medida empieza con nosotros desde 8.000 €, y el ciclo completo suele ocupar de 12 a 32 semanas, y eso es un precio de partida, no una factura, y 12 semanas no son los mismos tres primeros meses en los que prometemos un MVP usable: el plazo de partida es la construcción más corta, el MVP es el paso a partir del cual el sistema ya se usa, y 32 semanas son el techo de un trabajo mayor, que cabe también en lo que en la FAQ general llamamos de seis a ocho meses para un sistema a medida grande. La página de Laravel empieza desde los mismos 8.000 € y 6–24 semanas, y no es un software a medida más barato: es la página para quien ya sabe que el trabajo es Laravel, no la prueba de si el trabajo es siquiera una construcción.

Estos números no pueden convertirse en la frase «el software a medida es la opción más cara», porque la implantación de Moodle empieza desde 15.000 €, la versión Pro de la tienda cuesta 9.500 €, y las dos están por encima del precio de partida del software a medida, porque una es la implantación de un producto grande y la otra es una tienda con almacén y precios B2B. Comparar el «desde 8.000 €» con el «desde» de Moodle como «construcción contra producto» es una aritmética equivocada, porque solo se pueden comparar los dos caminos de un mismo proceso, y aun entonces las dos partes son precios de partida, no totales; en los trabajos no estándar más grandes facturamos por tiempo y materiales con un límite semanal, porque un precio fijo ahí suele significar un recargo por riesgo o una discusión sobre el alcance, y la tarifa horaria es 50 €.

La suscripción frente a la construcción tampoco es una fórmula en la que al cabo de N años un lado gana solo, y la planificación de gasto público nombra lo que también vemos en contratos privados: la cuota SaaS puede subir con el número de usuarios o con la indexación, las integraciones siguen siendo su coste, y para cambiar de proveedor hace falta un plan de salida, porque los datos los guarda el proveedor. Eso no es un porcentaje de la construcción que citemos aquí, porque la nota a pie detrás de esas cifras lleva a blogs de proveedores, y esas cifras no las escribimos, pero la forma se queda: la suscripción es una línea cada año, la construcción es un precio de partida más el mantenimiento, y ninguna de las dos va sin línea.

El Reglamento de Datos, aplicable en la Unión desde el 12 de septiembre de 2025, ayuda a sacar los datos exportables de un servicio en la nube y prohíbe al proveedor poner obstáculos al cambio, pero la equivalencia funcional la exige a un servicio de infraestructura, no a un CRM que usted simplemente «traslada», y el Reglamento 2023/2854 no promete que el proceso se mude junto con el archivo. El artículo 20 del Reglamento general de protección de datos (RGPD) transfiere los datos personales que el interesado haya facilitado, no la aplicación, ni su configuración, ni las reglas de negocio, de modo que si quiere un sistema que pueda llevar a otro desarrollador, eso es el código fuente que nosotros entregamos, no una exportación desde el panel de otro, y aquí termina también esta sección, porque la frase siguiente ya sería una tarifa que para esta pregunta no tenemos.

Lo que no decimos cuando hablamos de software a medida

No decimos que un sistema propio sea siempre más inteligente, que el producto estándar sea para quienes «aún no han crecido», o que a los tres años la construcción se haya amortizado seguro, porque una curva así, sin su proceso, es un invento. Un artículo que, después de un comienzo honesto, acaba de todos modos en que hay que comprar la construcción ha ido demasiado lejos, y lo hemos visto las veces suficientes para parar aquí, porque la honestidad es un límite y una prueba corta es el objetivo.

Tampoco decimos que Laravel sea la respuesta a la pregunta del producto estándar, porque Laravel es el modo en que escribimos cuando la prueba ya ha dado una construcción, y vender un framework a quien necesita Moodle es vender un martillo a quien necesita un estante. Nuestra página de Laravel empieza desde 8.000 € y habla de API, colas y pruebas, pero este artículo habla de si usted necesita siquiera esa página, y mezclarlas es elegir el instrumento antes de haber elegido el trabajo.

Tampoco decimos que el taller de descubrimiento sea un modo encubierto de meterle en una construcción, porque el resultado del taller es un plan que sigue siendo útil aunque decida no contar con nosotros, y a veces el plan dice: tome el producto que ya ha nombrado, y lo implantaremos nosotros, o lo implantará otro. Si esta frase le suena a un encargo perdido, es porque es un encargo perdido, y preferimos perder una construcción en la que habría que escribir otro CRM a ganar un cliente que al cabo de un año pregunta por qué mantiene un sistema que podía suscribir.

Para la contratación pública esta prueba no funciona igual que para una empresa privada, y esa regla no se traslada, porque en la planificación pública la Ley 40/2015 pide consultar si ya hay una solución reutilizable, y eso pertenece a la contratación, no a esta frase, pero en el lado privado pertenecen su proceso y nuestra tarifa. Los dos lados pueden llegar a la misma respuesta, y no llegan a ella porque uno sea la ley del otro.

Cómo se toma esta decisión con nosotros

El trabajo empieza con un taller de descubrimiento de dos a tres días, en el que con su equipo repasamos los procesos, los roles de usuario, los riesgos y el alcance del MVP, y no es una mañana de diapositivas, sino un trabajo después del cual podemos decir si el proceso encaja en una herramienta estándar, si pide el tercer camino o si es una construcción. Si la respuesta es un producto, el taller se ha amortizado con esa frase; si la respuesta es una construcción, el siguiente paso no es código.

Antes del código de producción preparamos en dos o tres semanas un prototipo navegable, porque ahí cambiar de idea es más barato que en un sistema terminado, y el prototipo no es «para tener algo que mostrar al consejo», sino el sitio donde usted ve que la tabla de precios que ayer nombró es en realidad otra tabla, y donde ese hallazgo cuesta días, no meses. Solo después empieza el desarrollo: en los tres primeros meses construimos un MVP que se puede usar de verdad, y a partir de ahí ampliamos de forma iterativa, en sprints de dos semanas con una demostración después de cada uno.

Al final recibe el código fuente, la documentación y la configuración de la infraestructura y puede llevarlo a otro desarrollador, y eso no es la promesa de que el traslado será agradable, sino la promesa de que no queda atado a nuestra cuenta. En los proyectos más grandes nos quedamos en tiempo y materiales con un límite semanal, y el límite del MVP lo fijamos de todos modos, porque de lo contrario «agile» se convierte en una palabra detrás de la cual desaparece el alcance, y si después del taller usted toma otro camino, el plan se queda con usted, como hemos escrito en la página del servicio, y este artículo no cambia eso.

Antes de escribirnos, escriba el proceso en una sola página sin el nombre de ninguna herramienta y marque las líneas que no puede ceder a un lanzamiento ajeno: si la página está vacía o solo dice «para tener un sistema propio», usted necesita un producto, y también se lo diremos, pero si en la página hay un proceso que el competidor no puede comprar como herramienta estándar, entonces merece la pena hablar de construir. Escríbanos si quiere que leamos esa página con usted y le digamos de qué lado está, también cuando la respuesta sea tomar el producto que usted ya ha nombrado.