Planes de mantenimiento de SaaS: qué incluir y cómo comparar proveedores

Lanzar un producto SaaS o una aplicación web es el comienzo del trabajo, no el final. Las bibliotecas reciben parches de seguridad, las integraciones cambian sus API, los certificados caducan, las bases de datos crecen y los clientes encuentran caminos que nadie probó. Alguien tiene que vigilar el sistema y cuidarlo.

Muchos fundadores contratan a un proveedor de mantenimiento sin tener una idea clara de lo que están comprando. El resultado es un plan que suena tranquilizador y acaba cubriendo muy poco. Esta guía explica qué incluye un plan razonable, cómo comparar proveedores según lo que realmente importa y qué preguntas hacer antes de firmar.

Qué cubre realmente el mantenimiento de software

El mantenimiento es más que corregir errores. Los ingenieros suelen describir varios tipos de trabajo: correctivo (arreglar defectos), adaptativo (mantenerse al día con entornos cambiantes), perfectivo (mejorar el rendimiento y la usabilidad), preventivo (detectar problemas a tiempo) y trabajo de seguridad. Nuestra visión general de los tipos de mantenimiento de software explica cada uno.

Un buen plan convierte esas categorías en actividades específicas y repetibles, con un responsable claro y un informe mensual.

Qué debería incluir un buen plan

• Monitorización de disponibilidad y errores. Comprobaciones automáticas y seguimiento de errores, con alertas que lleguen a una persona designada y una regla que defina qué se considera un incidente.
• Verificación de copias de seguridad y pruebas de restauración. Confirmación de que las copias de seguridad se ejecutan, además de una prueba programada de que realmente pueden restaurarse.
• Parches de seguridad y actualización de dependencias. Actualizaciones seleccionadas, aplicadas y probadas en un entorno de staging antes de su publicación, en lugar de actualizar a ciegas.
• Investigación y corrección de errores dentro de una bolsa mensual acordada de horas de ingeniería.
• Revisión de lo que falla en silencio: webhooks de pago, tareas programadas, entrega de correo electrónico y conexiones con API de terceros.
• Lanzamientos controlados. Cambios aprobados y desplegados mediante un proceso repetible, con notas de versión.
• Un informe mensual que recoja el trabajo realizado, los incidentes, el tiempo utilizado, los riesgos pendientes y los siguientes pasos recomendados.

Las seis cosas que definir antes de contratar

1. Cobertura. Qué aplicaciones y entornos (producción, staging) están incluidos, y quiénes son sus contactos designados en ambas partes.
2. Horario de soporte y zona horaria. "24/7" y "horario laboral en su zona horaria" son productos muy distintos con precios muy distintos.
3. Niveles de severidad y objetivos de respuesta. Qué se considera crítico y con qué rapidez el proveedor acusa recibo de cada nivel.
4. La bolsa mensual de ingeniería. Cuántas horas se incluyen, si las horas no utilizadas caducan o se acumulan, y qué ocurre cuando se superan.
5. Responsabilidades sobre copias de seguridad y aprobaciones. Quién es responsable de las copias de seguridad y las pruebas de restauración, y qué cambios requieren su visto bueno.
6. Condiciones comerciales. Cuota mensual, fecha de facturación, plazo mínimo si lo hay y cómo cancelar.

El tiempo de respuesta no es el tiempo de resolución

Esta es la línea que más se malinterpreta en cualquier plan. Un objetivo de respuesta suele significar que el proveedor acusa recibo de su aviso y empieza a investigar dentro de un plazo determinado. No significa que el problema esté resuelto para entonces. Algunos problemas se resuelven en minutos y otros tardan días, según la causa.

Pregunte qué hace el proveedor después de la primera respuesta: con qué frecuencia le informa, quién escala el caso y qué ocurre si la solución requiere trabajo que excede su bolsa de horas. Desconfíe de cualquier proveedor que prometa tiempos de resolución garantizados sin conocer su sistema.

Comparación de los modelos de precios más habituales

Ninguno de ellos es el mejor en todos los casos. Elija el que se ajuste a cuánto le costaría realmente el tiempo de inactividad.

Señales de alerta al comparar proveedores

• Un precio sin alcance por escrito, o un alcance que solo dice "mantenimiento y soporte".
• Ninguna mención a staging, pruebas o notas de versión.
• Promesas de soluciones instantáneas o de "cero tiempo de inactividad" sin ningún detalle.
• Proveedores que quieren control exclusivo de sus cuentas, alojamiento o código.
• Ausencia de condiciones de traspaso si cancela.
• Alojamiento, suscripciones de software y costos de uso de IA incluidos en el paquete sin desglosar.

Diez preguntas que hacer antes de firmar

1. ¿Qué se monitoriza exactamente y quién recibe las alertas?
2. ¿Cómo prueban las actualizaciones antes de que lleguen a producción?
3. ¿Cuándo probaron por última vez la restauración de una copia de seguridad y cuánto tardó?
4. ¿Qué se considera un incidente y cuáles son sus objetivos de respuesta según la severidad?
5. ¿Qué incluyen las horas mensuales y qué no?
6. ¿Qué ocurre con las horas no utilizadas?
7. ¿Quién es el propietario del código, del alojamiento y de las cuentas de terceros?
8. ¿Qué acceso necesitan y cómo se limita y se retira?
9. ¿Qué contendrá el informe mensual? ¿Puedo ver un ejemplo?
10. ¿Qué ocurre con la documentación y los accesos cuando terminemos el acuerdo?

Propiedad y continuidad

Usted debe conservar la propiedad y el control administrativo de su código, sus cuentas y su infraestructura. El proveedor debe recibir acceso por rol, con los permisos mínimos necesarios. Si la relación termina, el traspaso debe incluir la documentación actualizada, el estado del trabajo pendiente y la retirada de los accesos del proveedor. Si un proveedor se resiste a cualquiera de estos puntos, considérelo una señal de advertencia.

Cuándo empezar y cuándo corregir primero

El mantenimiento funciona mejor en una aplicación que ha sido revisada. Un buen proveedor comienza con una revisión de incorporación de la arquitectura, el proceso de despliegue, los accesos y la deuda técnica conocida, de modo que el plan refleje la realidad. Si esa revisión detecta problemas graves ya existentes, como datos expuestos o una facturación defectuosa, lo habitual es abordarlos primero en un proyecto aparte. Nuestra auditoría técnica de apps con IA y nuestro servicio de reparación y lanzamiento a producción de apps con IA están pensados para esa etapa, y nuestra lista de verificación de lanzamiento muestra qué comprobar.

Una vez que la aplicación es estable, el mantenimiento mensual de SaaS la mantiene así, con un alcance definido, una bolsa mensual de horas de ingeniería y un informe que puede leer en cinco minutos.