Cuando una empresa contrata un proyecto de desarrollo web, el entusiasmo por el diseño, la tecnología o los plazos suele eclipsar una parte crítica del acuerdo: las garantías y el SLA (Service Level Agreement o Acuerdo de Nivel de Servicio). Estas dos piezas son el “seguro de vida” del proyecto: definen qué cubre la agencia, durante cuánto tiempo, cómo se priorizan y resuelven las incidencias, qué pasa si el servicio cae y cuáles son las consecuencias económicas y operativas de un incumplimiento. Un contrato sólido de diseño web donostia (o cualquier otro lugar) y desarrollo web no es un anexo opcional; es la base que evita sorpresas, conflictos y pérdidas de negocio.

Qué es realmente una garantía (y qué no)

En un contrato de desarrollo web, la garantía es el compromiso del proveedor de corregir defectos atribuibles al trabajo entregado, durante un tiempo determinado y sin coste adicional.
No debe confundirse con:

  • Mantenimiento evolutivo (nuevas funcionalidades o mejoras).
  • Soporte (atención al usuario, preguntas de uso, incidencias no atribuibles a defectos del código).
  • Suscripciones (plugins, temas, pasarelas, APIs de terceros).
  • Incidencias externas (caídas del hosting contratado por el cliente, cambios en políticas de terceros, ataques DDoS ajenos a la responsabilidad del proveedor, etc.).

Elementos esenciales de una garantía

  • Alcance: qué se considera defecto (bugs, incompatibilidades con navegadores definidos, errores de maquetación respecto a diseños aprobados, fallos en flujos críticos como checkout o formularios).
  • Duración: período de cobertura (por ejemplo, 60–90 días desde la puesta en producción).
  • Condiciones: requisitos para que aplique (portal sin modificaciones de terceros, CMS y plugins en versión aprobada, sin accesos no autorizados, sin cambios de infraestructura).
  • Exclusiones: todo lo que queda fuera (cambios de alcance, nuevas versiones mayores del CMS, degradaciones por terceros, pérdida de datos por acciones del cliente, integraciones externas que rompen su API).
  • Procedimiento: canal de reporte, tiempos de diagnóstico y de corrección.

SLA: el contrato del “día después”

El SLA es el acuerdo operativo que detalla tiempos de respuesta y resolución, ventanas de soporte, prioridades e indicadores. Es la pieza que traduce el “te ayudamos” en métricas verificables, tanto si se trata de una web corporativa como de un ecommerce.

Qué debe incluir un SLA de calidad

  • Horario de soporte: por ejemplo, lunes a viernes 9:00–18:00 (zona horaria definida). Opcional: soporte ampliado, fines de semana o 24/7 con coste diferencial.
  • Canales: mesa de ayuda (ticketing), email, chat, teléfono de emergencias.
  • Clasificación de incidencias: severidad crítica, alta, media y baja, con ejemplos.
  • Tiempos de respuesta (SLO de respuesta): cuánto tarda el proveedor en atender el ticket.
  • Tiempos de resolución (SLO de resolución o contención): cuánto tarda en resolver o implantar workaround.
  • Métricas y reporting: cumplimiento mensual (% de tickets dentro de SLO), causas raíz (RCA), propuestas de mejora.
  • Compensaciones: descuentos o horas de bolsa si no se cumplen los SLO pactados (dentro de límites razonables).
  • Plan de escalado: a quién se escala internamente cuando una incidencia se bloquea o se retrasa.
  • Mantenimiento programado: ventanas y preavisos para actualizaciones que puedan afectar a la disponibilidad.
  • Backups y recuperación: periodicidad, retención, pruebas de restauración y RTO/RPO acordados.

Matriz de severidades y ejemplos prácticos

Una buena matriz alinea expectativas. Modelo habitual:

  • Severidad 1 (Crítica): caída total del sitio, pasarela de pago inoperativa, exposición de datos personales, imposibilidad de login masiva.
    • Respuesta: ≤ 1 hora (en horario de soporte); Resolución/contención: ≤ 4–8 horas.
  • Severidad 2 (Alta): degradación severa de rendimiento, formularios clave fallando intermitentemente, errores en el checkout de una variante, secciones clave inaccesibles.
    • Respuesta: ≤ 2 horas; Resolución/contención: ≤ 1 día hábil.
  • Severidad 3 (Media): bug visual en una página secundaria, problema con un filtro, error no bloqueante.
    • Respuesta: ≤ 1 día hábil; Resolución: ≤ 3–5 días hábiles.
  • Severidad 4 (Baja): mejoras menores, ajustes de contenido, refactor no urgente.
    • Respuesta: ≤ 2 días hábiles; Resolución: a convenir en el ciclo de mantenimiento.

Clave: la clasificación no la define unilateralmente el proveedor; debe estar objetivada por impacto en negocio y usuarios.

Garantías específicas por área del proyecto

1) Maquetación y front-end (UI/UX)

  • Conformidad con prototipos: fidelidad respecto a diseños aprobados.
  • Compatibilidad de navegadores: lista cerrada de navegadores y versiones mínimas.
  • Accesibilidad: nivel objetivo (p. ej., WCAG 2.2 AA) en los componentes acordados.
  • Rendimiento: valores objetivo de LCP, INP y CLS en páginas clave (laboratorio y campo si aplica).

2) Back-end e integraciones

  • Flujos críticos: login/registro, checkout, generación de pedidos, sincronizaciones con CRM/ERP.
  • Contratos de API: versiones soportadas, manejo de errores, límites de rate y reintentos.
  • Logs y auditoría: registro suficiente para diagnosticar problemas y hacer RCA.

3) SEO técnico y datos

  • Mapa de redirecciones (si hay migración): garantías sobre preservación de URLs clave.
  • Etiquetado: seguimiento de eventos convenidos, validación de schema y sitemaps.
  • Consentimiento: funcionamiento correcto de CMP/Consent Mode con analítica.

4) Seguridad

  • Hardening del CMS, políticas de contraseña, 2FA (si aplica).
  • Actualizaciones críticas dentro de una ventana acordada (por ejemplo, ≤ 72 h para parches críticos).
  • Copia de seguridad y restauración: RTO/RPO medibles y test de restauración semestral/anual.

Mantenimiento vs. garantía: dónde trazar la línea

Para no mezclar conceptos:

  • En garantía: bugs del entregable original, incumplimientos de especificación, discrepancias con los diseños aprobados, fallos reproducibles en entornos definidos.
  • En mantenimiento: actualizaciones de CMS y plugins, compatibilidades con nuevas versiones de navegadores/sistemas, nuevas funcionalidades o cambios de alcance, optimizaciones posteriores, degradaciones por cambios de terceros, soporte al usuario final.

Sugerencia contractual: adjuntar una tabla de límites que liste escenarios y marque si están incluidos en garantía o requieren mantenimiento.

Cláusulas clave que no deben faltar

Incluya, al menos, estas cláusulas en el contrato de desarrollo web:

  1. Definición de “defecto” y lista de exclusiones.
  2. Plazo de garantía y condiciones que la invalidan (accesos no autorizados, cambios por terceros, versiones no aprobadas).
  3. SLA de soporte con horario, canales, severidades, SLO de respuesta y resolución, plan de escalado y compensaciones.
  4. Propiedad intelectual: titularidad del código, diseño, y derecho de uso de dependencias (plugins, fuentes, imágenes).
  5. Gestión de dependencias: inventario de licencias, renovaciones y responsabilidades (quién paga, quién administra, cómo se transfieren).
  6. Backups y recuperación: periodicidad, retención, responsable, pruebas de restauración y objetivos RTO/RPO.
  7. Seguridad y cumplimiento: RGPD/LSSI, trazabilidad de tratamientos, DPA si se accede a datos personales.
  8. Mantenimiento posterior: bolsa de horas, alcance, tarifas, tiempos de atención y evolución del roadmap.
  9. Cambio de alcance: procedimiento de “change request”, estimaciones y aceptación.
  10. Terminación y salida: entrega de código y assets, traspaso de cuentas, documentación, acceso a repositorios, soporte de transición.

Ejemplos de redacción (plantillas orientativas)

Definición de defecto
“Se considerará ‘defecto’ toda desviación reproducible respecto a la especificación funcional y técnica aprobada, a los diseños validados o a los criterios de aceptación acordados, siempre que se reproduzca en los entornos soportados (Anexo X) y con los datos de prueba provistos.”

Plazo de garantía
“El Proveedor corrige sin coste los defectos reportados durante los 90 días naturales posteriores a la Puesta en Producción, siempre que el Cliente no haya realizado modificaciones en el código o configuración sin aprobación escrita del Proveedor.”

SLA – Tiempos
“Severidad 1: respuesta ≤ 1 h y contención ≤ 4 h en horario de soporte. Severidad 2: respuesta ≤ 2 h y resolución ≤ 1 día hábil. Severidad 3: respuesta ≤ 1 día hábil y resolución ≤ 5 días hábiles.”

Compensaciones
“Si el Proveedor incumple en un mes natural más del 10% de los SLO de Severidad 1 y 2 combinadas, se aplicará un descuento del 10% en la factura de mantenimiento del mes siguiente o un crédito equivalente en bolsa de horas.”

Propiedad intelectual y salida
“A la finalización, el Proveedor entregará código fuente, activos gráficos, documentación técnica y accesos a repositorios. El Cliente será titular de los derechos de explotación del código a medida desarrollado. Las licencias de terceros se regirán por sus términos.”

Qué exigir en proyectos con alto impacto (ecommerce, SaaS, portales de reserva)

Si el sitio es crítico para ingresos u operaciones:

  • Soporte ampliado o 24/7 para Severidad 1.
  • Monitoreo activo (uptime, errores, rendimiento) con alertas al equipo.
  • Entornos de staging y preproducción con datos controlados.
  • Plan de continuidad: runbooks para incidentes graves, contacto de emergencia, checklist de recuperación.
  • Pruebas de carga y seguridad (pentests o escaneos periódicos).
  • KPIs de negocio integrados (conversiones, tasa de fallo en checkout, tiempo medio de respuesta).

Relación entre SLA y precio: cómo negociar sin perder calidad

  • Transparencia de costes: atención 24/7, tiempos de respuesta bajos y equipos dedicados incrementan el coste; evita “milagros baratos”.
  • Paquetes por niveles: esencial, avanzado, premium; elige el que se alinee con el valor de negocio del sitio.
  • SLO realistas: mejor un SLO cumplible y medible que promesas imposibles.
  • Compensaciones razonables: descuentos escalonados y topes mensuales, evitando penalizaciones desproporcionadas.
  • Revisión trimestral: permite ajustar severidades, métricas y procedimientos según el histórico.

Cómo verificar el cumplimiento: métricas, auditorías y reporting

  • Uptime mensual y tiempo medio de respuesta (objetivo y real).
  • MTTA/MTTR (Mean Time To Acknowledge/Resolve) por severidad.
  • Cumplimiento de SLO (% tickets en tiempo).
  • RCA (análisis de causa raíz) de incidentes críticos con plan de prevención.
  • Backups restaurados: evidencia de pruebas de restauración (capturas, registros).
  • Actualizaciones realizadas (changelog de CMS/plugins, parches de seguridad).

Errores comunes que disparan conflictos (y cómo evitarlos)

  1. Garantías “infinitas”: suenan bien, pero son inviables y generan expectativas irreales.
  2. SLA ambiguos: sin métricas, todo es opinable.
  3. Sin matriz de severidades: cada incidencia se convierte en “urgente”.
  4. Sin inventario de terceros: cuando un plugin o API falla, nadie “es responsable”.
  5. Backups sin pruebas: el día del desastre no es momento para descubrir que no restauran.
  6. Propiedad difusa del código y las cuentas: bloqueos en la salida.
  7. Falta de documentación: cada cambio cuesta el doble y el triple de tiempo.

Antídoto: contrato claro, anexos técnicos, métricas y cultura de documentación.

Conclusión

En diseño web y desarrollo web, una interfaz brillante no compensa un contrato débil. Las garantías bien definidas y un SLA medible convierten la relación proveedor–cliente en una colaboración predecible, con expectativas alineadas y riesgos controlados. Exigir estos elementos no es desconfianza; es profesionalidad. Cuando el acuerdo recoge alcance, plazos, severidades, compensaciones, seguridad, backups, mantenimiento y salida, el proyecto deja de ser una apuesta y se convierte en un activo fiable para el negocio.