Mantenimiento operativo para OctoberCMS

Depende del servicio, y conviene mirarlos por separado porque las condiciones son distintas:

• Mantenimiento operativo — permanencia mínima de 3 meses.
• Retainer (capacidad de desarrollo) — sin permanencia mínima; baja con 30 días de aviso.
• OnePage — permanencia mínima de 6 meses, con 15 días de aviso para la baja.
• Email hosting — sin permanencia; mensual y cancelable cuando quieras.

La permanencia del mantenimiento operativo existe por una razón concreta: hacerse cargo de un sistema implica conocerlo, y eso lleva tiempo. Los tres primeros meses son los que hacen que el servicio valga la pena para ambas partes.

No. Podemos operar distintas tecnologías, pero contamos con un equipo especialmente fuerte en October CMS y ecosistemas Laravel/PHP.

Sí. Hacemos una fase de diagnóstico inicial y, a partir de ahí, definimos el plan y los riesgos.

Podemos priorizar tareas, replanificarlas para el mes siguiente o ampliar la capacidad de ese mes con una cotización adicional acordada previamente.

Nunca ejecutamos horas por encima del techo de tu retainer sin avisarte antes: la decisión de cómo seguir es siempre tuya.

Operamos desde España, en horario europeo, con foco en proyectos que valoran cercanía, comunicación clara y compromiso a largo plazo.

Una emergencia es una incidencia que impide la continuidad operativa del negocio: el sistema no está disponible, ningún usuario puede iniciar sesión, no se pueden procesar pagos por ningún medio, o una funcionalidad crítica detiene la actividad. Lo que la define es el impacto sobre la operación —no el tamaño del desarrollo— y que el origen esté dentro del sistema.

No son emergencias: los errores visuales o de diseño que no impiden operar, los problemas que afectan a un solo usuario, las incidencias que permiten seguir trabajando por otra vía o esperar al siguiente día hábil, y los fallos de servicios externos (internet, pasarelas de pago, proveedores de correo). Pueden tener prioridad alta o incluso crítica, pero se atienden dentro del horario laboral.

La urgencia comercial —una reunión, una entrega prometida, un cierre de venta— la entendemos y la tenemos en cuenta para priorizar, pero no cambia la clasificación técnica de una incidencia.

Con tres cosas alcanza:

1. Cómo reproducirlo — qué hiciste, en qué orden y en qué página (pegá la dirección).
2. Una captura o un video — vale más que cualquier descripción.
3. Qué esperabas que pasara y qué pasó en realidad.

Sin una forma concreta de reproducirlo no hay nada que corregir: no podemos arreglar lo que no podemos ver fallar.

Cuanto mejor esté el reporte, menos tiempo se va en diagnóstico y antes queda resuelto. Y es una diferencia con efecto en el costo: corregir un bug cubierto por la garantía no se cobra, pero investigar y reproducir un problema que termina no siendo un bug sí es una tarea facturable.

Desplegamos por la mañana y nunca los viernes, para tener el día por delante por si hay algo que revisar. Un despliegue de viernes a última hora es la forma más segura de arruinarle el fin de semana a alguien.

Antes de salir a producción, cada tarea pasa por tu revisión en el entorno de pruebas. Mientras una tarea entregada espera tu visto bueno, frena a las que vienen detrás: un despliegue arrastra todo lo que está aprobado y pendiente de publicar, no se sube una cosa suelta.

Las tareas también salen en orden: cuando una depende de otra, la de abajo se revisa y se publica primero. Por eso el ritmo depende de los dos: revisión al día, salida al día.