Mantenimiento de software a medida: qué incluye y cómo contratarlo

Mantenimiento de software a medida: la respuesta corta

El mantenimiento de software a medida es el trabajo continuo que mantiene una aplicación funcionando, segura y útil después de la entrega: corregir errores, aplicar actualizaciones de seguridad, adaptarla cuando cambia algo a su alrededor (el servidor, un programa con el que se conecta, una ley, un modelo de IA) y mejorarla cuando cambia tu negocio. Aunque nadie toque tu código, el entorno cambia, y una aplicación sin mantenimiento se degrada poco a poco hasta que un día falla.

Un buen contrato de mantenimiento deja por escrito qué tipos de mantenimiento cubre, en cuánto tiempo se responde según la gravedad, cómo se hacen y se prueban las copias de seguridad, quién paga servidores y servicios de terceros, cuántas horas de mejoras incluye y, sobre todo, qué no incluye. Y tan importante como el contrato es que el código, la documentación y los accesos estén a tu nombre, para que puedas cambiar de proveedor si algún día lo necesitas.

Tipos de mantenimiento: correctivo, adaptativo, evolutivo y preventivo

Se suelen distinguir cuatro tipos. Conviene conocerlos porque un contrato puede cubrir unos y excluir otros, y ahí nacen la mayoría de malentendidos.

Tipo	Qué es	Ejemplo
Correctivo	Arreglar algo que no funciona como debería	El PDF del presupuesto descuadra el total cuando hay un descuento por línea
Adaptativo	Ajustar la aplicación a cambios de su entorno, sin añadir funciones	Tu tienda online cambia su API; el proveedor de IA retira el modelo que usabas; una norma exige otro formato
Evolutivo (o perfectivo)	Añadir funciones o mejorar las que hay porque cambia tu negocio	Un informe nuevo, un tipo de usuario más, conectar con otro programa
Preventivo	Adelantarse a los problemas antes de que den la cara	Actualizar librerías, vigilar el espacio en disco, revisar los registros de errores, probar a restaurar una copia

El correctivo y el preventivo mantienen la aplicación viva; el adaptativo evita que el mundo la deje atrás; el evolutivo hace que siga siendo útil. Un ejemplo de evolutivo que conocemos bien: nuestro propio CRM es software a medida, y cuando necesitamos reflejar cuotas mensuales en los presupuestos o que el precio de cada proyecto saliera solo de su presupuesto, lo añadimos en horas, sin esperar a que un fabricante lo incluyera en sus planes.

Garantía no es mantenimiento

La garantía cubre, durante un periodo pactado, los errores de lo que se entregó: si algo no funciona como se acordó, se corrige sin coste. No cubre que cambie la API de tu tienda online, que caduque un certificado ni que quieras un informe nuevo. Eso es mantenimiento, igual que cualquier corrección una vez acabada la garantía.

Qué debe incluir un contrato de mantenimiento de software

Da igual que se pague como cuota mensual, bolsa de horas o por petición: estos son los puntos que el contrato debería dejar claros.

Tiempos de respuesta según la gravedad

No todas las incidencias son iguales, y el contrato debería clasificarlas, por ejemplo así:

• Crítica: la aplicación no funciona o hay riesgo para los datos. Nadie puede trabajar.
• Alta: falla una función importante, pero hay forma de seguir trabajando.
• Normal: un error menor o una molestia.

Para cada nivel, pide dos plazos: el de respuesta (cuándo alguien empieza a trabajar en ello) y el de resolución o solución provisional, además del horario cubierto y el canal para avisar. Los plazos dependen de lo crítica que sea la aplicación; lo importante es que estén escritos.

Copias de seguridad y restauración

Qué se copia (base de datos, archivos subidos, configuración), cada cuánto, cuánto tiempo se conservan y dónde: al menos una copia fuera del servidor principal y, mejor, fuera del mismo proveedor de alojamiento. Incluye pruebas de restauración periódicas y una estimación de cuánto se tardaría en volver a funcionar tras un desastre. Si la aplicación trata datos personales, no es un extra: el artículo 32 del RGPD incluye entre las medidas de seguridad «la capacidad de restaurar la disponibilidad y el acceso a los datos personales de forma rápida en caso de incidente físico o técnico», y un proceso para verificar con regularidad que esas medidas funcionan.

Actualizaciones de seguridad

Sistema operativo del servidor, lenguaje, framework y librerías: quién las aplica, cada cuánto y cómo se prueban antes de pasarlas a la versión real. Pregunta también qué se hace cuando se publica una vulnerabilidad grave en alguna pieza que usa tu aplicación, porque ese parche no puede esperar a la revisión trimestral.

Servidores, dominio y vigilancia

Quién contrata el alojamiento y a nombre de quién, quién renueva el dominio y los certificados y si hay monitorización: avisos automáticos cuando la aplicación cae, se llena el disco o una tarea programada deja de ejecutarse.

Horas de evolución e informes

Si la cuota incluye horas para mejoras, el contrato debe decir cuántas al mes, si se acumulan o se pierden, cómo se piden y aprueban los trabajos y a qué precio va la hora adicional. Pide un informe periódico de lo que se ha hecho: sin él, no sabes qué estás pagando.

Protección de datos

Si quien mantiene la aplicación puede acceder a datos personales de tus clientes o empleados, actúa como encargado del tratamiento y el artículo 28 del RGPD exige un contrato que lo regule. El artículo 33 le obliga además a avisarte «sin dilación indebida» de cualquier brecha de seguridad, porque tú, como responsable, debes notificarla a la autoridad de control, si es posible, en un máximo de 72 horas desde que la conoces, salvo que sea improbable que suponga un riesgo para las personas. Que el contrato diga cómo y a quién se avisa.

Qué no incluye y cómo se sale

Es la parte más útil del contrato. Suelen quedar fuera, o presupuestarse aparte, las funciones nuevas que superan las horas pactadas, los rediseños, las migraciones grandes, la formación de personal nuevo, los errores causados por terceros que tocan el sistema sin coordinarse y los costes de servicios externos. Y conviene pactar desde el principio la salida: al terminar, entrega del código actualizado, la documentación, las credenciales y una copia de los datos, con un periodo de transición para el nuevo equipo.

Costes que influyen en el mantenimiento de una aplicación

Qué gastos aparecen después de la entrega (mantenimiento, servidores, APIs de IA, licencias, adaptaciones normativas) ya lo repasamos en cuánto cuesta una aplicación a medida. Aquí vamos un paso más allá: qué hace que suban o bajen y por qué algunos llegan aunque nadie pida cambios.

Disponibilidad exigida

No cuesta lo mismo mantener una herramienta interna que puede estar parada una hora un domingo que un portal de clientes que no puede caerse. Más disponibilidad significa más vigilancia, redundancia y, a veces, guardias fuera de horario.

Dominios y certificados

El dominio se renueva cada año, y uno caducado te deja sin web y sin correo. Los certificados de la conexión segura (el candado del navegador) caducan cada vez antes: el CA/Browser Forum, que fija las reglas del sector, aprobó reducir su validez máxima de 398 a 47 días de forma escalonada entre marzo de 2026 y marzo de 2029. Con esos plazos, la renovación tiene que ser automática y vigilada.

APIs de inteligencia artificial: los modelos se retiran

Si tu aplicación usa IA, además del coste por uso hay otro que casi nadie presupuesta: los modelos se retiran. Anthropic explica en su página de retiradas de modelos que las peticiones a un modelo retirado fallan, y se compromete a avisar con al menos 60 días de antelación en los modelos públicos. Claude Sonnet 4, de mayo de 2025, se declaró obsoleto el 14 de abril de 2026 y se retiró el 15 de junio de 2026. OpenAI publica también su calendario de retiradas.

Migrar no es solo cambiar el nombre del modelo en la configuración: el nuevo responde de forma distinta, así que hay que repetir las pruebas con casos reales, ajustar las instrucciones y revisar el coste, que también cambia. Es mantenimiento adaptativo, y el contrato debería decir si está incluido.

Librerías y versiones con fecha de caducidad

Todo software se apoya en un lenguaje, un framework y decenas de librerías, cada una con su ciclo de vida. Node.js, por ejemplo, indica que sus versiones LTS reciben correcciones críticas durante unos 30 meses y recomienda usar en producción solo versiones con soporte. Actualizar con regularidad cuesta poco; saltar varias versiones de golpe tras años sin tocar nada puede convertirse en un proyecto.

Cambios normativos y servicios de terceros

Una norma nueva puede obligarte a cambiar tu software, como la adaptación a Verifactu de los programas que emiten facturas: es mantenimiento adaptativo, a veces grande, que rara vez cabe en una cuota básica. Lo mismo ocurre con cada servicio externo (correo automático, firma electrónica, pasarela de pago): tiene su tarifa y su API, y las dos pueden cambiar.

Cómo se construyó

Es el factor que más pesa a largo plazo: un software con pruebas automáticas, código ordenado y documentación se mantiene con menos horas que uno hecho deprisa. Lo que se ahorra en calidad al desarrollar se paga después, cada mes.

Cómo no quedarte atado a tu proveedor (y qué pasa si desaparece)

La pregunta incómoda que conviene hacerse antes de firmar: si mañana tu proveedor cierra, ¿podría otro equipo seguir manteniendo tu aplicación? Depende de lo que tengas en tus manos:

• El código fuente, en un repositorio de tu empresa (por ejemplo, una organización de GitHub o GitLab a tu nombre) en el que el proveedor trabaja como invitado, y la cesión de derechos por escrito. Si solo recibes un archivo comprimido al final del proyecto, ya vas tarde.
• Documentación que permita a otro equipo arrancar: cómo se instala y se publica, cómo está organizado, qué servicios externos usa, dónde están las copias y cómo se restauran.
• Tecnología estándar y extendida, que conozcan muchos profesionales. Desconfía de plataformas propias del proveedor o de herramientas cerradas de las que no se puede sacar la lógica.
• Accesos a tu nombre: dominio, servidor o cuenta en la nube, cuentas de APIs (IA, correo, pagos), contratados y facturados a tu empresa. El proveedor entra con usuarios propios que puedes retirar.
• Tus datos, exportables en un formato legible sin depender de nadie.

Una prueba sencilla: pide que alguien que no haya participado en el proyecto instale la aplicación desde cero siguiendo solo la documentación. Si lo consigue, estás cubierto. Y si el software es crítico y su código no es tuyo, como ocurre con un producto licenciado, existe el depósito del código fuente ante un tercero, que lo entrega si el proveedor desaparece.

¿Y si ya ha desaparecido? Primero, asegura lo que no puede perderse: el dominio, el acceso al servidor y una copia de los datos. Después, busca un equipo que revise el código y el servidor antes de comprometerse con cambios. Con código, documentación y accesos, retomarlo es cuestión de estudio; sin ellos, a veces compensa más rehacer. Para elegir a quién encargarlo, te ayudará nuestra guía sobre cómo elegir una empresa de desarrollo de software.

Señales de que un software está mal mantenido

• Te enteras de los fallos por tus clientes o por tu equipo, nunca por una alerta.
• Nadie sabe decirte cuándo se hizo la última copia ni si se ha restaurado alguna vez.
• El navegador ha avisado de que tu aplicación «no es segura» porque caducó el certificado.
• Nadie sabe qué versiones usa ni cuándo se actualizó por última vez, o la respuesta es «funciona, mejor no tocarlo».
• Cada cambio pequeño rompe otra cosa, y los plazos para cambios sencillos no paran de crecer.
• Solo una persona sabe cómo funciona y no hay nada escrito.
• Tú no tienes acceso ni al servidor, ni al dominio, ni al código.
• Pagas una cuota cada mes sin recibir detalle de lo que se ha hecho.
• Las integraciones fallan en silencio y descubres los datos a medias días después.

Si te reconoces en varias, no es motivo de pánico, pero sí de pedir una revisión: el estado de las copias, las versiones y los accesos se comprueba rápido, y es mejor descubrirlo ahora que el día de un incidente.

Checklist antes de firmar un contrato de mantenimiento

1. Qué tipos de mantenimiento cubre la cuota y cuáles se presupuestan aparte.
2. Niveles de gravedad, con plazos de respuesta y de resolución, horario y canal.
3. Copias: frecuencia, ubicación, conservación y pruebas de restauración.
4. Quién aplica las actualizaciones de seguridad y cada cuánto.
5. Servidor, dominio, certificados y cuentas de servicios, a nombre de tu empresa.
6. Horas de evolución: cuántas, si se acumulan y precio de la hora adicional.
7. Qué pasa cuando se retira un modelo de IA o cambia una norma.
8. Contrato de encargado del tratamiento si hay datos personales.
9. Informe periódico de lo hecho y lista de lo que no incluye.
10. Código en tu repositorio, documentación al día y condiciones de salida.

En nuestros proyectos de desarrollo de aplicaciones a medida trabajamos con tecnología estándar y muy extendida, precisamente para que tu aplicación no dependa de nada exótico, y el mantenimiento se contrata aparte, como una cuota mensual con el alcance por escrito. Exígenos lo mismo que a cualquier otro proveedor: esta lista te sirve para compararnos. Y si ya tienes una aplicación y no sabes en qué estado está, cuéntanoslo y vemos por dónde empezar.