Es la primera pregunta de casi todas las reuniones y la más difícil de responder en frío. "Un software a medida" puede ser una herramienta interna que ahorra veinte horas al mes a tres personas, o una plataforma que soporta a diez mil usuarios y factura por suscripción. Entre esos dos extremos hay un factor 20 de diferencia en presupuesto.
Aun así, hay rangos. Después de más de diez años construyendo [software a medida](/servicios/desarrollo-software-a-medida/) para empresas como Mediapro, UNICEF o Knauf, sabemos aproximadamente dónde cae cada tipo de proyecto y, sobre todo, qué es lo que hace que un presupuesto se dispare. Esto es lo que pagas de verdad cuando pagas por software.
Rangos de precio por tipo de proyecto en España
Qué hay dentro de esos números (y qué no)
Un presupuesto serio no es solo horas de programación. En un proyecto medio, escribir código es entre el 45 % y el 60 % del esfuerzo total. El resto se reparte entre trabajo que no se ve pero que decide si el proyecto sale bien:
- Análisis y definición funcional: Convertir "queremos digitalizar el proceso de pedidos" en reglas concretas, casos límite y criterios de aceptación. Es la fase donde más dinero se ahorra o se pierde.
- Arquitectura y modelo de datos: Las decisiones que se toman aquí condicionan el coste de todo lo que venga después.
- Diseño de interfaz y experiencia de uso: Si la herramienta la van a usar personas ocho horas al día, esto no es decoración: es adopción.
- Pruebas y control de calidad: Automatizadas y manuales.
- Despliegue e infraestructura: Entornos, CI/CD, copias de seguridad, monitorización.
- Gestión del proyecto: Interlocución, seguimiento y toma de decisiones.
Lo que normalmente NO está dentro y conviene preguntar siempre: licencias de terceros, coste de la infraestructura en la nube, migración de datos históricos, formación de usuarios y el mantenimiento posterior.
Los factores que de verdad mueven el presupuesto
1. La complejidad de las reglas de negocio. No cuenta el número de pantallas, cuenta la cantidad de excepciones. Un catálogo de productos es barato. Un catálogo con precios por cliente, descuentos por volumen, tarifas por zona y tres excepciones históricas que solo conoce una persona de administración es otra cosa. Si en la reunión aparece la frase "salvo cuando", el presupuesto sube.
2. Las integraciones. Cada sistema externo que hay que conectar añade entre 3.000 y 15.000 € según su documentación y su estado. Una API moderna y documentada es un problema pequeño. Un ERP de 2009 sin API, del que hay que leer directamente la base de datos, es un proyecto dentro del proyecto.
3. La migración de datos. Casi siempre se subestima. Los datos antiguos vienen duplicados, incompletos y con criterios que cambiaron tres veces por el camino. Limpiar y migrar un histórico grande puede ser el 10 % o el 15 % del proyecto.
4. Usuarios, roles y permisos. Una herramienta con un único tipo de usuario es mucho más barata que la misma con cinco perfiles, permisos por departamento y auditoría de quién hizo qué.
5. Cumplimiento y accesibilidad. RGPD, trazabilidad, normativa sectorial o [accesibilidad WCAG](/servicios/accesibilidad-web/) cuando hay administración pública de por medio. No es opcional y añade entre un 10 % y un 20 % si se contempla desde el principio. Bastante más si se añade al final.
6. Disponibilidad y escala. Una herramienta interna para 30 personas y una plataforma que no puede caerse nunca no tienen ni la misma arquitectura ni el mismo precio.
Y un factor que baja el precio: tener claro qué se quiere. Un cliente con el proceso definido y una persona con capacidad de decidir puede ahorrar semanas de idas y venidas.
¿Quieres una cifra para tu caso concreto?
Cuéntanos el proceso que quieres resolver y te damos un rango honesto en la primera llamada. Hablas directamente con quien dirigirá tu proyecto, no con un comercial.
El coste que casi nadie te enseña: los años 2 a 5
El precio de construir el software es la parte visible. Un producto que se usa de verdad necesita presupuesto todos los años siguientes, y ahí es donde se decide si la inversión fue buena:
- Mantenimiento correctivo y actualizaciones: entre un 15 % y un 20 % anual del coste de desarrollo. Dependencias que hay que actualizar, parches de seguridad, cambios en las APIs de terceros.
- Infraestructura: de 50 a 600 € al mes en la mayoría de aplicaciones de empresa, según tráfico, datos y requisitos de disponibilidad.
- Evolutivos: lo que quieras invertir en que el producto siga mejorando. Es el que más retorno da y el primero que se recorta.
Sumado a cinco años, el mantenimiento y la evolución suelen igualar o superar el coste inicial. Por eso el criterio para elegir proveedor no debería ser quién construye más barato, sino con quién quieres estar hablando dentro de tres años. Nosotros trabajamos con [contratos de mantenimiento](/servicios/mantenimiento-evolutivo/) precisamente porque el software que no se mantiene se degrada solo.
Por qué el presupuesto más barato acaba costando más
Una parte relevante de nuestro trabajo es [rescatar proyectos](/servicios/auditoria-y-rescate/) que alguien empezó por la mitad de precio. El patrón se repite:
- El presupuesto bajo no incluye análisis, así que se construye sobre supuestos que resultan ser falsos en la semana seis.
- No hay pruebas automatizadas, así que cada cambio rompe algo en otro sitio.
- No hay documentación ni control de versiones serio, así que cambiar de equipo cuesta semanas.
- El código funciona en la demo y se cae con datos reales.
Cuando eso pasa, el cliente ha gastado el presupuesto, ha perdido entre seis meses y un año, y la reescritura cuesta más que haberlo hecho bien la primera vez porque además hay que rescatar los datos.
Esto no significa que caro sea sinónimo de bueno. Significa que si un presupuesto es la mitad que los demás, la pregunta correcta no es "por qué son tan baratos", sino "qué han quitado".
Cómo comparar dos presupuestos que parecen iguales
Cuando tengas varias ofertas encima de la mesa, compáralas con estas seis preguntas:
1. ¿Qué alcance exacto cubre? Un presupuesto sin listado de funcionalidades no es un presupuesto, es un número.
2. ¿Quién va a escribir el código? Perfil y seniority del equipo real, no del que va a la reunión.
3. ¿Incluye pruebas, despliegue y documentación? Si no aparecen, o no están, o te las cobrarán después.
4. ¿De quién es el código y dónde vive? El repositorio y la propiedad intelectual deben ser tuyos, sin discusión.
5. ¿Qué pasa con los cambios? Todo proyecto cambia. Lo importante es que el mecanismo para valorarlos esté escrito antes de empezar.
6. ¿Qué incluye el mantenimiento y cuánto cuesta? Con tiempos de respuesta y qué entra y qué no.
Si un proveedor no puede responder a las seis por escrito, ya tienes información suficiente.
Cómo bajar el coste sin romper el proyecto
Hay formas legítimas de ajustar un presupuesto y formas de hipotecar el proyecto. Las que funcionan:
- Empieza por el proceso que más duele. Un primer alcance que resuelve un problema real y se usa desde el mes tres vale más que una plataforma completa que llega en el mes doce.
- Divide en fases con valor independiente. Cada fase tiene que poder estar en producción por sí sola, no ser media aplicación.
- No construyas a medida lo que no te diferencia. Facturación, firma digital, pasarela de pago o mensajería: usa producto de mercado e intégralo. A medida solo lo que es tu ventaja competitiva.
- Reduce perfiles y pantallas antes que calidad. Menos alcance con la misma solidez es sostenible. El mismo alcance sin pruebas ni arquitectura no lo es.
Las que no funcionan: quitar la fase de análisis, saltarse las pruebas, aceptar que "la documentación ya la haremos" y elegir tecnología por lo que sabe hacer el proveedor y no por lo que necesita el proyecto.
Somos un equipo senior de desarrollo de software a medida. Escribimos sobre lo que construimos: backend, arquitectura e IA aplicada a la programación.