Mantenimiento y soporte para webs y aplicaciones a medida (Vue, Nuxt, React, Astro)

El problema de las webs que no son WordPress

Cuando una web está hecha con WordPress, encontrar a alguien que la mantenga es relativamente fácil. Cuando está hecha a medida, con Vue, Nuxt, React, Next, Astro o Node, la cosa cambia. La mayoría de servicios de mantenimiento web que hay en Barcelona solo trabajan con WordPress, y los desarrolladores que saben de estas tecnologías suelen estar dentro de equipos de producto, no disponibles para ocuparse del proyecto de una pyme.

Así que es fácil quedarse en una situación incómoda: tienes una web o una aplicación que funciona, que te costó dinero, y nadie a quien llamar cuando hay que cambiar algo o cuando el servidor avisa de que algo va a dejar de funcionar.

Algunas situaciones habituales:

• El desarrollador que la hizo ya no está. Cambió de trabajo, cerró su empresa o simplemente no contesta.
• Nadie se atreve a actualizar. El proyecto lleva tiempo sin tocarse y cada vez que alguien lo intenta, algo deja de compilar.
• La herramienta de seguridad del repositorio muestra decenas de avisos y no sabes cuáles importan.
• El proyecto está en Nuxt 2 o Vue 2, versiones que ya no reciben correcciones de seguridad.
• La web se ha vuelto lenta y nadie sabe por qué.

Esto es justo lo que hago. Llevo más de 20 años desarrollando frontend en empresas como Softonic, coches.net, PromoFarma, GoTrendier, iAhorro, Acierto o Spock. Trabajo con Vue, Nuxt y React según las necesidades de cada proyecto.

Qué incluye el mantenimiento de una web a medida

Dependencias y vulnerabilidades

Una aplicación moderna se apoya en cientos de paquetes de npm. Cada uno se actualiza por su cuenta y, de vez en cuando, se publica una vulnerabilidad en alguno. Herramientas como npm audit o los avisos automáticos del repositorio lo detectan, pero no te dicen qué es grave para tu caso y qué no.

Lo que hago: reviso los avisos, separo lo que afecta de verdad a tu web de lo que solo está en herramientas de desarrollo, y actualizo con cuidado. Las versiones de parche y menores, con regularidad. Las mayores, planificadas, leyendo qué cambia y probando antes de publicar.

Versiones de Node y del entorno

Node también tiene fechas de caducidad. Cuando una versión deja de tener soporte, los servicios de alojamiento acaban retirándola y la web puede dejar de desplegarse. Me encargo de que el proyecto funcione con versiones con soporte y de que el entorno local, el de integración y el de producción usen la misma.

Migraciones de versión

Es lo que más preocupa a quien tiene un proyecto con unos años. Vue 2 y Nuxt 2 dejaron de recibir soporte oficial, y pasar a Vue 3 y a Nuxt 3 o Nuxt 4 no es una simple actualización: cambian la forma de escribir componentes, la gestión del estado, algunas librerías y la configuración.

Cómo lo planteo:

1. Inventario. Qué dependencias tiene el proyecto y cuáles tienen versión compatible con la nueva.
2. Plan por fases. Siempre que se puede, la migración se hace por partes, con la web funcionando entre fase y fase.
3. Pruebas. Si el proyecto no tiene pruebas automáticas, añado al menos las de los recorridos más importantes antes de empezar, para saber si algo se rompe.
4. Publicación controlada. Cada fase se publica cuando está probada, con posibilidad de volver atrás.

He hecho este tipo de trabajo en entornos grandes: la migración de coches.net a React desde .NET, la migración del backoffice de GoTrendier a React Admin o la modernización del panel de administración de Spock con Nuxt, Vue y TypeScript.

CI/CD y despliegues

Muchos proyectos heredados se publican “a mano”: alguien compila en su ordenador y sube los archivos. Funciona hasta que esa persona no está. Configuro o reviso la integración continua para que cada cambio pase pruebas y se publique de la misma forma siempre, y dejo escrito cómo se despliega.

Rendimiento

Con el tiempo, las aplicaciones crecen: más librerías, más imágenes, más código que se carga en todas las páginas. Reviso el peso de lo que se envía al navegador, el renderizado en servidor cuando lo hay y las métricas de Core Web Vitals. Si quieres entender qué miden, lo explico en la guía sobre web lenta y Core Web Vitals. Cuando el problema de velocidad es serio, lo trato como un proyecto de optimización aparte, con su propio presupuesto.

Cambios y pequeñas mejoras

Además del mantenimiento acordado, el plan Avanzado incluye hasta dos horas totales de cambios al mes, no acumulables: un campo nuevo en un formulario, un ajuste en una pantalla, una corrección que el equipo anterior dejó pendiente.

Heredo proyectos de otros desarrolladores

Recibir un proyecto ajeno es parte normal de este trabajo, y no lo hago con quejas sobre el código anterior. Todo proyecto tiene decisiones que tenían sentido en su momento.

Así empiezo:

• Revisión del repositorio. Estructura, versiones, dependencias, pruebas, cómo se compila y cómo se despliega.
• Puesta en marcha local. Si no consigo arrancar el proyecto en mi máquina siguiendo lo que hay escrito, eso ya es un hallazgo, y lo documento.
• Informe claro. Qué está bien, qué es urgente y qué puede esperar, con una estimación de cada cosa. Escrito para que lo entienda alguien sin formación técnica y, si tienes un responsable técnico, con el detalle que necesite.
• Propuesta. Mantenimiento mensual, una puesta a punto inicial o las dos cosas.

Si no tienes el código, lo primero es localizarlo. Te ayudo a pedirlo y a ponerlo a tu nombre, para que no vuelva a depender de una sola persona.

Qué necesito de ti

Para empezar a trabajar en un proyecto a medida necesito poco, pero es importante:

• Acceso al repositorio (GitHub, GitLab o el que uséis), idealmente como colaborador de una cuenta a tu nombre.
• Acceso al alojamiento donde está publicada la web y a los servicios que usa: base de datos, almacenamiento, correo transaccional, pasarela de pago si la hay.
• Las variables de entorno y claves necesarias para arrancar el proyecto, enviadas por un canal seguro y no por correo normal.
• Cualquier documentación que exista, aunque sea un correo antiguo del desarrollador anterior explicando cómo se publicaba.

Si alguno de estos accesos está a nombre de otra persona, lo primero que te recomiendo es pasarlo al tuyo. Es la mejor protección para que el proyecto no vuelva a quedarse sin dueño.

Varias instalaciones del mismo proyecto

Hay aplicaciones que funcionan como marca blanca: el mismo código con una instalación por cliente. Cada instalación puede tener su propia identidad y configuración. Mantener algo así exige que las actualizaciones se apliquen igual en todas las instalaciones y que nadie se quede atrás. Si tu proyecto funciona de esta forma, lo tengo en cuenta desde la revisión inicial.

Para quién es

• Pymes con una web o aplicación a medida que funciona pero no tiene a nadie que la cuide.
• Negocios que encargaron un desarrollo a una agencia o a un freelance y ahora necesitan continuidad.
• Responsables técnicos de una pyme que quieren delegar el frontend o el mantenimiento para que su equipo se centre en el producto.

Trabajo desde Barcelona y puedo reunirme en persona en la ciudad y el área metropolitana. Para el resto de España trabajo en remoto.

Y si estás valorando si tu próximo proyecto debería ser a medida o con WordPress, la guía WordPress o web a medida te ayuda a decidir. A menudo no hace falta algo a medida, y te lo diré. Si sí hace falta, tienes el servicio de desarrollo web a medida.

Precio

Las webs y aplicaciones sencillas pueden acogerse al plan Avanzado de mantenimiento web, a 169 €/mes sin IVA y con hasta dos horas totales de cambios, si la revisión técnica confirma su encaje. Se factura mes a mes, sin permanencia. Los proyectos más grandes, las migraciones de versión y la puesta a punto inicial se presupuestan aparte, después de revisar el código, para que sepas exactamente qué estás pagando.