Respuesta breve
El «Soporte técnico continuo» cuesta $290/mo, funciona por ciclos mensuales y se detiene avisando con 30 días. Qué incluye, por qué el volumen se acuerda al inicio de cada ciclo y en qué se diferencian las actualizaciones de seguridad de las funciones nuevas.
Qué es el soporte web y por qué se paga cada mes
El soporte web es el trabajo sobre un producto que ya está funcionando: actualizaciones, comprobaciones, reparaciones cuando algo se rompe y ajustes menores por el camino. En VITON13 se llama «Soporte técnico continuo» y cuesta $290/mo. Se organiza como un ciclo mensual y se interrumpe avisando con 30 días de antelación.
El formato mensual se explica por el origen del trabajo. Los navegadores publican versiones nuevas, las librerías cierran vulnerabilidades, las pasarelas de pago y los servicios de correo cambian sus interfaces. Nada de eso sigue el calendario de su proyecto: llega según la agenda de terceros y exige una respuesta en ese momento.
Pagar por incidencia encaja mal con esa realidad. Cada vez que algo se rompiera habría que negociar otra vez un presupuesto, esperar un hueco libre y volver a explicar el contexto del proyecto a quien lo recogiera. Un ciclo mensual elimina ese bucle de negociación y deja solamente el trabajo.
Conviene trazar una línea desde el principio. El soporte continuo no incluye una construcción nueva ni un rediseño, y eso se presupuesta por separado. La condición protege el presupuesto y también el calendario, porque un trabajo grande necesita su propia planificación y no las horas que le sobren a un ciclo de mantenimiento.
Qué incluye el «Soporte técnico continuo»
El alcance declarado es breve y conviene retenerlo entero: actualizaciones prioritarias, un ritmo semanal de publicaciones y mantenimiento técnico. Son tres puntos concretos, no una promesa difusa de ocuparse de todo lo relacionado con el sitio. Conocer los límites resulta aquí más útil que la longitud de la lista.
Las actualizaciones prioritarias significan que sus tareas entran en la cola sin una nueva ronda de aprobaciones. Cuando una dependencia resulta vulnerable o una integración deja de responder, el trabajo empieza dentro del ciclo vigente y no después de firmar otro acuerdo con el proveedor.
El ritmo semanal de publicaciones hace previsible la entrega. Los cambios se agrupan, se comprueban y se despliegan con regularidad, en lugar de acumularse durante meses hasta una actualización grande y arriesgada. Para el propietario significa que un cambio llega al sitio dentro de un plazo que puede nombrar de antemano.
El mantenimiento técnico es la parte que nadie ve en pantalla: actualizar paquetes, revisar las compilaciones, vigilar el entorno, comprobar que los formularios y el correo siguen funcionando y observar los errores. Luce poco en un informe, y es lo que sostiene el sitio entre publicaciones visibles.
El volumen se acuerda al inicio de cada ciclo
Este servicio no fija un número de rondas de cambios, y la omisión es deliberada. No se indica ninguna cifra de revisiones. Lo que sí se indica es otra condición: el volumen se acuerda al inicio de cada ciclo. No traslade aquí el número de otro paquete o discutirá sobre una promesa que nadie hizo.
En la práctica, el ciclo se abre con una lista corta: qué hay que hacer este mes, qué pesa más y qué puede esperar. La lista se deja por escrito y a partir de ahí funciona como referencia compartida por ambas partes del acuerdo.
Es un instrumento más justo que un contador de revisiones, porque el trabajo de mantenimiento no es homogéneo. Actualizar una dependencia, recuperar un formulario roto y añadir un campo en el CMS son tareas de tamaños distintos, y llamar «una revisión» a cada una deforma la imagen.
Para que el ciclo no se difumine, mantenga la lista breve y ordenada por prioridad. Cuando aparece algo urgente a mitad de mes, resulta más honesto sacar otra tarea de la lista que fingir que todo sigue cabiendo en las mismas semanas.
Las actualizaciones de seguridad no son funciones nuevas
Un sitio no se queda quieto mientras usted no lo toca. Las dependencias, el entorno del servidor y los servicios de terceros siguen publicando versiones, y parte de lo que publican cierra vulnerabilidades. Instalarlas pertenece al mantenimiento y no al desarrollo de producto.
La distinción tiene una consecuencia práctica. Una actualización de seguridad no añade nada que el cliente pueda ver: después el sitio se ve y se comporta igual que antes. Saltárselas, en cambio, convierte poco a poco el proyecto en un conjunto de problemas ajenos ya conocidos.
Por eso este trabajo encaja dentro de una cuota mensual, donde no compite por presupuesto con la funcionalidad nueva. Una actualización que debe salir esta semana no debería quedarse esperando detrás de la siguiente decisión de inversión.
Revise por separado quién se ocupa de lo que viene después. Actualizar un CMS, una plataforma o una librería puede cambiar el comportamiento, así que tras la instalación conviene repasar los caminos críticos: formularios, pago, acceso y publicación de contenido en las plantillas que usa.
La deriva de dependencias y cómo se acumula
Un sitio actual se monta con decenas de paquetes externos. Cada uno sigue su propio calendario: publica correcciones, cambia interfaces y con el tiempo declara sin soporte las versiones antiguas. La distancia entre su compilación y las versiones vigentes es lo que describe la deriva.
La deriva importa porque se acumula. Una actualización omitida se aplica hoy sin esfuerzo. Un año de actualizaciones omitidas se convierte en una cadena de incompatibilidades, donde cada cambio obliga a otro más abajo en el árbol de dependencias antes de que algo vuelva a compilar.
El mantenimiento regular convierte eso en pasos pequeños y reversibles. Actualizar, compilar, probar, desplegar: y la distancia entre su código y el mundo exterior se mantiene lo bastante corta como para recorrerla en una jornada de trabajo.
Por eso el soporte cuesta dinero también en los meses en los que aparentemente no pasa nada. Que no haya cambios visibles en el sitio no significa que no haya trabajo; parte de la tarea consiste precisamente en que usted no llegue a necesitar una intervención de emergencia.
Por qué las funciones nuevas se presupuestan aparte
La condición es explícita: una construcción nueva o un rediseño no forman parte del soporte y se presupuestan por separado. No es un intento de vender más, sino la consecuencia de que se trata de trabajos de naturaleza distinta.
El mantenimiento conserva el comportamiento existente. Una función nueva lo modifica: aparecen estados nuevos, rutas nuevas, formas nuevas de fallar y pruebas nuevas que escribir. Un trabajo así no cabe con seguridad dentro de un ciclo cuyo propósito entero es la estabilidad.
Para el desarrollo funcional, VITON13 ofrece «Desarrollo de producto» por $880 con un plazo de 2-3 semanas y dos rondas de cambios por cada función entregada. Las aplicaciones móviles nativas y las licencias de pagos no están incluidas en ese paquete.
La separación también le conviene a usted. Cuando el desarrollo se presupuesta aparte, ve lo que cuesta de verdad en lugar de diluirlo en una factura de mantenimiento, donde consume en silencio las horas reservadas para la estabilidad.
Qué cambia un ritmo semanal de publicaciones
Publicar con regularidad tiene que ver menos con la velocidad que con el tamaño de cada cambio. Cuanto más a menudo salen las versiones, más pequeña es cada una y más fácil resulta identificar qué provocó un problema cuando aparece uno.
Las actualizaciones grandes y espaciadas apilan decenas de modificaciones en un mismo instante. Cuando algo se rompe después de una publicación así, encontrar la causa lleva más tiempo que la propia reparación, y el sitio funciona mal durante toda la búsqueda.
El ritmo semanal también ofrece un horizonte de planificación. Una petición formulada hoy entra en el siguiente despliegue, de modo que nadie tiene que perseguir el estado a diario ni adivinar cuándo será visible el cambio para los clientes.
El ritmo no anula la urgencia. Un fallo crítico no espera al calendario, pero todo lo demás gana al entrar en un flujo previsible en lugar de una cola abierta sin fechas asociadas.
El rendimiento cambia con el tiempo
La velocidad de un sitio no está entre los resultados que se consiguen una sola vez. Se añaden scripts de analítica, crecen las imágenes, se incrustan widgets de terceros y aumenta el volumen de datos. Cada uno de esos cambios parece inofensivo el día en que se publica.
Mantener significa vigilar esa acumulación. Compensa medir las páginas clave con una periodicidad fija y comparar el resultado con el ciclo anterior, en lugar de esperar a que un visitante diga que el sitio ha empezado a ir lento.
La documentación de rendimiento de MDN Web Docs explica de qué se compone la velocidad percibida y qué describe cada métrica. Es una referencia razonable cuando hay que explicar por qué un cambio concreto merece atención este mes.
La conclusión práctica para el propietario: incluya el rendimiento en la lista del ciclo como un punto recurrente, en lugar de tratarlo como parte de un lanzamiento que se aprobó una vez y se dio por cerrado.
La accesibilidad exige la misma atención periódica
La accesibilidad también se degrada con los cambios. Un banner nuevo atrapa el foco del teclado, un formulario añadido sale sin etiquetas en los campos, una paleta actualizada baja el contraste por debajo de lo utilizable. Todo eso llega después del lanzamiento, no en él.
La referencia rápida del W3C sobre WCAG 2.2 enumera los criterios de conformidad junto con formas de comprobarlos. Funciona bien como lista de verificación en revisiones periódicas, porque permite probar lo que se ha movido en vez de auditar otra vez el sitio entero.
Mire lo que ha cambiado: elementos interactivos nuevos, el orden del foco, las alternativas textuales de las imágenes y si los mensajes de error de los formularios se leen y se entienden sin depender solo del color para transmitir el significado.
Esto es mantenimiento, no un proyecto aparte. Encaja en el ciclo mensual en porciones pequeñas y aguanta mal el aplazamiento, porque el trabajo pospuesto vuelve convertido en una lista larga que nadie de ninguna de las dos partes quiere abrir.
Cuándo basta con una corrección puntual
Un acuerdo mensual no le conviene a todos los sitios. Cuando la tarea es finita y está bien entendida, el instrumento sensato es el «Site Fix Pack» por $70: hasta cinco correcciones acordadas, un plazo de 1-2 días laborables y una ronda de cambios.
El paquete incluye una comprobación en móvil y escritorio y una lista de «antes y después» en la entrega. Sirve para la situación en la que usted ya puede nombrar con precisión lo que le molesta y no espera nada más detrás.
Sus límites son igual de claros: páginas nuevas, rediseño y migraciones no están incluidos. No intente colar por ahí un trabajo grande, porque dedicará el tiempo a discutir sobre el alcance en lugar de recoger un resultado.
El formato puntual deja de funcionar cuando las peticiones se repiten. Tres o cuatro encargos sueltos en un trimestre indican que usted ya está comprando soporte, solo que sin previsibilidad y sin un plan común que lo sostenga.
Cómo se relaciona el soporte con el lanzamiento
El soporte suele empezar cuando el sitio ya se ha entregado. «Sitio para lanzamiento» cuesta $380 con un plazo de 3-5 días laborables e incluye una construcción responsive, la conexión del CMS básico o de los datos y la configuración del despliegue, con dos rondas de cambios antes del lanzamiento.
El contenido y las traducciones no entran en ese paquete: los aporta el cliente. El mismo límite continúa después, porque el mantenimiento no redacta sus textos; planifique las actualizaciones de contenido en su lado de la línea.
Cuando el lanzamiento corre prisa, «Launch Site Express» cuesta $520 con un plazo de 2 días laborables: el mismo alcance en una cola prioritaria con compilaciones diarias, una lista de verificación de lanzamiento y una llamada de entrega, con una ronda de cambios después de la primera construcción completa.
Fíjese en lo que Express deja fuera: contenido, fotografía y soporte continuo. El soporte es una decisión aparte, que se toma con el sitio ya publicado y se organiza en su propio ciclo en lugar de incluirse dentro del lanzamiento.
Cómo decidir si el soporte mensual le conviene
Empiece por el coste de la caída. Si un formulario roto o un pago que falla le cuesta pedidos ese mismo día, una cola previsible de correcciones tiene un valor que puede expresar como cifra y no como sensación.
Después pregúntese con qué frecuencia cambia el sitio. Una web que se mueve cada semana necesita otro cuidado que una página de presentación que nadie ha tocado en dos años, y pagar lo mismo por ambas tiene muy poco sentido.
Después pregúntese por las personas. ¿Hay alguien en el equipo que actualice dependencias, verifique una compilación y lea un registro de errores? Si nadie ocupa ese papel, el soporte cubre una función y no solo completa una lista de tareas.
Por último, el acuerdo es reversible. La condición de avisar con 30 días significa que la decisión puede revisarse sin un contrato largo: pruebe uno o dos ciclos y juzgue después qué cambió de una forma que pueda medir.
Lista práctica
- Redacte la lista del ciclo antes de que empiece y ordénela por prioridad.
- Separe en esa lista el mantenimiento de las funciones nuevas y presupuéstelos aparte.
- Revise formularios, pago y acceso después de cada actualización de dependencias.
- Mida las páginas clave en cada ciclo y compare el resultado con el anterior.
- Compruebe con los criterios de WCAG 2.2 las zonas de la interfaz que hayan cambiado.
- Deje por escrito quién avisa con 30 días para detener el servicio y de qué forma.
Preguntas frecuentes
¿Cuánto cuesta el soporte técnico continuo?
$290/mo. El servicio funciona como ciclo mensual y para detenerlo hay que avisar con 30 días de antelación. El volumen se acuerda al inicio de cada ciclo.
¿Cuántas rondas de cambios incluye al mes?
Este servicio no indica ninguna cifra de revisiones, y no conviene trasladar el número de otro paquete. La condición declarada es otra: el volumen se acuerda al inicio de cada ciclo, así que la lista de tareas se deja por escrito al abrirlo.
¿Qué incluye exactamente el soporte?
Actualizaciones prioritarias, un ritmo semanal de publicaciones y mantenimiento técnico. En la práctica son actualizaciones de paquetes, revisión de compilaciones, vigilancia del entorno, formularios y correo en funcionamiento y observación de errores.
¿El soporte cubre un rediseño o un sitio nuevo?
No. Una construcción nueva o un rediseño no forman parte del soporte y se presupuestan por separado, porque un trabajo de ese tamaño necesita su propia planificación y no las horas que sobren de un ciclo de mantenimiento.
¿En qué se diferencia el soporte de una corrección puntual?
La vía puntual es el «Site Fix Pack» por $70: hasta cinco correcciones acordadas, un plazo de 1-2 días laborables, una ronda de cambios, comprobación en móvil y escritorio y una lista de «antes y después» en la entrega. Páginas nuevas, rediseño y migraciones no están incluidos.