---
title: "Cuánto cuesta mantener un software a medida"
description: "Cuánto cuesta el mantenimiento de un software a medida: de qué depende, referencias publicadas con fuente, bolsa de horas o cuota y cómo comparar ofertas."
canonical: https://caricalia.com/notas/cuanto-cuesta-mantenimiento-software
last-updated: 2026-10-09
---

# Cuánto cuesta mantener un software a medida

> El mantenimiento no tiene un precio de mercado, pero sí se sabe qué lo mueve. Estas son las referencias publicadas, con su fuente y su límite, y cómo comparar ofertas.

Publicado: 2026-10-09

Autor: carlos

Temas: mantenimiento, precio, presupuesto

---

## Cuánto cuesta el mantenimiento de un software a medida

No hay un precio de mercado para mantener un software a medida. La referencia
que más circula es de entre el 15 % y el 25 % al año de lo que costó
construirlo, y la publica una agencia, no un estudio independiente. Lo que de
verdad mueve la cifra es el tamaño del sistema, si por él pasa dinero, el tiempo
de respuesta que necesitas y el estado en que lo heredas. El alojamiento y las
licencias se pagan aparte.

Esta nota explica de qué depende el coste, qué referencias hay publicadas y con
qué fuente, y cómo pedir presupuestos que se puedan comparar. Es la pregunta que
más nos hacen al hablar de [mantenimiento de software](/mantenimiento-de-software).

## Qué incluye el mantenimiento y qué no

Antes de comparar precios hay que comparar lo mismo. Bajo «mantenimiento» se
venden cosas muy distintas.

| Suele incluir | Suele ir aparte |
|---|---|
| Corregir errores del sistema que ya existe | Funcionalidades nuevas o módulos enteros |
| Actualizar el lenguaje, el framework y las librerías | El alojamiento, los dominios y las licencias de terceros |
| Parches de seguridad | Migrar a otra plataforma |
| Vigilar que el sistema está en marcha y actuar si cae | Rediseñar pantallas |
| Cambios pequeños que pide el negocio | Formación de personal nuevo |
| Adaptar el sistema cuando un servicio externo cambia | Auditorías externas |

La frontera entre «cambio pequeño» y «proyecto» es donde más discusiones hay.
Conviene que el contrato la fije con un criterio que se pueda medir, por
ejemplo un número de horas por cambio.

Hay una parte del trabajo que casi nadie presupuesta: entender el sistema.
Robert Glass, en *Facts and Fallacies of Software Engineering*, estima que
comprender el producto existente se lleva en torno al 30 % del tiempo de
mantenimiento, según la [reseña de Yevgeniy Brikman](https://www.ybrikman.com/blog/2017/03/30/facts-and-fallacies-of-software-engineering/)
que cita sus hechos literales. En un sistema sin documentación, ese porcentaje
sube.

## De qué depende el coste

Casi nunca del número de pantallas. Estas son las cinco cosas que miramos al
calcularlo, por orden de peso.

**Si por el sistema pasa dinero.** Cobros, facturación, conciliación, nóminas.
Un error ahí no se arregla mañana: hay que saber qué pasó, a quién afectó y
cómo se deshace. Eso pide más pruebas y más cuidado en cada cambio.

**El tiempo de respuesta que necesitas.** Que alguien mire un fallo grave en una
hora, también en fin de semana, cuesta bastante más que mirarlo al día
siguiente laborable. Es la palanca más clara del precio. Conviene decidirla
según lo que cuesta una hora del sistema parado, no por costumbre.

**El estado en que lo heredas.** Un sistema con pruebas automáticas, versiones
al día y documentación se mantiene con pocas horas al mes. Uno con versiones
caducadas obliga a ponerse al día primero, y eso es un proyecto aparte. Lo
contamos en [software en una versión sin soporte](/notas/aplicacion-version-sin-soporte).

**Las dependencias de terceros.** Cada servicio externo con el que habla el
sistema, como pasarelas de pago, correo, mapas o la administración, cambia a su
ritmo. Cada cambio obliga a adaptar algo, lo pidas o no.

**Cuánto se mueve tu negocio.** Si cada mes cambian precios, tarifas o reglas,
habrá más cambios pequeños. Si el sistema hace lo mismo desde hace años, casi
todo el trabajo será actualizar y vigilar.

## Qué referencias de precio hay publicadas

No existe una estadística oficial del coste de mantenimiento de software en
España. Lo que hay son estimaciones de proveedores y algún dato de directorios.
Se citan con su límite al lado.

| Referencia | Qué dice | Qué no dice |
|---|---|---|
| [Calculadora de coste de software a medida de Techsy](https://techsy.io/es/recursos/herramientas/calculadora-coste-software-medida) (agencia española) | El mantenimiento anual ronda entre el 15 % y el 25 % del coste original de construcción | Es una regla propia de la agencia, sin datos de proyectos publicados |
| [Benchmark de Wavect](https://wavect.io/es/blog/software-maintenance-cost-benchmark-dach-saas/) (consultora, 24 productos en Alemania, Austria y Suiza, actualizado el 2 de septiembre de 2026) | Mediana anual del 24 %, el 21 % y el 26 % del coste de construcción en los años uno, dos y tres. Propone entre el 18 % y el 30 % para un producto que sigue evolucionando, del 10 % al 16 % para una herramienta interna estable y del 35 % al 60 % para uno regulado o con muchas integraciones | Ellos mismos lo llaman orientativo y no representativo. No publican los datos para comprobarlo, y no es mercado español |
| [Clutch, precios de desarrollo de software](https://clutch.co/developers/pricing) (actualizado el 21 de septiembre de 2026) | Para proveedores de España, tarifas de entre 25 y 49 dólares por hora | Son tarifas declaradas por las empresas del listado. No dicen cuántas horas hacen falta |
| Robert Glass, *Facts and Fallacies of Software Engineering* (2002), hecho 41, citado en la [reseña de Brikman](https://www.ybrikman.com/blog/2017/03/30/facts-and-fallacies-of-software-engineering/) | El mantenimiento consume entre el 40 % y el 80 % del coste total de un software a lo largo de su vida, un 60 % de media | Es una cifra de hace más de veinte años, sobre todo el ciclo de vida. No sirve para calcular una cuota mensual |

Leídas juntas, las dos primeras apuntan a lo mismo: un sistema que sigue vivo
cuesta cada año una parte apreciable de lo que costó hacerlo. La de Glass dice
otra cosa útil: a lo largo de la vida de un software, se gasta más en
mantenerlo que en construirlo.

Ninguna sirve como presupuesto. Un sistema con cobros y diez integraciones y
una herramienta interna que usan tres personas no se parecen. Y si no sabes lo
que costó construir tu sistema, que es lo normal cuando lo heredas, el
porcentaje no se puede aplicar.

## Bolsa de horas, cuota fija o por incidencia

Hay tres formas habituales de contratar el mantenimiento. Ninguna es mejor en
abstracto: depende de cuánto se mueve tu sistema y de cuánto te cuesta tenerlo
parado.

| Modelo | Cómo funciona | A favor | En contra |
|---|---|---|---|
| Por incidencia | Pagas cada vez que algo falla o pides un cambio | No pagas nada si no pasa nada | Nadie vigila el sistema entre incidencias. Las versiones caducan sin que nadie lo vea |
| Bolsa de horas | Compras un número de horas que se van gastando | Pagas lo que usas y ves en qué se ha ido cada hora | Si la bolsa se acaba a mitad de mes, el trabajo se para. Nadie tiene incentivo para trabajar menos horas |
| Cuota mensual fija | Pagas lo mismo cada mes por un alcance escrito | Coste previsible. Quien mantiene tiene interés en que el sistema falle poco | Exige definir bien qué entra y qué no. Si se define mal, acaba en discusiones |

Nuestra recomendación para un sistema del que depende la empresa es la cuota
fija. Debe incluir actualizaciones y vigilancia dentro, y separar con claridad
los cambios grandes, que se presupuestan aparte. El pago por incidencia solo
sirve para sistemas que pueden pararse un día sin que nadie lo note.

Sea cual sea el modelo, el contrato tiene que decir cuánto se tarda en responder
según la gravedad (cómo se fija, en
[tiempos de respuesta del soporte](/notas/tiempos-de-respuesta-soporte-software)), a nombre de quién están el código y las cuentas, y qué pasa
si un día cambias de proveedor. Lo que hay que pedir en ese último caso está en
[cambiar de proveedor de software](/notas/cambiar-de-proveedor-de-software). Las
cláusulas, una a una, en el
[contrato de mantenimiento de software](/notas/contrato-mantenimiento-software).

## Qué encarece y qué abarata

| Encarece | Abarata |
|---|---|
| Por el sistema pasa dinero o datos sujetos a normativa | Es una herramienta interna que puede pararse un día |
| Hace falta respuesta en horas, también fuera de horario | Basta con mirarlo el siguiente día laborable |
| Versiones del lenguaje o del framework sin soporte | Todo está en versiones con soporte |
| No hay pruebas automáticas ni documentación | Las reglas de negocio están escritas como pruebas |
| Muchas integraciones con servicios de terceros | El sistema vive casi entero dentro de tu base de datos |
| Nadie del equipo original sigue disponible | Quien lo escribió puede contestar dudas durante el traspaso |

La fila de las versiones se puede cambiar. Ponerse al día es un gasto puntual
que baja la cuota de los años siguientes.

## Cómo pedir presupuestos que se puedan comparar

Dos ofertas de mantenimiento casi nunca incluyen lo mismo. Para compararlas,
manda a cada proveedor el mismo documento con esto:

1. **Qué es el sistema.** Qué hace, cuánta gente lo usa y si por él pasa dinero.
2. **Con qué está hecho.** Lenguaje, framework, base de datos y versiones. Si no
   lo sabes, dilo: es lo primero que tendrán que averiguar.
3. **Con qué habla.** La lista de servicios externos.
4. **El tiempo de respuesta que necesitas**, separado por gravedad: sistema
   caído, algo importante falla y una molestia.
5. **Cuántos cambios pequeños esperas al mes**, aunque sea a ojo.
6. **Qué tiene que pasar si un día terminas el contrato.**

Y pide que cada oferta conteste por escrito tres cosas. Qué queda fuera. Cuánto
cuesta el primer mes, que suele ser más caro porque hay que entender el sistema.
Y qué pasa con las horas que no se usan.

Si el sistema lo heredas sin documentación, ningún proveedor podrá darte una
cifra honesta sin leerlo antes. En ese caso, lo razonable es pagar primero una
revisión con el código delante y pedir los presupuestos después, con el alcance
ya escrito. Es lo que hacemos en el [diagnóstico](/diagnostico).

## Preguntas frecuentes

### ¿Cuánto cuesta al mes mantener una aplicación?

No hay una cifra que valga para todas. Las referencias publicadas sitúan el
coste anual entre el 15 % y el 30 % de lo que costó construirla, pero son
estimaciones de proveedores. Depende sobre todo de si pasa dinero por ella y del
tiempo de respuesta que necesites.

### ¿El alojamiento entra en el mantenimiento?

Normalmente no. El alojamiento, los dominios y las licencias de terceros se
pagan aparte, al proveedor de cada uno. Lo que sí suele entrar es vigilar que el
servidor está al día y actuar cuando cae.

### ¿Es mejor una bolsa de horas o una cuota fija?

Para un sistema del que depende la empresa, la cuota fija: el coste es
previsible y quien mantiene tiene interés en que falle poco. La bolsa de horas
encaja cuando los cambios son irregulares y el sistema puede esperar.

### ¿Por qué el primer mes cuesta más?

Porque antes de mantener un sistema hay que entenderlo: ponerlo en marcha,
revisar versiones y averiguar qué hace cada parte. En un sistema heredado sin
documentación es la parte más larga.

### ¿Se puede bajar el coste del mantenimiento?

Sí, y casi siempre con lo mismo. Poner las versiones al día, escribir pruebas de
lo que mueve dinero y documentar lo que solo sabía una persona. Es un gasto
puntual que reduce el trabajo de cada mes siguiente.

Si quieres saber cuánto costaría mantener tu sistema, en el
[diagnóstico](/diagnostico) lo leemos y te damos el alcance por escrito.