Cuánto cuesta mantener un software a medida al año

El proyecto termina, la herramienta entra en producción y durante unos meses todo va bien. La factura del desarrollo está pagada y, en la cabeza de casi todo el mundo, el gasto se acabó ahí.

Luego llega el año dos. Un proveedor cambia su API y dejan de entrar los pedidos. La versión del lenguaje que corre en el servidor deja de recibir parches de seguridad. Google avisa de que la app tiene que actualizarse para seguir apareciendo en la tienda. Y quien usa la herramienta a diario acumula una lista de doce cosas pequeñas que le harían el día más fácil.

Nada de eso es una avería. Es el coste normal de tener software en producción y se puede presupuestar antes de que aparezca. La respuesta corta a cuánto cuesta mantener un software a medida es entre el 15 % y el 20 % del coste de desarrollo cada año, más la infraestructura. Lo interesante es de qué está hecho ese porcentaje, y cuándo puedes quedarte en la parte baja de la horquilla.

Los números, para tu tamaño de proyecto

Aplicando esa regla a los rangos de desarrollo que manejamos en cuánto cuesta un software a medida, la cuenta anual queda así:

Tipo de proyecto	Desarrollo inicial	Mantenimiento al año
Herramienta interna acotada	15.000 – 30.000 €	2.500 – 6.000 €
Aplicación de gestión completa	35.000 – 90.000 €	5.000 – 18.000 €
App móvil con backend propio	30.000 – 80.000 €	5.000 – 16.000 €
Plataforma SaaS con clientes de pago	50.000 – 150.000 €	8.000 – 30.000 €

A eso se le suma la infraestructura, que va aparte y se paga a terceros: servidores, base de datos, dominios, certificados, copias de seguridad y correo transaccional. Para una aplicación de empresa media suele moverse entre 40 y 250 € al mes.

Si hay app móvil, hay dos cuotas más: el Apple Developer Program cuesta 99 dólares al año y la cuenta de Google Play, 25 dólares una sola vez. Son cantidades pequeñas, pero la de Apple caduca, y una cuenta caducada saca la app de la tienda.

Un matiz importante sobre la tabla: el porcentaje no es una tarifa, es un presupuesto. Hay años en los que se gasta menos y años —el de un cambio grande de plataforma— en los que se gasta más. Lo que no hay son años a cero.

De qué está hecha esa cifra

El mantenimiento tiene cuatro partidas y conviene distinguirlas, porque se contratan y se recortan de forma distinta.

Lo que se cae. Errores, incidencias, cosas que dejan de funcionar. Es la partida más visible y, en un software bien construido, la más pequeña. Si es la mayor, el problema no es el mantenimiento: es el desarrollo que hubo debajo.

Lo que caduca. Actualizaciones de seguridad, versiones de lenguaje y de base de datos que llegan a su fin de soporte, dependencias con vulnerabilidades publicadas. Nadie las pide y llegan igual.

Lo que cambia fuera. Tu pasarela de pagos retira una versión de su API, tu ERP actualiza el formato de exportación, la Agencia Tributaria modifica un requisito de facturación. Tu aplicación no ha tocado una línea y ha dejado de funcionar.

Lo que se mejora. Los ajustes que pide quien usa la herramienta todos los días. Esta es la partida que más se recorta y la que más rentabilidad da, porque es la única que hace que la herramienta se parezca cada año un poco más a como trabajáis.

Lo que caduca no es una opinión, tiene fecha

Esta partida sorprende porque parece opcional y no lo es. Un par de ejemplos con fecha en el calendario, a día de hoy:

Node.js 20 dejó de recibir parches en abril de 2026, y Node.js 22 los dejará de recibir en abril de 2027. En PHP, todo lo anterior a 8.2 está ya fuera de soporte, y la propia 8.2 termina el 31 de diciembre de 2026. Que tu aplicación siga arrancando sobre una versión sin soporte no significa que esté bien: significa que la próxima vulnerabilidad que se publique no se va a arreglar.

Con las apps es todavía más literal. Desde el 31 de agosto de 2026, Google Play exige que las apps nuevas y las actualizaciones apunten a Android 16, y que las que ya están publicadas apunten como mínimo a Android 15 para seguir llegando a usuarios con móviles más modernos. Una app que nadie actualiza no se queda igual: se va quedando invisible. Es una de las razones por las que en desarrollo de aplicaciones móviles el mantenimiento no es un extra opcional.

Ninguno de esos cambios aporta nada nuevo a quien usa la herramienta. Es trabajo que se hace para seguir donde ya estabas, y por eso duele pagarlo. También es el más barato de todo el mantenimiento si se hace a su ritmo, y uno de los más caros si se deja para cuando ya no queda alternativa.

Qué pasa si decides no pagarlo

El mantenimiento se puede posponer. Lo que no se puede es evitar; solo cambia de forma y de precio.

Las actualizaciones se acumulan y dejan de ser actualizaciones. Saltar de una versión a la siguiente es medio día de trabajo. Saltar cinco versiones de golpe, con las dependencias rotas por el camino, es un proyecto de varias semanas. El coste no crece de forma lineal: crece a saltos, y el salto llega justo cuando una vulnerabilidad grave te obliga a actualizar con prisa.

Las integraciones se rompen en silencio. Cuando un servicio externo retira una versión de su API, casi nunca falla con un aviso claro. Lo normal es que dejen de sincronizarse unos cuantos registros y que alguien lo descubra tres semanas después, cuadrando cifras que no cuadran.

La herramienta se va separando de la operativa. Los procesos de tu empresa cambian todos los años. Un software que no se toca los refleja cada vez peor, y el equipo empieza a hacer lo de siempre: una hoja de cálculo al lado para el caso que la aplicación no cubre. Cuando hay tres de esas hojas, has vuelto al punto de partida y encima pagando el desarrollo.

Quien lo construyó deja de tener el contexto en la cabeza. Una aplicación que se toca cada mes tiene a alguien que la conoce. Una que no se toca en dos años necesita que alguien vuelva a leerla entera antes de cambiar nada, y ese tiempo se factura.

Un ejemplo de un año normal

Para que no quede en abstracto, cómo se reparte un año de mantenimiento en un proyecto de tamaño medio —pongamos la plataforma de gestión de un centro de formación, con matrículas, grupos, profesores y pagos.

Trimestre uno. Actualización de dependencias y del sistema del servidor, más un par de errores que aparecen al terminar el primer curso completo: un informe que no cuadraba con alumnos dados de baja a mitad de trimestre. Poco trabajo, todo previsible.

Trimestre dos. La pasarela de pagos anuncia que retira la versión de su API en cuatro meses. Se adapta la integración y se aprovecha para registrar mejor los recibos devueltos, que hasta ahora se revisaban a mano.

Trimestre tres. El grueso de los evolutivos. Administración pide poder emitir los certificados en lote en lugar de uno a uno, y coordinación quiere ver el hueco de aulas libres por sede. Son dos semanas de trabajo que ahorran varias horas cada semana durante el resto del año.

Trimestre cuatro. Preparar la matriculación del curso siguiente: revisar rendimiento antes del pico de septiembre, comprobar que la copia de seguridad se restaura de verdad —comprobarlo es distinto de tenerla— y dejar cerrado el histórico del curso anterior.

El reparto típico se parece a esto: alrededor de la mitad del presupuesto anual se va en mejoras, un tercio en actualizaciones y adaptaciones a cambios de terceros, y el resto en incidencias. Si en tu caso las incidencias se comen la mitad, hay algo que revisar antes de firmar otro año igual.

Qué mirar en un contrato de mantenimiento

Los contratos de mantenimiento se parecen mucho en el titular y muy poco en la letra. Estas son las cláusulas que miramos cuando nos toca revisar el de otro.

Qué entra y qué se factura aparte. La frontera habitual está entre corregir lo que no funciona como se acordó —que debería entrar— y construir algo que no existía —que es un proyecto. Si el contrato no dibuja esa línea, la va a dibujar cada mes una conversación incómoda.

Cuántas horas de mejora incluye. Un contrato solo correctivo sale barato el primer año y caro el tercero, porque la herramienta se congela mientras la empresa sigue moviéndose. Nosotros reservamos horas de evolutivo cada mes por defecto, y no por generosidad: es lo que evita el rediseño completo dentro de tres años.

Qué tiempos de respuesta hay, y para qué. Un único plazo para todo no sirve. Una caída del servicio y una petición de un informe nuevo no pueden compartir prioridad. Lo razonable son niveles distintos, escritos, con lo que se considera crítico definido antes de que ocurra.

Cómo se justifica el trabajo. Un total mensual de horas no es un informe. Tareas, tiempo y el cambio concreto asociado, sí. Enseñarlo no le cuesta nada a quien trabaja bien.

Quién tiene las llaves. Los accesos al servidor, al dominio, al repositorio y a las cuentas de las tiendas deberían estar a nombre de tu empresa, con tu proveedor invitado. Si están a nombre de él, no tienes un contrato de mantenimiento: tienes una dependencia. Es el mismo criterio que aplicamos al elegir el modelo de contratación en presupuesto cerrado o bolsa de horas.

Cuándo no te hace falta un contrato

No todo software necesita mantenimiento contratado, y decir lo contrario sería vender.

Si la herramienta es interna, no está expuesta a internet, no se integra con nada de fuera y hace un trabajo que no va a cambiar —una calculadora de un proceso concreto, un panel que lee datos y no escribe—, puede vivir años con revisiones puntuales de seguridad y poco más. Ahí lo sensato es una bolsa de horas pequeña que se usa cuando hace falta, no una cuota mensual.

El contrato empieza a compensar cuando se cumple alguna de estas tres: la aplicación está expuesta a internet, se integra con sistemas de terceros que cambian por su cuenta, o hay gente que depende de ella para trabajar cada día y una caída les para. Con dos de las tres, no contratarlo es una decisión de riesgo, no de ahorro.

En resumen

Presupuesta entre el 15 % y el 20 % del desarrollo al año, más la infraestructura, y decide con ese número delante en lugar de descubrirlo en el mes catorce. Un software a medida es una herramienta de trabajo, y como cualquier otra tiene un coste de uso que no aparece en el precio de compra.

Si ya tienes una aplicación en producción y no sabes en qué estado está —quién la mantiene, qué versiones corre, si las copias de seguridad se restauran—, escríbenos y la miramos. Recogemos también proyectos hechos por otros, y ahí el primer paso siempre es una auditoría antes de comprometer plazos, como contamos en mantenimiento y soporte. Sale de ahí un informe con lo urgente, lo importante y lo que puede esperar, aunque después decidas hacerlo por tu cuenta.