Hay una pregunta que casi nadie hace en la primera reunión y que decide cómo serán los tres años siguientes: ¿quién mantiene esto cuando esté funcionando? Se firma, se desarrolla, se entrega, el equipo empieza a usarlo… y un día Apple cambia un requisito de la App Store, el banco cambia el formato de un fichero o el jefe de almacén necesita un campo nuevo. Entonces importa mucho quién tiene el código, quién sabe cómo está construido y en qué condiciones te va a atender.
Este artículo explica qué es realmente el mantenimiento de software a medida, por qué un programa necesita atención aunque «ya funcione», qué opciones tienes cuando te entregan el proyecto y qué preguntar antes de firmar.
Qué incluye el mantenimiento de un software a medida
«Mantenimiento» se usa como una palabra única, pero dentro hay cuatro trabajos que se pagan y se planifican de forma distinta. Confundirlos es la causa más habitual de discusiones: uno creía que estaba incluido y el otro, que era un desarrollo nuevo.
| Tipo | Qué es | Cuándo aparece |
|---|---|---|
| Correctivo | Arreglar algo que no hace lo que se acordó que haría. | En las primeras semanas de uso real, con datos que nadie había previsto. |
| Adaptativo | Ajustarlo a un cambio de fuera: una API de un tercero, un formato bancario, una norma fiscal, una versión nueva de iOS o Android. | Sin avisar y sin que hayas pedido nada. Es el que más sorprende. |
| Evolutivo | Funciones nuevas: otro informe, otro rol, otro flujo que antes se hacía a mano. | Cuando el equipo lo usa de verdad y empieza a pedir cosas. Es buena señal. |
| Preventivo | Actualizar dependencias, parchear seguridad, revisar copias y rendimiento antes de que reviente. | Periódicamente. Es el primero que se abandona si nadie lo tiene asignado. |
Los dos primeros son obligaciones; los dos últimos, decisiones. Un presupuesto honesto distingue cuál es cuál por escrito, porque «mantenimiento incluido», sin especificar de qué tipo, no significa nada.
Por qué un programa necesita mantenimiento aunque no lo toques
Existe la idea de que un software terminado es como una máquina: si funciona y no la fuerzas, aguanta. No es así: no por mala calidad del código, sino porque el suelo sobre el que se apoya se mueve solo.
- Las plataformas caducan. Apple y Google obligan a recompilar las apps con versiones nuevas de su sistema cada cierto tiempo. Una app que nadie toca dos años puede acabar retirada de la tienda sin haber cambiado una línea.
- Las integraciones cambian de lado. Si tu programa habla con una pasarela de pago, un transportista o tu contabilidad, el día que ellos cambian su API el que se rompe eres tú.
- La ley se mueve. Todo lo que emita facturas, guarde datos personales o declare impuestos vive pegado a normativa que cambia, como se nota en los programas de facturación.
- Los datos crecen. Una consulta instantánea con 2.000 registros puede tardar con 400.000. El código es el mismo; el volumen no.
- Las dependencias acumulan vulnerabilidades. Un proyecto web se apoya en librerías de terceros que publican parches de seguridad; ignorarlos años es la vía más silenciosa a un incidente.
El mantenimiento, por tanto, no es la factura de un trabajo mal hecho: es el coste de que tu herramienta siga viva. Por eso entra en la conversación cuando alguien pregunta cuánto cuesta un software a medida.
Las tres opciones cuando te entregan el proyecto
Si el código es tuyo —y debería serlo—, tienes tres caminos, y ninguno es el bueno siempre.
1. Que lo mantenga quien lo desarrolló. Lo más rápido y barato en horas: ya conoce las decisiones, los entornos y por qué algo está hecho de una forma aparentemente rara. El riesgo es la dependencia, y se neutraliza con una sola cosa: que el código y la documentación estén en tu poder desde la entrega, no «disponibles si los pides».
2. Llevarlo con equipo interno. Tiene sentido cuando el software es el núcleo del negocio y ya hay perfiles técnicos dentro. Exige más de lo que parece: alguien debe entender la arquitectura, mantener los entornos y priorizar. Aquí encaja un CTO as a Service o un desarrollador freelance integrado en tu equipo sin montar una plantilla completa.
3. Cambiar de proveedor. Posible si te entregaron el proyecto en condiciones. Un equipo nuevo necesita unas semanas para hacerse con el código, y ese coste existe; lo que no debería existir es la imposibilidad de hacerlo. Si nadie puede retomar tu software porque no hay repositorio, ni documentación, ni accesos a tu nombre, no tienes un proveedor: tienes un candado.
Qué preguntar antes de firmar
Se responden en dos minutos y ahorran años de problemas. Hazlas mientras decides, no cuando ya hay una incidencia:
- ¿A nombre de quién está todo? Repositorio, servidores, dominio, cuentas de App Store y Google Play, servicios de terceros: de tu empresa, no del proveedor.
- ¿Qué es un bug y qué es una mejora? Por escrito: es la frontera donde nacen casi todas las discusiones.
- ¿En cuánto tiempo respondéis a algo que impide trabajar? Y qué se considera «impide trabajar».
- ¿El mantenimiento es obligatorio para poder usar el programa? Si la respuesta es sí, eso no es mantenimiento: es una licencia.
- ¿Qué me entregáis si mañana lo llevo a otro sitio? La buena respuesta es concreta: código, documentación, despliegue y configuración.
En cómo pedir presupuesto de software está el resto de la conversación previa.
La señal de alarma: cuando el mantenimiento es una cuota disfrazada
Hay una diferencia enorme entre pagar por atención y pagar por permiso. Un plan legítimo cubre trabajo: correctivo, actualizaciones, seguridad, mejoras acordadas. Si dejas de pagarlo, el software sigue funcionando y tú te quedas sin servicio.
Una cuota disfrazada es otra cosa: si dejas de pagarla, el programa se apaga. Se llame «mantenimiento», «soporte» o «hosting gestionado», si el uso depende del pago lo que has comprado es un alquiler con un desarrollo a medida por delante: la dinámica que describimos al comparar software a medida frente a SaaS, solo que disimulada.
Cómo lo planteamos en FastIA
Nuestra posición no depende de la buena voluntad de nadie: el código es 100% de tu empresa y se entrega con la documentación necesaria para que otro equipo pueda retomarlo. Cada proyecto incluye 30 días de soporte tras la entrega, justo la ventana en la que aparece el correctivo real, el que solo sale cuando el software se enfrenta a los datos y a las manos de verdad.
A partir de ahí, un plan de mantenimiento y evolución es opcional: conserva el conocimiento del proyecto, pero es tu decisión, no una condición para seguir usando tu propio programa. Si prefieres llevarlo dentro, te ayudamos con el traspaso. Puedes ver el resto de nuestros servicios de desarrollo o cómo trabajamos el software a medida.
Preguntas frecuentes
¿Cuánto cuesta el mantenimiento de un software a medida?
Depende de qué cubra y de lo crítico que sea el sistema: un programa interno para cinco personas y una plataforma que atiende clientes a todas horas no necesitan lo mismo. Lo que sí debe quedar claro es el modelo: qué incluye, qué queda fuera y qué pasa si un mes no hay incidencias. Te lo damos cerrado por escrito y sin cuotas obligatorias para usar el programa.
¿Podéis mantener un software que desarrolló otra empresa?
Sí. Revisamos el estado real del proyecto —código, entornos, dependencias, copias de seguridad— y te decimos con franqueza qué se puede estabilizar y qué conviene rehacer. A veces mantenerlo cuesta más que reescribir una parte; preferimos decirlo antes que descubrirlo a mitad.
Si no contrato mantenimiento, ¿pierdo el software?
No. El código y los accesos son tuyos, así que el programa sigue funcionando igual. Lo que no tienes es a alguien de guardia cuando cambie una API o salga una versión de Android. Es una decisión de riesgo, no una trampa contractual.
¿El mantenimiento incluye funciones nuevas?
Solo si se acuerda así. Lo habitual es separar el correctivo y las actualizaciones (previsibles, de coste estable) de las funciones nuevas, que se presupuestan aparte porque su tamaño no se puede estimar de antemano. Mezclarlo en una cuota única suena cómodo y acaba saliendo caro para alguien.
El mantenimiento no es la letra pequeña de un proyecto: es la mitad de su vida útil. Decidirlo al principio —quién lo hace, qué incluye y de quién es el código— separa una herramienta que crece con tu empresa de una congelada en la versión del día de la entrega. Si quieres ver cómo quedaría en tu caso, cuéntanos qué necesitas: respondemos con presupuesto cerrado, plazos y condiciones de soporte por escrito, sin compromiso.