Cuánto cuesta un software a medida: qué determina el presupuesto

Es la primera pregunta que hace casi todo el mundo, y la más difícil de responder con un número suelto. El software a medida no tiene tarifa de catálogo porque no hay dos proyectos iguales: una web corporativa y una plataforma que gestiona inventario, pagos y tres integraciones externas no comparten ni remotamente el mismo presupuesto, aunque las dos sean «una aplicación web». Esto es lo que de verdad mueve el precio.

El alcance, no las «funcionalidades»

Pedir precio por una lista de funcionalidades sueltas («login, panel de usuario, pagos») da estimaciones inútiles, porque cada una puede ser trivial o enorme según el detalle. Un «login» puede ser email y contraseña, o puede incluir SSO corporativo, roles granulares y auditoría de accesos. Lo que de verdad define el coste es el alcance: qué problema resuelve el sistema, quién lo usa, qué pasa si falla y qué reglas de negocio tiene que respetar. Un buen proveedor no cotiza una lista de features; entiende el problema primero.

Qué variables mueven el presupuesto

• Integraciones. Conectar con un ERP, una pasarela de pago o un sistema externo de terceros añade complejidad real: hay que entender su API, gestionar sus fallos y mantener la integración cuando cambie. Cada integración es, en la práctica, un proyecto dentro del proyecto.
• Datos y reglas de negocio. Un sistema con lógica compleja —permisos por rol, flujos de aprobación, cálculos específicos del sector— cuesta más que uno con un modelo de datos simple, aunque la interfaz se vea parecida.
• Volumen y rendimiento. No es lo mismo diseñar para cien usuarios internos que para tráfico público con picos. La arquitectura cambia, y con ella el tiempo de desarrollo.
• Vida útil esperada. Un prototipo para validar una idea y un sistema que va a operar cinco años con distintos equipos técnicos no se construyen igual. El segundo exige más documentación, más pruebas y una arquitectura pensada para que otros la entiendan sin ti delante.
• Cumplimiento normativo. RGPD, ENS, o requisitos sectoriales concretos añaden trabajo de diseño y de auditoría que no se ve en la interfaz pero está en el presupuesto.

Por fases, no todo de golpe

La forma más razonable de abordar un proyecto grande es dividirlo en fases con entregas visibles: un alcance inicial que resuelve lo esencial y sale a producción, y ampliaciones posteriores según el sistema demuestra su valor. Esto reduce el riesgo para ambas partes —no se paga todo por adelantado sobre una idea sin validar— y permite ajustar el rumbo con información real, no con suposiciones iniciales.

Qué preguntar antes de pedir presupuesto

Antes de escribir a un proveedor, ayuda tener claro: qué problema concreto resuelve el sistema, quién lo va a usar y con qué frecuencia, con qué otros sistemas tiene que hablar, y qué pasa el día que algo falla. No hace falta tener las respuestas perfectas —para eso está la primera conversación— pero cuanto más claro esté el problema, más ajustado (y más rápido) será el presupuesto.

Lo que no debería variar

Sea cual sea el alcance, hay cosas que un presupuesto serio siempre debería incluir sin coste oculto: una propuesta técnica por escrito, hitos claros, y la propiedad del código y la documentación al terminar. Si un proveedor no puede explicarte por qué cuesta lo que cuesta, es una señal de alarma tan importante como el propio número.

En Onubia damos precio y plazo concretos tras entender el proyecto, sin letra pequeña ni sorpresas a mitad de camino. Si tienes algo entre manos, hablamos de qué encaja mejor para tu caso.