En síntesis: Una aplicación necesita mantenimiento del código y de su entorno. El costo depende de criticidad, integraciones, infraestructura y cobertura; no existe un porcentaje anual universal.
Una aplicación requiere administrar su entorno, actualizar componentes, respaldar, monitorear y atender errores. El presupuesto depende del alcance y la criticidad, no de un porcentaje anual universal.
Por qué se rompen los sistemas que "funcionaban bien"
Una falla puede originarse en código, dependencias, infraestructura o servicios externos. Certificados, capacidad y versiones de API también requieren responsables.
Las cinco cosas que hay que tener cubiertas
1. Infraestructura administrada
El servidor (propio, en un datacenter o en la nube) tiene que tener alguien responsable de recursos, sistema operativo, red y seguridad. No es lo mismo que "el hosting": es la administración.
2. Actualizaciones de seguridad
Sistema operativo, base de datos, lenguaje y librerías de la aplicación. Cada año aparecen vulnerabilidades en componentes que todos usan. Un sistema sin actualizar desde su entrega es un sistema expuesto.
3. Backups probados
Base de datos y archivos, con copias fuera del servidor, y una prueba de restauración cada tanto. Un backup que nunca se restauró es una hipótesis.
4. Monitoreo con alertas
Disponibilidad, tiempos de respuesta, errores en los registros, espacio en disco, vencimiento de certificados. La diferencia entre enterarse por una alerta a las 7 de la mañana o por un cliente a las 11.
5. Corrección y evolución
Errores que aparecen con el uso, ajustes chicos, cambios normativos (una modificación en facturación electrónica, por ejemplo). Un contrato de mantenimiento suele incluir una cantidad de horas mensuales para esto, con tiempos de respuesta acordados.
El problema de los dos proveedores
Un escenario muy común: una empresa desarrolla el sistema y otra administra el servidor. Cuando algo falla, cada una dice que es culpa de la otra, y el cliente queda en el medio. Nuestra posición, basada en la operación de infraestructura, es que quien construye el sistema tiene que hacerse cargo de dónde corre, o al menos trabajar con un único responsable de las dos cosas.
Qué preguntar antes de contratar un desarrollo
- ¿Dónde va a correr el sistema y quién administra ese servidor?
- ¿Qué incluye el mantenimiento mensual y cuáles son los tiempos de respuesta?
- ¿Cómo se hacen y se prueban los backups?
- ¿Qué pasa si quiero cambiar de proveedor? ¿Me llevo el código, los datos y la documentación?
- ¿Cuánto cuesta el segundo año, no solo el primero?
Cómo lo hacemos nosotros
Cada desarrollo se entrega con un plan de mantenimiento mensual que cubre los cinco puntos anteriores, sobre infraestructura que administramos nosotros o la del cliente. La entrega del código específico y los datos se define por contrato, respetando licencias de terceros. Es la misma lógica con la que operamos los sistemas propios que tenemos en producción: se sostienen porque alguien los mira todos los días.
Aplicación práctica: qué comprobar
Escenario ilustrativo, no un caso de éxito documentado. El sistema responde, pero una integración dejó de registrar pagos. Monitorear sólo la página de inicio no detecta el problema. Definí comprobaciones del proceso completo y una reconciliación que identifique operaciones pendientes.
Evidencia que conviene registrar
- Inventario de componentes, certificados e integraciones.
- Backups, alertas y pruebas del flujo de negocio.
- Responsables de cambios, incidentes y evolución.
