Presupuesto de mantenimiento web: qué revisar antes de contratar

Cuando una empresa pide o recibe un presupuesto de mantenimiento web, la cifra mensual suele ocupar casi toda la conversación. Sin embargo, el dato decisivo no es cuánto cuesta aislado, sino qué responsabilidad técnica compra esa cuota y dónde termina.

Dos propuestas con un precio parecido pueden cubrir realidades muy distintas. Una puede limitarse a ejecutar tareas programadas; otra puede incluir revisión técnica, criterio antes de intervenir, seguimiento de puntos críticos y atención de determinadas incidencias. También puede ocurrir lo contrario: una propuesta más extensa sobre el papel puede apoyarse en etiquetas genéricas que no aclaran qué se hará realmente.

Por eso, antes de contratar un servicio de mantenimiento web, conviene convertir cada propuesta en respuestas concretas: qué sistema se mantiene, qué se revisa de forma recurrente, quién responde ante cada tipo de problema, qué queda fuera y cómo se trata el trabajo que va más allá del mantenimiento.

Esta guía no es una lista de tarifas. Si buscas específicamente los factores que explican el precio de mantener una web WordPress, ese análisis tiene su propia guía. Aquí el objetivo es otro: ayudarte a comparar propuestas comerciales sin confundir cuota, alcance y responsabilidad.

No compares propuestas solo por la cuota mensual

La comparación útil empieza cuando se separan cinco dimensiones:

• Alcance: qué capas, tareas y recorridos de la web están cubiertos.
• Responsabilidad: quién ejecuta, supervisa, decide y responde en cada capa.
• Criticidad: qué impacto tiene un fallo sobre ventas, captación u operaciones.
• Exclusiones: qué problemas o intervenciones no forman parte de la recurrencia.
• Modelo de intervención: cómo se revisa, se prioriza y se actúa cuando aparece una necesidad.

Una cuota baja no es necesariamente insuficiente para una web sencilla. Una cuota alta tampoco demuestra por sí sola que exista más control. Lo que permite valorar el coste de mantenimiento web es la correspondencia entre la complejidad real del proyecto y las obligaciones escritas en la propuesta.

Por ejemplo, dos documentos pueden incluir «actualizaciones, seguridad y copias». En uno, actualizar puede significar activar automatizaciones y comprobar que la portada carga. En otro, puede implicar revisar compatibilidad, preparar una copia, aplicar el cambio con criterio y validar después formularios o procesos relevantes. Las etiquetas coinciden; la responsabilidad asumida, no.

El punto de partida es el tipo de web

Una propuesta razonable debería identificar primero qué está manteniendo. El tipo de proyecto condiciona las revisiones, los riesgos y las competencias necesarias.

Web corporativa

En una web informativa suelen ser importantes la disponibilidad, los formularios, el contenido, la seguridad y el rendimiento. Si su función principal es captar oportunidades, un formulario que deja de entregar leads puede ser más grave que un pequeño defecto visual. La propuesta debería reconocer esa prioridad.

WordPress

WordPress añade un ecosistema de núcleo, tema, plugins y versiones del entorno que evolucionan por separado. No basta con indicar que se harán actualizaciones: debe entenderse cómo se revisan y qué elementos funcionales se comprueban después. Cuando esta es la tecnología central del proyecto, tiene sentido evaluar el alcance específico de un mantenimiento WordPress.

WooCommerce o ecommerce

Una tienda incorpora carrito, checkout, pagos, pedidos, stock, emails transaccionales y, a menudo, conexiones externas. Que la web esté disponible no garantiza que pueda vender. Una propuesta de mantenimiento WooCommerce debería reconocer los recorridos comerciales críticos y no tratar la tienda como una web corporativa con más páginas.

Desarrollo a medida o aplicación web

En una solución propia importan el código, las dependencias, la base de datos, los despliegues, los logs, la lógica de negocio y el conocimiento de la arquitectura. Aplicar el mismo paquete que a un CMS estándar puede dejar fuera precisamente las piezas que sostienen el funcionamiento del sistema.

Webs conectadas con otros sistemas

Cuando existen CRM, ERP, APIs, pasarelas, herramientas de marketing o sincronizaciones de pedidos y stock, la web ya no funciona de forma aislada. La propuesta debe indicar qué conexiones entran en el perímetro y hasta dónde llega el diagnóstico o soporte cuando el fallo procede de un tercero.

El propósito de esta clasificación no es crear un catálogo de servicios. Sirve para comprobar si el proveedor ha entendido el proyecto antes de definir una cuota.

Qué trabajo recurrente se realiza de verdad

Una buena propuesta describe acciones y criterios, no solo categorías amplias. Expresiones como «seguridad», «rendimiento» o «monitorización» necesitan contexto para poder compararse.

Conviene que el documento aclare, según la tecnología:

• Qué revisiones técnicas se realizan y sobre qué componentes.
• Cómo se valoran y aplican las actualizaciones cuando existen.
• Qué controles de seguridad y accesos forman parte del seguimiento.
• Cómo se gestionan o supervisan las copias y la capacidad de recuperación.
• Qué aspectos de rendimiento se observan y en qué zonas de la web.
• Qué disponibilidad, errores o procesos se monitorizan o supervisan.
• Qué comprobaciones de compatibilidad o funcionamiento acompañan a los cambios.

La profundidad debe ser proporcional al proyecto. No todas las webs necesitan el mismo ritual, pero la empresa sí debería poder entender qué ocurrirá de forma recurrente, qué señales se observarán y qué resultado se espera de cada tarea.

También es útil que la propuesta explique la cadencia como un modelo operativo, sin reducirla a una promesa artificial de hacer exactamente lo mismo cada mes. Algunas revisiones son periódicas; otras dependen de que exista una actualización relevante, una alerta o un cambio en el proyecto.

Cómo se atienden las incidencias

«Soporte incluido» es demasiado ambiguo para decidir. La propuesta debería distinguir, al menos, entre una incidencia menor relacionada con el entorno mantenido, un trabajo correctivo significativo y un problema que ya existía antes de empezar.

Una incidencia menor puede ser un error acotado cuya revisión y resolución encajan en la operativa habitual. En cambio, una caída con causa desconocida, una infección, un conflicto profundo, una recuperación compleja o un fallo estructural pueden exigir diagnóstico e intervención propios.

Lo relevante es que el criterio esté escrito:

• Qué tipo de incidencias puede atenderse dentro del mantenimiento recurrente.
• Cómo se recibe, clasifica y sigue una incidencia.
• En qué momento deja de ser una actuación ordinaria.
• Qué ocurre cuando hace falta investigar antes de poder estimar la solución.
• Cómo se comunica y presupuesta el trabajo que queda fuera.

Esto evita dos expectativas incompatibles: que la empresa interprete la cuota como cobertura de cualquier problema y que el proveedor considere cualquier incidencia un trabajo adicional.

Pequeños cambios no son lo mismo que desarrollo evolutivo

El mantenimiento puede admitir pequeños ajustes cuando encajan en el alcance acordado. Por ejemplo, corregir una configuración menor, adaptar un detalle técnico o resolver un comportamiento acotado. Pero esa posibilidad no convierte la cuota en una bolsa indefinida de desarrollo.

Normalmente requieren valoración separada:

• Una funcionalidad nueva.
• Un cambio estructural de diseño o de arquitectura.
• Una modificación relevante de la lógica de aplicación o de negocio.
• Una integración nueva o una ampliación sustancial de una existente.
• Un desarrollo que necesite análisis, pruebas y despliegue propios.

La frontera no depende solo del tiempo que parece llevar el cambio. Una modificación breve puede afectar a pagos, permisos o datos críticos y necesitar más control que otra visualmente mayor. Una buena propuesta explica cómo se decide qué es ajuste menor y qué se convierte en trabajo evolutivo.

Backups, hosting e infraestructura: asignar cada responsabilidad

Mantenimiento y hosting no son automáticamente el mismo servicio. El hosting aporta el entorno donde vive la web; el mantenimiento puede ocuparse de la aplicación, de parte de su operación o de ambas capas si así se ha acordado.

Antes de contratar, debería quedar claro:

• Quién configura, genera y conserva las copias.
• Quién supervisa que se estén ejecutando y qué información puede recuperar cada una.
• Quién tiene acceso al proveedor, servidor, panel, DNS, logs y otros recursos necesarios.
• Quién monitoriza la disponibilidad y los recursos de infraestructura.
• Quién modifica configuraciones del entorno y coordina incidencias con el proveedor de hosting.

Cuando Projectia gestiona la infraestructura, puede gestionar esa capa directamente. Si el alojamiento pertenece a otro proveedor, los backups y la monitorización pueden supervisarse o configurarse una vez facilitados los accesos necesarios. Esa dependencia de acceso y autoridad debe constar en la propuesta: nadie puede asumir una responsabilidad operativa sobre una capa que no puede ver ni administrar.

En proyectos WordPress donde se quiere unificar servidor, SSL, copias y soporte de la capa de alojamiento, conviene revisar por separado qué aporta un hosting WordPress gestionado. La comparación será más clara si hosting, mantenimiento de la aplicación y desarrollo aparecen delimitados, aunque los coordine un mismo equipo.

Qué ocurre si la web ya tiene problemas

El inicio de un mantenimiento no borra la deuda técnica ni convierte en recurrente cualquier reparación pendiente. Si una web llega con errores, componentes obsoletos, accesos incompletos o una arquitectura difícil de diagnosticar, el proveedor necesita conocer ese punto de partida.

Un proceso de incorporación razonable puede incluir:

1. Una revisión inicial del estado, la tecnología, las dependencias y los puntos críticos.
2. La identificación de fallos previos, riesgos y deuda técnica que condicionen el servicio.
3. Una fase de diagnóstico, estabilización o trabajo correctivo cuando sea necesaria.
4. La transición al mantenimiento recurrente cuando exista una base suficientemente controlada.

La propuesta debería indicar si esa revisión forma parte del alta, qué profundidad tiene y cómo se tratarán los hallazgos. Para un WordPress con síntomas dispersos o sin una visión técnica fiable, una auditoría técnica puede ser el paso adecuado antes de definir la rutina. Lo importante es no asumir que todo problema preexistente queda incluido automáticamente en la primera cuota.

Integraciones críticas y procesos de negocio

Una web puede seguir cargando mientras deja de enviar formularios al CRM, sincronizar stock con el ERP o confirmar pagos. Por eso el inventario técnico de una propuesta debe incluir también los procesos conectados que realmente importan al negocio.

Conviene identificar, cuando existan:

• Formularios, leads y su entrega al equipo o al CRM.
• Pasarelas de pago y estados transaccionales.
• APIs consumidas o expuestas por la aplicación.
• Sincronizaciones de productos, stock, pedidos o clientes.
• Conexiones con ERP, logística, reservas, email u otras plataformas.
• Tareas programadas, colas y mecanismos de reintento asociados.

No es necesario incluir todos los sistemas externos por defecto. Sí es necesario escribir cuáles se monitorizan, cuáles se comprueban, hasta dónde llega el soporte y quién coordina una incidencia que cruza varios proveedores. Si estas conexiones sostienen la operación, el alcance puede necesitar una revisión específica de integraciones técnicas.

Qué debería dejar explícito una buena propuesta

Esta tabla permite convertir términos comerciales amplios en puntos comparables:

Si una fila no puede responderse después de leer el documento, todavía falta concretar el alcance o formular una pregunta antes de comparar.

Señales de una propuesta demasiado genérica

Una propuesta breve puede ser suficiente si el proyecto es sencillo y las responsabilidades están bien definidas. El problema no es la extensión, sino la falta de relación con la web que se va a mantener.

Conviene pedir más detalle cuando aparece alguna de estas señales:

• El paquete es idéntico para una web corporativa, una tienda y una aplicación a medida.
• Nadie ha preguntado qué hace la web, de qué tecnología depende o qué procesos son críticos.
• «Seguridad, backups y actualizaciones» aparecen sin acciones ni responsables definidos.
• Hosting, mantenimiento y desarrollo se mezclan sin fronteras operativas.
• No existe tratamiento para errores o deuda técnica anteriores al contrato.
• No se distingue entre pequeñas intervenciones y evolución funcional.

Una señal aislada no demuestra que el servicio sea inadecuado. Sirve para localizar preguntas pendientes antes de firmar, cuando todavía es fácil alinear expectativas.

Cuándo puede tener sentido pagar más

Un presupuesto puede aumentar porque el proveedor asume más superficie técnica, más comprobaciones o mayor responsabilidad operativa. Eso suele ser razonable cuando la web es crítica para captar negocio, procesa ventas, incorpora lógica propia o depende de varias integraciones.

También influyen el número de capas que hay que coordinar, la dificultad para probar procesos relevantes, la complejidad del despliegue y el impacto que tendría una incidencia. Una tienda con pagos y stock conectado al ERP exige un modelo distinto al de una web corporativa sin dependencias externas.

Pagar más no garantiza por sí solo un mejor servicio. La diferencia solo está justificada si se puede vincular a necesidades reales y obligaciones claras. Del mismo modo, una propuesta más contenida puede ser perfectamente adecuada cuando el proyecto es simple, el riesgo es bajo y las exclusiones son transparentes.

Checklist antes de aceptar un presupuesto de mantenimiento web

Antes de contratar, comprueba que puedes responder con claridad a estas preguntas:

• ¿La propuesta describe la tecnología, el tipo de web y sus funciones críticas?
• ¿Sé qué revisiones y tareas se realizan de forma recurrente?
• ¿Entiendo cómo se valoran, aplican y comprueban las actualizaciones?
• ¿Está definido qué incidencias entran y cuáles se presupuestan aparte?
• ¿Se diferencia un pequeño ajuste de una evolución o funcionalidad nueva?
• ¿Sé quién gestiona o supervisa las copias y quién podría restaurarlas?
• ¿Hosting, aplicación, infraestructura y desarrollo tienen responsables claros?
• ¿La propuesta identifica formularios, pagos, APIs e integraciones que deben seguir funcionando?
• ¿Está explicado qué acceso necesita el proveedor para asumir cada tarea?
• ¿Existe un proceso para revisar problemas previos y estabilizar la web si hace falta?
• ¿Las exclusiones son comprensibles y coherentes con la cuota?
• ¿El coste se explica por el alcance y la criticidad, no solo por una lista de etiquetas?

La mejor propuesta es la que reduce las zonas grises

Evaluar un presupuesto de mantenimiento web no consiste en elegir el documento con más tareas ni la cuota más alta. Consiste en comprobar si tecnología, criticidad, alcance, accesos y responsabilidades forman un conjunto coherente.

Cuando esas fronteras están claras, la empresa sabe qué esperar de la recurrencia, cómo se tratará una incidencia y cuándo una necesidad debe convertirse en un trabajo independiente. El proveedor, a su vez, puede mantener con criterio sin asumir obligaciones indefinidas ni descubrir dependencias críticas demasiado tarde.

Si estás comparando propuestas o todavía necesitas definir qué debería cubrir la tuya, el siguiente paso es revisar la web actual y sus conexiones. A partir de ahí se puede plantear un alcance de mantenimiento proporcional a la tecnología, la criticidad y la responsabilidad operativa que realmente necesita el proyecto.