Mantenimiento y soporte de Next.js

La mayoría de las aplicaciones no se caen. Se van a la deriva. El framework avanza dos versiones mayores, una dependencia deja de mantenerse, la persona que entendía la capa de caché se va, y un día una actualización de rutina es un proyecto de dos semanas que nadie había presupuestado.

Este es el servicio para equipos que tienen una aplicación en producción, no necesitan un especialista en Next.js cuarenta horas a la semana, y no quieren que la primera conversación con un especialista ocurra durante una incidencia.

Lo que no es

No es un retainer que existe para generar una factura. Lo decimos claro porque el sector se ha ganado la desconfianza: si un mes no tiene trabajo, te lo decimos, y no pagas esas horas.

Tampoco es una mesa de soporte. No estás metiendo tickets en una cola. Estás hablando con los ingenieros que han leído tu código.

Qué cubre

Actualizaciones de framework y dependencias. Next.js y React se mueven rápido. Seguimos lo que cambia, decidimos qué importa para tu aplicación en concreto, y hacemos la actualización habiendo leído las notas de la versión, no subiendo un número. Una versión menor que toca tu comportamiento de caché es un trabajo distinto de una que no lo toca, y saber cuál es cuál es la mayor parte del valor.

Seguridad y riesgo de dependencias. Avisos contra tu lockfile, triados según si el camino vulnerable es uno que tu código alcanza de verdad. La mayoría de los avisos en un árbol de dependencias de Next.js no son explotables en tu aplicación; de los que sí lo son, necesitas enterarte el mismo día.

Regresiones de rendimiento. Los datos de campo no se quedan arreglados solos. Un presupuesto impuesto en CI caza lo que hace un despliegue; una lectura mensual de Core Web Vitals caza lo que hicieron un cambio de CMS, una etiqueta nueva o un tercero. El mecanismo es el mismo que instalamos en ingeniería de rendimiento, y esto es mantenerlo honesto.

Incidencias. Una ingeniera con nombre y apellidos que conoce tu arquitectura, localizable dentro de una ventana acordada. Lo importante no es el tiempo de respuesta del contrato. Lo importante es que quien responde ha leído tu código antes de la incidencia y no durante.

El trabajo pequeño que nunca se prioriza. Una ruta que debería ser estática y no lo es. Una dependencia que podría irse. El use client que se ha ido colando hacia arriba hasta el layout. Por separado nada de eso justifica un proyecto; junto, es la diferencia entre una aplicación que envejece bien y una que no.

Cómo se acota

Un bloque mensual de horas, acordado por adelantado, con su propósito escrito. Las horas no usadas se quedan sin usar: no inventamos trabajo para gastarlas, y tampoco las acumulamos indefinidamente, porque un saldo que crece es señal de que el acuerdo está mal y eso hay que decirlo.

Por encima del bloque, el trabajo se presupuesta como proyecto. No hay un contador por horas corriendo de fondo.

Cualquiera de las dos partes puede terminarlo con un mes de aviso. Un acuerdo de mantenimiento que necesita un contrato para sobrevivir no es uno que queramos.

Qué te llevas el primer mes

Antes de cualquier trabajo continuado, la misma orientación que hacemos sobre cualquier aplicación heredada: un mapa de rutas, la frontera de datos, el camino de despliegue y la lista de lo que se va a romper a continuación, ordenada por cuándo. Ese documento es tuyo continúe o no el acuerdo. Es el mismo artefacto descrito en migración y rescate, y es lo que abarata todo lo que venga después.

Cuándo no necesitas esto

Si tienes una ingeniera que lee las notas de versión de Next.js, no nos necesitas para las actualizaciones. Si tu aplicación es un sitio de marketing que cambia dos veces al año, una revisión anual cuesta menos y hace lo mismo.

Preferimos decirlo al principio antes que facturar un año en el que no pasa nada.