Desarrollo de software a medida: cuándo conviene de verdad

El desarrollo de software a medida consiste en construir una aplicación pensada para el proceso concreto de una empresa, en lugar de adaptar la empresa a un producto ya hecho. El resultado es tuyo: el código, los datos, las reglas de negocio y la decisión de qué se cambia y cuándo. Se justifica cuando el proceso que quieres soportar es parte de cómo ganas dinero, no cuando es administración corriente.

Y conviene decir la otra mitad desde el principio, porque casi nadie que vende esto la dice: la mayoría de las empresas no necesita software a medida. Facturación, correo, firma electrónica, contabilidad, tienda online estándar, gestión de tareas — todo eso ya existe hecho, mantenido por otro y por una cuota que ningún desarrollo propio va a igualar. El software a medida empieza a tener sentido en el punto exacto en que el producto estándar te obliga a trabajar de una forma que te resta ventaja, o en que mantenerlo a base de hojas de cálculo, copiar y pegar entre herramientas y correos internos ya cuesta más que construirlo.

Cuándo compensa (y cuándo no)

No es una cuestión de tamaño de empresa, sino de qué proceso estamos hablando. Un criterio que funciona:

Compensa cuando:

• El proceso es tu diferencial. Si tu forma de cotizar, de asignar trabajo o de liquidar comisiones es lo que te hace competitivo, meterla dentro de un producto genérico la aplana hasta dejarla igual a la de todos.
• Hay volumen humano repetido: alguien dedica horas cada semana a mover datos de un sitio a otro, revisar lo mismo o rehacer un informe. Ese coste no aparece en ninguna factura y es el que suele pagar el proyecto.
• Necesitas que varias herramientas hablen entre sí y ninguna integración estándar hace exactamente eso.
• Las licencias por usuario crecen más rápido que tu equipo, y estás pagando por un producto del que usas el 20 %.
• Tienes requisitos que el producto estándar no cubre: quién puede ver qué, trazabilidad, datos que no pueden salir de un sitio, reglas de negocio que cambian por cliente.

No compensa cuando:

• Existe un producto estándar que cubre el 90 % y el 10 % restante es preferencia, no necesidad. Ese 10 % es exactamente lo que dispara el presupuesto.
• El proceso todavía no está claro. Si no puedes explicarlo en una pizarra, no está listo para convertirse en software: lo primero que hará el proyecto es descubrir que cada persona lo hace distinto.
• Nadie dentro va a mantener la relación con el producto. El software a medida no se entrega y se olvida; necesita un responsable que decida qué cambia (y eso enlaza con el mantenimiento, que aquí no es opcional).
• Lo que buscas en realidad es una web. Si el objetivo es presencia y captación, eso es otro proyecto y otro presupuesto: lo trato en la guía de precios de una página web.

Software a medida, producto estándar y no-code: las tres opciones reales

| | Producto estándar (SaaS) | No-code / low-code | Software a medida | |---|---|---|---| | Puesta en marcha | Días | Semanas | Semanas o meses | | Coste inicial | Bajo | Bajo-medio | Alto | | Coste a 3 años | Licencias por usuario, crecen | Licencias + límites de plan | Desarrollo + mantenimiento | | Se adapta a tu proceso | Tu proceso se adapta a él | Hasta cierto punto | Sí, es el punto | | Propiedad | De ellos | De ellos | Tuya | | Techo | El del producto | El de la plataforma | El que decidas | | Riesgo principal | Que cambien precios o cierren funciones | Chocar con el límite a mitad de camino | Empezar sin tener el proceso claro |

La conclusión honesta es que casi nunca es una elección pura. Lo más habitual y lo más sensato es un híbrido: producto estándar para lo genérico (correo, contabilidad, pagos), y a medida sólo el núcleo donde te juegas la ventaja. El error caro no es elegir mal la tecnología, es construir a medida lo que ya estaba resuelto.

Qué encarece de verdad un proyecto a medida

Lo que se suele imaginar es que el coste está en las pantallas. En la práctica el presupuesto se mueve por otras cosas:

Las integraciones. Conectar con lo que ya existe —el CRM, la pasarela de pago, el correo, el ERP, la API de un proveedor— es donde aparecen los imprevistos: sistemas de terceros que cambian sin avisar, límites de peticiones, datos que llegan en un formato que la documentación no menciona. En un proyecto de logística en el que trabajé, el seguimiento de envíos dependía de la API de la transportista; el trabajo visible era una pantalla de consulta, y el trabajo real era todo lo que hay que hacer para que esa pantalla no mienta cuando la API responde tarde o mal.

La migración de datos. Casi nadie empieza de cero. Los datos vienen de otro sistema, de hojas de cálculo o de las dos cosas, con duplicados, campos usados para lo que no eran y años de excepciones. He hecho migraciones masivas de catálogos de producto —colores, tejidos, variantes, precios— y la parte de programar el proceso fue la corta; la larga fue decidir qué hacer con lo que no encajaba.

Los permisos. "¿Quién puede ver esto?" parece un detalle y es una decisión de arquitectura. En una plataforma multiempresa que construí para el sector energético, el aislamiento entre clientes está en la propia base de datos (RLS en PostgreSQL), no sólo en la aplicación: si un fallo del código intentara leer datos de otra empresa, la base los niega igual. Eso se decide al principio o se paga carísimo después.

Los casos raros. El 80 % del proceso es fácil. El presupuesto lo fija el 20 % que nadie cuenta en la primera reunión: la devolución parcial, el cliente con condiciones distintas, el mes que se cierra a mano, la comisión que se reparte entre tres personas. Ese 20 % es, además, lo que justificaba hacerlo a medida.

El después. Un sistema vivo cambia porque el negocio cambia. Presupuestar sólo la construcción y no la evolución es la forma más común de acabar con software propio que nadie toca y que en dos años vuelve a ser el problema.

Cuánto cuesta

No voy a publicar una tarifa, porque cualquier cifra sin alcance detrás es marketing. Lo que sí puedo decirte es qué mueve el precio, que es lo que necesitas para leer un presupuesto:

1. Cuántos procesos entran. Uno bien resuelto cuesta una fracción de "toda la operación".
2. Cuántos sistemas hay que integrar y si tienen API decente o hay que pelearse con ellos.
3. Si hay migración de datos y en qué estado están.
4. Cuántos tipos de usuario con permisos distintos.
5. Si necesita tiempo real (avisos, actualizaciones en vivo) o le basta con recargar.
6. Qué nivel de disponibilidad exige: no cuesta lo mismo algo interno que algo por lo que cobras a tus clientes.

Y un consejo práctico: desconfía del presupuesto cerrado sobre un requisito de dos líneas. O el proveedor ya asumió lo que va a recortar, o el precio incluye un colchón para lo que todavía no ha preguntado. Un buen punto de partida es acotar una primera fase pequeña y útil por sí sola —el proceso que más duele, funcionando— y decidir el resto con eso ya en producción.

Cómo suele ir un proyecto bien planteado

1. Entender el proceso real, no el que está escrito. Se hace mirando cómo trabaja la gente hoy, incluidos los apaños. Ahí aparece la mitad de los requisitos.
2. Recortar el alcance de la primera entrega hasta que sea algo que se pueda poner en uso. Si la primera versión tarda seis meses en verse, el proyecto ya tiene un problema.
3. Construir por partes que se entregan. Cada entrega se usa, se corrige y ajusta la siguiente. La alternativa —desaparecer medio año y volver con todo— es donde se acumulan los malentendidos.
4. Migrar los datos pronto, no la semana antes de arrancar: es donde salen las sorpresas.
5. Poner a la gente a usarlo con datos de verdad antes de apagar el sistema anterior.
6. Dejarlo mantenido: alguien responsable de los cambios, copias de seguridad probadas y una vía clara para pedir mejoras.

Lo que deberías exigir en el contrato

Esto es lo que separa "software a medida" de "he alquilado algo que parece mío":

• Propiedad del código y acceso al repositorio desde el primer día.
• Tus datos, exportables en un formato utilizable, sin pedir permiso.
• Infraestructura a tu nombre: los servicios (servidor, base de datos, dominios) contratados por ti, con el proveedor invitado a gestionarlos.
• Documentación mínima para que otro equipo pueda continuar: cómo se levanta, de qué depende, qué credenciales hacen falta.
• Condiciones de mantenimiento por escrito: qué entra, qué tiempo de respuesta y qué pasa si un día decides cambiar de proveedor.

Si algo de esto no está, lo que estás comprando no es a medida: es una dependencia.

Qué hago yo, para que sepas con quién hablas

Construyo software a medida sobre stack propio —Next.js, PostgreSQL, integraciones y automatización con IA— y suelo trabajar el híbrido: producto estándar donde ya está resuelto y desarrollo propio donde está la ventaja. Algunos ejemplos de trabajo real, sin nombres de clientes:

• Un CRM construido desde cero para la venta de contratos eléctricos en España: contactos, oportunidades, tareas, citas y calendario, con grupos de permisos, saldo prepago con pasarela de pago y liquidación de comisiones a varios niveles. Ninguna de esas dos últimas cosas la resolvía un CRM comercial sin retorcerlo.
• Automatización de catálogos en agro y textil: procesos que toman datos de producto de varios orígenes, los normalizan y los dejan listos para vender, con un asistente de consultas encima.
• Integraciones de operación: seguimiento de envíos contra la API de una transportista, cobro con Stripe y Redsys en comercio electrónico, correo y CRM conectados a los flujos internos.
• Automatización de un despacho profesional: gestor de contenido legal y procesos internos conectados, para dejar de repetir trabajo administrativo.
• Y este mismo enfoque aplicado a mi propio negocio: agentes que operan procesos con una persona aprobando las decisiones, no sustituyéndola.

Si estás valorando si tu caso justifica un desarrollo a medida, la conversación útil no empieza por la tecnología: empieza por el proceso, por cuántas horas al mes se van en él y por si eso es lo que te distingue. Cuéntame el caso y te digo con franqueza si lo tuyo se resuelve con algo que ya existe.

Preguntas frecuentes

¿Qué es exactamente el desarrollo de software a medida?

Es construir una aplicación para el proceso concreto de una empresa, en lugar de adaptar la empresa a un producto ya hecho. Incluye el análisis del proceso, la construcción, las integraciones con lo que ya usas, la migración de los datos existentes y el mantenimiento posterior. La diferencia práctica frente a un SaaS es la propiedad: el código, los datos y el ritmo de los cambios son tuyos.

¿Cuánto cuesta un software a medida?

Depende del alcance, y cualquier cifra sin alcance detrás es publicidad. Lo que mueve el precio es cuántos procesos entran, cuántos sistemas hay que integrar, si hay que migrar datos y en qué estado están, cuántos perfiles de usuario con permisos distintos existen y qué nivel de disponibilidad se exige. Lo razonable es acotar una primera fase que sea útil por sí sola y presupuestar el resto con esa fase ya en producción.

¿Es mejor un software a medida o uno estándar?

Depende de qué proceso hablemos. Para lo genérico —contabilidad, correo, facturación, firma— el producto estándar casi siempre gana: cuesta menos y lo mantiene otro. El desarrollo a medida compensa en el núcleo donde tu forma de trabajar es tu ventaja, o cuando el producto estándar te obliga a operar de una manera que te resta competitividad. Lo más habitual es un híbrido de las dos cosas.

¿Cuánto tarda en construirse?

Depende del alcance, pero la señal de que está bien planteado es que la primera versión utilizable llegue en semanas, no en meses. Un proyecto que desaparece medio año y vuelve con todo terminado acumula malentendidos que se pagan al final. Por partes que se entregan y se usan, cada entrega corrige la siguiente.

¿De quién es el código cuando lo hace un proveedor externo?

Debería ser tuyo, y conviene dejarlo por escrito antes de empezar: propiedad del código, acceso al repositorio desde el primer día, datos exportables en un formato utilizable e infraestructura contratada a tu nombre. Si el proveedor conserva el código o la infraestructura, lo que has comprado no es software a medida, es una dependencia con otro nombre.