Mantenimiento y soporte de aplicaciones web a medida: lo que nadie te cuenta antes de lanzar

Un viernes a las ocho de la tarde, mientras medio equipo recoge la mochila y el otro medio ya está en el metro, alguien del departamento financiero llama al móvil del CTO porque la plataforma ha dejado de procesar facturas. No es un escenario hipotético. Es la conversación que hemos visto repetirse durante años en empresas que celebraron el lanzamiento de su aplicación como si fuera la meta y descubrieron, semanas o meses después, que en realidad era la salida.

El día que tu aplicación web a medida entra en producción no cierra el proyecto. Lo abre. Y lo abre hacia una fase que casi nadie te describe con honestidad cuando firmas el presupuesto inicial: el mantenimiento y soporte de aplicaciones web a medida. En este reportaje contamos qué tipos de soporte técnico existen, cuánto cuesta hoy mantener una aplicación web en España, qué SLA de mantenimiento conviene negociar y cómo distinguir a un proveedor serio del que desaparece justo cuando suena el teléfono.

Qué pasa cuando no mantienes una aplicación web

Empecemos por el final, que en estos casos suele ser el principio del aprendizaje. La mayoría de las empresas con las que nos hemos cruzado entendieron la importancia del mantenimiento porque les explotó algo entre las manos.

Una escena habitual: una empresa de logística con sede en Barcelona lanza un portal de seguimiento de envíos en 2022. Funciona. Los clientes lo usan. El equipo técnico pasa a otras prioridades y nadie vuelve a tocar el código en dos años. Llega 2024 y una vulnerabilidad crítica en una librería de autenticación, descubierta y publicada meses antes, termina explotada por un atacante con paciencia. Los datos de 12.000 clientes quedan al descubierto. La factura del incidente supera los 80.000 euros entre asesoría legal, notificación a la AEPD y un daño reputacional que tardará mucho más en repararse. Mantener una aplicación web hubiera costado una fracción.

Lo malo del desgaste es que casi nunca avisa. Se acumula sin hacer ruido:

• Vulnerabilidades de seguridad que aparecen cada semana en librerías y frameworks que ya tienes en producción.
• Degradación del rendimiento por acumulación de datos, fragmentación de índices y configuraciones que un día escalaban y otro no.
• Incompatibilidades con navegadores, sistemas operativos y APIs de terceros que sí se actualizan, aunque tú no.
• Deuda técnica que va encareciendo y ralentizando cualquier cambio futuro, hasta que mover una coma cuesta una semana.

Los cuatro tipos de mantenimiento que tu app necesita

La norma ISO/IEC 14764 define cuatro categorías. No es teoría académica para llenar diapositivas: es la lente que te permite mirar tu factura mensual y entender, línea por línea, qué estás pagando y por qué.

Mantenimiento correctivo

Arreglar lo que se rompe. Bugs que aparecen un martes cuando alguien intenta exportar un informe. Cálculos que dan resultados extraños en cuanto el saldo entra en negativo. Flujos que funcionan en Chrome y no en Safari. Caídas que ocurren los lunes a las nueve, cuando todo el mundo se conecta a la vez.

Es el soporte técnico más visible y el que más prisa mete. Cada empresa necesita un canal claro para reportar incidencias y un SLA que defina cuánto tarda cada nivel de gravedad en recibir respuesta.

Mantenimiento adaptativo

Adaptar la aplicación al mundo que la rodea. Sistemas operativos que se actualizan, versiones nuevas de PHP o Node.js, pasarelas de pago que cambian su API sin demasiado aviso, normativas que entran en vigor en una fecha concreta.

En España, este capítulo se ha vuelto especialmente exigente con la facturación electrónica obligatoria y las distintas oleadas del sistema Verifactu. Lo que parecía un detalle técnico se convierte en bloqueo operativo si no se ha previsto.

Mantenimiento perfectivo

Aquí no hay nada roto. Lo que hay son cosas que pueden ser mejores. Un listado que tardaba dos segundos en cargar cuando tenía 500 registros y ahora arrastra 50.000 y rasca seis. Un flujo de alta que genera tantas dudas que el equipo de soporte responde el mismo email quince veces al día. Un filtro que los usuarios llevan pidiendo desde hace meses por el chat interno.

Este es, a la larga, el mantenimiento que más empuja al negocio. Mantiene la aplicación viva y alineada con personas que usan el producto, no con el documento de requisitos firmado hace tres años.

Mantenimiento preventivo

Actualizaciones de seguridad. Pequeñas refactorizaciones para domesticar la deuda técnica. Optimización de bases de datos. Repaso de logs. Métricas que se miran antes de que el problema llegue al usuario.

Es el menos urgente. Y precisamente por eso es el primero que se sacrifica. También es el que separa a una aplicación que aguanta cinco años de la que, a los dos, alguien propone reescribir desde cero.

Cuánto cuesta el mantenimiento de una app a medida en España

Los costes bailan mucho según la complejidad de la aplicación, el nivel de servicio y el proveedor. Estos rangos orientativos sirven como brújula para el mercado español en 2026.

Modelo de bolsa de horas

El más extendido en pymes. Contratas un paquete mensual y se va consumiendo según la necesidad.

• Aplicación simple (web corporativa con panel de administración, formularios, integraciones básicas): 10-20 horas/mes, entre 600 y 1.600 euros/mes.
• Aplicación media (plataforma con usuarios, pagos, integraciones con terceros, API pública): 20-40 horas/mes, entre 1.600 y 3.500 euros/mes.
• Aplicación compleja (marketplace, SaaS multitenant, plataforma con alta concurrencia): 40-80+ horas/mes, entre 3.500 y 7.000+ euros/mes.

Modelo de tarifa fija

Menos flexible. Más previsible. El proveedor cubre un alcance definido por una cuota fija. Funciona bien cuando la aplicación está estable y los movimientos del próximo año son razonablemente predecibles.

Modelo por incidencia

Pagas solo cuando algo cruje. El precio por incidencia se mueve entre 80 y 200 euros la hora, según urgencia y franja horaria. Parece barato sobre el papel, hasta que un mes encadenas tres o cuatro avisos y la factura supera con holgura lo que habrías pagado por una bolsa cerrada.

Lo que no te dicen sobre los costes

• Las actualizaciones de seguridad del framework consumen horas aunque “no cambien nada visible” para el usuario. Existen y se cobran.
• Saltar de una versión major a otra (Laravel 10 a Laravel 11, Django 4 a Django 5) puede llevarse entre 40 y 120 horas de trabajo limpio.
• La infraestructura cloud va aparte y crece, año tras año, entre un 10 y un 20% si nadie la revisa con intención.

SLAs: qué debería incluir tu contrato de soporte

Un SLA mal definido es papel mojado el día que alguien lo necesita. Estos son los puntos que un buen contrato cubre con detalle.

Tiempos de respuesta por severidad

• Crítica (servicio caído, pérdida de datos, brecha de seguridad): respuesta en menos de 1 hora, resolución en menos de 4 horas.
• Alta (funcionalidad principal degradada, errores que afectan a muchos usuarios): respuesta en menos de 4 horas, resolución en menos de 24 horas.
• Media (errores en funcionalidades secundarias, problemas de rendimiento no críticos): respuesta en menos de 8 horas, resolución en menos de 3 días laborables.
• Baja (mejoras menores, ajustes cosméticos, consultas): respuesta en menos de 24 horas, resolución planificada en el siguiente ciclo.

Horarios de cobertura

• Horario laboral (L-V 9:00-18:00): estándar suficiente para la mayoría de aplicaciones internas.
• Horario extendido (L-V 8:00-22:00): recomendable para B2C con uso fuera de la oficina.
• 24/7: imprescindible para plataformas críticas como e-commerce, salud digital o servicios financieros. El coste se multiplica por 2,5-3x respecto al horario laboral.

Canal de comunicación y reporting

Define cómo se abre una incidencia (ticket, email, teléfono), quién la recoge primero y cómo se escala si pasan las horas sin movimiento. Y exige informes periódicos: uptime, número de incidencias, horas consumidas y estado de las actualizaciones de seguridad. Sin informes, no hay conversación seria.

Monitorización: los ojos que tu app necesita cuando tú no miras

Un buen servicio de mantenimiento incluye monitorización activa. Esperar a que un usuario escriba “la web va lenta” no es una estrategia, es un milagro.

Lo que conviene vigilar de forma continua:

• Disponibilidad: la app responde, el servidor está en pie, los servicios críticos siguen vivos.
• Rendimiento: tiempos de respuesta, queries lentas, uso de CPU y memoria.
• Errores: tasa de 500, excepciones no capturadas, fallos en integraciones externas.
• Seguridad: intentos de acceso sospechosos, certificados SSL a punto de caducar.
• Negocio: caídas inesperadas de registros, pedidos que no se completan, emails que no se envían.

Herramientas como Datadog, Grafana con Prometheus o alternativas más sencillas como UptimeRobot y Sentry cubren distintos niveles de exigencia y de presupuesto.

Cuándo refactorizar y cuándo reconstruir desde cero

Tarde o temprano, todo responsable de una app a medida se sienta a hacerse esta pregunta. La respuesta no es ideológica. Es práctica.

Refactorizar tiene sentido cuando:

• La lógica de negocio sigue siendo válida pero el código ya pesa demasiado al moverlo.
• Puedes mejorar por módulos sin bajar el servicio.
• El framework sigue teniendo soporte activo de la comunidad.
• El equipo actual conoce la tecnología y puede sostener la transición.

Reconstruir tiene sentido cuando:

• El framework ha llegado al final de su ciclo de vida y la migración cuesta más que reescribir.
• La arquitectura original no soporta los requisitos actuales (un monolito que necesita escalar a microservicios, por ejemplo).
• La deuda técnica multiplica por cinco el coste de cualquier cambio sencillo.
• No hay documentación, no hay tests y el equipo original ya no está disponible para preguntar.

Un análisis honesto de estos factores ahorra meses caminando en la dirección equivocada. Si la decisión no está clara, una auditoría técnica suele pagar su precio en pocas semanas. Para entender mejor cómo abordar el proceso desde el principio, puede ayudarte nuestro artículo sobre contratar empresa de desarrollo web a medida.

Cómo elegir proveedor de mantenimiento para tu app

No todos los proveedores juegan en la misma liga. Estos criterios filtran rápido.

Conocimiento del stack

Tu proveedor tiene que dominar exactamente las tecnologías de tu aplicación. Un equipo brillante en PHP/Laravel rara vez es la mejor opción para mantener una app en Python/Django, y viceversa. Pide proyectos concretos en tu stack y, si puedes, una llamada con quien los llevó.

Acceso al código y documentación

Exige que el código fuente sea tuyo y viva en un repositorio al que puedas entrar mañana mismo. Pide documentación técnica mínima: diagrama de arquitectura, instrucciones de despliegue, variables de entorno y dependencias externas. Si un proveedor se resiste a darte acceso al código de tu aplicación, ya tienes una respuesta.

Capacidad de respuesta real

Llama a clientes actuales y pregúntales por la última incidencia gorda. Un SLA firmado no garantiza que haya alguien al otro lado del teléfono a las siete de la tarde de un viernes cuando la pasarela de pagos deja de responder. Las referencias sí.

Proactividad vs reactividad

Un proveedor que solo apaga fuegos te dejará con la sensación permanente de ir detrás. El bueno se adelanta: propone mejoras, identifica riesgos antes de que se materialicen, actualiza dependencias en ventanas planificadas y te cuenta cómo está la aplicación sin esperar a que preguntes.

Transparencia en costes y continuidad

Sospecha de presupuestos cerrados sin desglose. Tienes que saber cuántas horas se han dedicado a cada tipo de mantenimiento y qué tareas entran en los planes de soporte que firmas. Y revisa la cláusula de salida: documentación de lo realizado, accesos transferidos y soporte real durante la transición si decides cambiar de proveedor algún día.

Tu app merece un equipo que la cuide como si fuera suya

Mantener una aplicación web a medida no es un gasto añadido. Es la póliza que protege una inversión que probablemente te ha costado decenas de miles de euros levantar. Un buen plan alarga la vida útil del producto, reduce el riesgo de incidentes graves y te deja seguir evolucionando sin tener que empezar de cero cada pocos años.

En Tangram Consulting llevamos años acompañando a equipos que llegan con la aplicación todavía caliente y a otros que aterrizan en agosto con un proveedor anterior que dejó de coger el teléfono. Diseñamos planes de mantenimiento y soporte de aplicaciones web a medida con SLAs claros, monitorización activa y personas que conocen de verdad las tecnologías con las que trabajamos. Si estás buscando a alguien que sostenga tu aplicación o quieres una auditoría honesta del estado actual, escríbenos y cuéntanos cómo está hoy tu plataforma. Te devolvemos una propuesta a medida en menos de 48 horas.