Software a medida para empresas: cuándo compensa, cuánto cuesta pensarlo bien y qué sale mal

Si estás leyendo esto, probablemente alguien en tu empresa ha dicho «necesitamos algo que haga esto» y te ha tocado decidir si se compra o se construye. Este texto es para esa decisión: cuándo compensa el software a medida para empresas y cuándo no. No te voy a explicar qué es un patrón de diseño.

Cuándo compensa el software a medida para empresas frente a un producto de catálogo

Un producto de catálogo funciona bien cuando tu proceso se parece al del proveedor. El problema aparece cuando no se parece. Hay tres señales que suelen indicar que el catálogo te va a costar más de lo que parece:

• Tu proceso tiene reglas que el producto no contempla y que no vas a cambiar. Imagina un configurador de presupuestos para una empresa con producto vendido en más de 100 países. Cada mercado tiene impuestos, idiomas y condiciones distintas. Si adaptas un producto genérico a eso, acabas pagando módulos que no usas y reparando tus parches en cada actualización.
• Tienes que integrarte con sistemas que el proveedor no conoce. Un ERP de hace quince años, una pasarela de pago propia, una base de datos de fabricación. Las integraciones son lo que más se rompe en cualquier software, y en un producto de catálogo las pagas dos veces: la licencia y el parche.
• Cualquier cambio depende de un tercero. Si para cambiar un campo del formulario tienes que esperar a la cola de soporte del proveedor, el coste real no es el cambio. Es la espera.

Para decidir, suma lo que cuesta adaptar lo que compras: licencias, horas de configuración, consultoría, y el mantenimiento de cada adaptación cuando el proveedor saque versión nueva. Compáralo con un software a medida para empresas acotado a los procesos que de verdad necesitas. A veces gana el catálogo. A veces no.

Y no todo merece software propio. Si tu proceso es estándar, como contabilidad, nóminas o correo, compra. Construir algo que ya funciona bien y cuesta poco es una mala inversión, aunque suene a modernizar.

Cómo se desarrolla el software a medida: fases y lo que tiene que decidir la empresa

Un proyecto a medida serio tiene fases claras. Estas son las que suelen aparecer, con lo que se entrega en cada una y qué te toca decidir a ti:

1. Descubrimiento. Se estudia el proceso real, no el que figura en el manual. Se entrega un documento de alcance y, igual de importante, una lista de lo que la primera versión no hace. Tu decisión: quién en la empresa responde por ese proceso. Si nadie lo tiene claro, el proyecto no empieza todavía.
2. Diseño y prototipo. Pantallas y flujos sobre tus datos reales, no sobre datos de ejemplo. Aquí es donde se descubre si lo que pediste es lo que necesitas. Tu decisión: aprobar el flujo antes de programarlo, porque cambiarlo en papel es barato y cambiarlo en código no.
3. Desarrollo por entregas. Cada pocas semanas hay algo que se puede probar. Tu decisión: qué entra en cada entrega y qué espera a la siguiente.
4. Puesta en producción. Migración de datos, formación de usuarios y, si es posible, un periodo en paralelo con el sistema anterior.
5. Mantenimiento. El software no se termina. Quedan los fallos que aparecen con el uso, los cambios legales (facturación, impuestos, normativa) y las librerías que hay que actualizar. Pregunta antes de firmar qué cubre el mantenimiento y cuánto tarda un cambio pequeño.

Qué sale mal en un proyecto a medida y cómo se evita

Nadie que vende un proyecto te va a contar esto con franqueza, así que lo cuento yo. Estos son los problemas que más se repiten en proyectos de software, a medida o no, y lo que se puede hacer con cada uno.

Los retrasos. La causa más habitual es que el alcance no estaba cerrado y el proceso real aparece a mitad de camino. Alguien descubre una excepción que nadie mencionó y el calendario se mueve. Cómo se evita: que la fase de descubrimiento termine con un alcance firmado y con la lista explícita de lo que no entra. Si ya vas con retraso, la respuesta casi nunca es meter más personas. Suele ser parar, revisar qué queda y recortar.

El alcance que crece. Cada «ya que estamos, podríamos…» suma horas, y ninguna parece grave por separado. Al final el proyecto tiene el doble de funciones y el mismo plazo. Cómo se evita: cada petición nueva entra en la lista con su coste en tiempo, y la decides tú, no el proveedor ni el último que habló con el equipo. Una regla que funciona: si no cabe en el plazo, va a la siguiente entrega.

Depender de una sola persona. Si quien conoce el sistema se va, se pone enfermo o deja la agencia, el conocimiento se va con él. Y en proyectos pequeños es lo más frecuente. Cómo se evita: el código en un repositorio a tu nombre, las decisiones documentadas y, al menos, otra persona que haya tocado cada parte. Pregúntale al proveedor, sin rodeos: ¿quién más puede trabajar en esto si yo no puedo contactar contigo?

El presupuesto inicial optimista. El primer número se da antes de conocer bien el proceso, así que casi siempre se queda corto. Es normal. Lo que no es normal es no revisarlo cuando aparecen los datos reales. Si el proveedor no te explica por qué cambia el precio, desconfía.

Señales de que tu proyecto va mal, aunque nadie te lo diga: las entregas se mueven sin explicación, nadie de tu lado puede describir qué hace el sistema, o no tienes acceso al código.

ERP a medida frente a ERP de catálogo

Un ERP de catálogo cubre lo que casi todas las empresas necesitan: contabilidad, compras, stock, facturación, nóminas. Está probado por muchos clientes y las actualizaciones legales corren a cargo del proveedor. Su punto débil es que tu empresa tiene que adaptarse a él.

Un ERP a medida hace lo contrario: se construye sobre tus procesos tal como son, sin módulos que no usas. Pero lo construyes tú, lo mantienes tú y las actualizaciones legales también son cosa tuya o de quien lo mantenga.

Lo que casi nadie cuenta de esta decisión son los datos. Al migrar aparecen clientes con dos fichas, artículos con códigos distintos según el departamento y pedidos que nadie sabe si siguen vivos. Antes de decidir nada, audita tus datos. En muchos proyectos, la migración cuesta más que el software, y el catálogo no la libra de ese trabajo.

Cuándo basta el catálogo: cuando lo que te diferencia de tu competencia no es cómo gestionas la administración, sino el servicio, el producto o la relación con el cliente. Entonces, compra y dedica el dinero a lo que sí te diferencia.

La opción que más veces tiene sentido es la mixta: catálogo para contabilidad y nóminas, y software a medida para el proceso que te distingue, conectado al resto. No es la respuesta bonita, pero suele ser la honesta.

Por qué .NET para software empresarial que tiene que durar años

Un software de empresa suele vivir entre diez y veinte años. Lo que importa en ese plazo no es la moda, sino tres cosas.

Soporte a largo plazo. Microsoft publica versiones LTS con una fecha de fin de soporte conocida. Pregunta siempre en qué versión se entrega el proyecto y hasta cuándo tiene soporte. Un sistema que se entrega sobre una versión a punto de caducar te obliga a migrar antes de lo que pensabas. Hoy, por ejemplo, .NET 8 deja de tener soporte el 10 de noviembre de 2026, y el LTS vigente es .NET 10.

Disponibilidad de perfiles. En el mercado de empresa hay muchos desarrolladores con experiencia en .NET. Cuando alguien se va, sustituirlo es más fácil que con tecnologías de nicho. Yo he liderado migraciones a .NET 8 y MAUI, así que lo digo con experiencia de primera mano: el problema casi nunca es la tecnología, es el código que nadie se atreve a tocar.

Mantenimiento. La plataforma es madura, sus herramientas son estables y las actualizaciones suelen mantener la compatibilidad. Eso reduce el coste de mantener el software año tras año.

No es la única opción válida. Un stack distinto, bien elegido y bien mantenido, también dura. Lo que hace que un software dure no es el lenguaje: son el código limpio, la documentación y que haya más de una persona que lo entienda.

Coste y plazo antes de pedir presupuesto

El precio de un software a medida para empresas depende de dos cosas: cuántas horas lleva y cuánto vale cada hora. Aquí te doy lo que más pesa en tu decisión, que son las horas, y los factores que las mueven. El precio exacto sale de hablar de tu caso concreto.

La tarifa. Un precio por hora muy por debajo de lo normal suele significar menos experiencia, menos pruebas o más riesgo para tu proyecto. Conviene preguntar por qué antes de firmar.

Las horas, por tipo de proyecto. Estas cifras salen de mi experiencia: llevo casi 20 años construyendo este tipo de software. Son estimaciones, no contratos: cada caso cae dentro del rango según lo que se encuentre al empezar.

• Módulo que se integra con un sistema existente: 80 a 150 horas.
• Aplicación de escritorio .NET: 150 a 300 horas.
• Intranet o herramienta interna completa, desde cero: 200 a 400 horas.

Esos rangos describen proyectos de tamaño medio, que son los más frecuentes. Un proyecto grande, con muchos procesos, varias integraciones, muchos perfiles de usuario o operación en varios países o idiomas, puede irse perfectamente a 1.000 horas o más. Eso no significa que algo vaya mal: significa que es otro proyecto. Por eso el primer paso serio no es dar un número, sino acotar el alcance en la fase de descubrimiento. Sin ese trabajo, cualquier cifra, la mía incluida, es una suposición.

La migración se estima por componente. Pasar de .NET Framework a .NET 10 no tiene un precio único, porque depende de lo que tenga tu sistema. Una agencia, C&A Systems, publica estas horas base por tipo de componente:

• Aplicación de consola: 8 a 24 horas
• Librerías: 16 a 40 horas
• ASP.NET MVC: 40 a 120 horas
• Web API: 40 a 100 horas
• Servicios de Windows: 60 a 140 horas
• WCF: 120 a 300 horas
• WebForms: 300 a 800 horas

El total es la suma de los componentes que tenga tu sistema, así que una migración puede ir de unas pocas decenas de horas a varios miles, según su tamaño. La misma agencia cita un caso de referencia: 400 horas base para una aplicación WebForms de 180.000 líneas. Parte de tu inventario de componentes, no de una media. Si tu sistema es de este tipo, tienes más detalle sobre cómo se aborda una migración así en modernización de sistemas legacy. Y para quien quiera el detalle técnico de cómo se hace por partes, tengo un post sobre el patrón strangler fig.

Lo que mueve el número. Las horas de arriba son el punto de partida. Estos factores las suben o las bajan:

Lo que lo sube:

• El número de procesos que hay que cubrir, y cuántas excepciones tiene cada uno.
• Las integraciones con sistemas externos. Cada una es una fuente de trabajo y de riesgo.
• El estado de tus datos. Migrar datos sucios cuesta más que programar.
• El estado del sistema actual: código sin documentar, sin pruebas automáticas o con dependencias que ya no reciben actualizaciones. Cada una añade horas antes de tocar una sola función nueva.
• El número de perfiles de usuario, con permisos distintos.
• Los requisitos legales o de seguridad, como facturación electrónica o protección de datos.
• Cuánto puede cambiar el proceso durante el proyecto. Si cambia mucho, el precio sube aunque el alcance no haya crecido.

Lo que lo baja:

• Un proceso acotado, con una primera versión que hace menos y lo hace bien.
• Datos limpios antes de empezar.
• Pruebas automáticas y documentación que ya existen. Sin ellas, cada cambio exige comprobar a mano más partes del sistema.
• Decisiones tomadas antes del proyecto, no durante.
• Una fase de descubrimiento que cierre el alcance antes de programar.

Las horas dan el esfuerzo, no el calendario. Cuántas semanas tarda cada fase depende de cuántas personas trabajan en el proyecto y de cuánto cambia el proceso por el camino. Pregunta por el calendario de cada fase en la primera reunión, y desconfía de quien lo cierre sin haber visto tu caso.

El precio final sale de cruzar esas horas con tu tarifa y con lo que aparezca en tu sistema al empezar. Para saber cuánto costaría tu caso, lo más útil es pedir presupuesto con las respuestas de abajo ya preparadas.

Antes de pedir presupuesto, ten preparadas cinco respuestas: qué problema quieres resolver en una frase, qué procesos están implicados, qué sistemas tienes que conectar, cuándo lo necesitas y qué pasa si no lo tienes. Con eso, cualquier proveedor serio puede darte un número que signifique algo.

Si quieres que lo revise contigo, la página de desarrollo .NET a medida explica cómo trabajo y qué puedes esperar del primer contacto.

De quién es el código si el proveedor desaparece

Pregunta antes de firmar: ¿el código está en un repositorio a tu nombre? ¿Quién tiene las credenciales? ¿Puedes contratar a otro equipo para continuar sin reescribir todo? Si alguna respuesta es no, el software es de quien lo programó, aunque lo hayas pagado tú.

Si ya tienes esas cinco respuestas, hablemos. Si todavía no, no pasa nada: vuelve cuando las tengas, o escríbeme igualmente y lo miramos juntos.

Cuéntame tu caso