Tu web funciona. No perfectamente, pero funciona. Cada vez que alguien del equipo toca algo, aparece un error en otro sitio. Los presupuestos de mantenimiento han subido tres veces en dos años. Añadir una funcionalidad nueva tarda el doble de lo que tardaba al principio. Y nadie del equipo técnico quiere tocar el fichero de configuración principal.
No es mala suerte. Es deuda técnica acumulada. Y como la deuda financiera, crece con los intereses si no se gestiona. La diferencia es que la deuda técnica es invisible en el presupuesto hasta que se convierte en una reescritura completa del proyecto.
Este artículo es para quien ya tiene una web en producción y empieza a notar que algo va mal, pero no sabe ponerle nombre ni saber cuándo el problema es lo bastante serio como para actuar.
Qué es la deuda técnica y por qué no es culpa de nadie
La deuda técnica es el coste acumulado de decisiones técnicas que tenían sentido en su momento pero que, con el tiempo y el crecimiento del proyecto, se convierten en lastre. No es sinónimo de código mal hecho. Es el resultado natural de proyectos que evolucionan.
Cuando un equipo elige una solución rápida para cumplir una fecha de entrega, está tomando deuda. Cuando se añade un plugin para no construir algo a medida, se toma deuda. Cuando la arquitectura inicial no contemplaba la escala actual del tráfico o del catálogo, hay deuda.
El problema no es que exista. El problema es cuando se acumula sin auditar y sin plan de pago. Una web construida con desarrollo a medida bien documentado puede tener deuda técnica. Una web en WordPress también. Lo que cambia es la velocidad a la que crece y la dificultad para resolverla.
Señal 1 — Cada cambio pequeño tiene efectos secundarios impredecibles
Cambias el color de un botón y aparece un error en el formulario de contacto. Actualizas un plugin y deja de funcionar la integración con el CRM. Añades un campo al formulario de registro y algo en el flujo de emails automatizados se rompe.
Cuando los cambios locales tienen efectos globales impredecibles, es porque el código no tiene límites claros entre módulos. Todo está conectado con todo, de forma implícita. Eso es deuda arquitectural: el coste de no haber definido interfaces claras entre partes del sistema.
Señal 2 — El stack tecnológico ha quedado obsoleto
Versiones de frameworks sin soporte de seguridad. Librerías que llevan dos años sin actualizarse y ya no son compatibles con el ecosistema actual. Dependencias que no puedes actualizar porque rompen otras dependencias. Un ciclo de incompatibilidades que hace que cada actualización sea una negociación con el caos.
La obsolescencia técnica no es estética. Es un riesgo de seguridad y un freno a la velocidad de desarrollo. Cuando el equipo dedica más tiempo a gestionar compatibilidades que a construir funcionalidades, la deuda técnica está gobernando el proyecto.
En proyectos que auditamos, la situación más frecuente es un WordPress con 40+ plugins activos, algunos sin actualizar desde hace más de un año, donde actualizar el core rompe al menos uno. No es un problema de WordPress como tecnología — es el resultado de no haber gestionado el stack con criterio desde el principio. La alternativa, cuando esto ocurre, suele ser lo que analizamos en el artículo sobre cuándo WordPress deja de ser la solución.
Señal 3 — El rendimiento ha empeorado sin cambios aparentes
Las métricas de Core Web Vitals que antes estaban en verde ahora están en amarillo o rojo. El tiempo de carga ha subido. Los usuarios de móvil tienen una experiencia peor que hace un año. Y nadie ha tocado el diseño ni ha añadido contenido pesado conscientemente.
El rendimiento que se degrada solo suele tener causas técnicas acumuladas: scripts de terceros que se han añadido sin auditar su impacto, plugins que generan consultas innecesarias a la base de datos, imágenes que no se optimizan antes de subirse, o un hosting que ya no da soporte al tráfico actual.
Tip técnico: medir la deuda de rendimiento con CrUX
El Chrome User Experience Report (CrUX) es el dataset de rendimiento real que usa Google para calcular los Core Web Vitals de tu sitio. A diferencia de Lighthouse, que mide en condiciones de laboratorio, CrUX mide la experiencia de usuarios reales en dispositivos reales. Puedes acceder a los datos de tu dominio directamente desde PageSpeed Insights o desde el informe de Core Web Vitals en Google Search Console. Si tu INP está por encima de 200ms o tu LCP supera 2,5 segundos en el percentil 75, tienes deuda de rendimiento con impacto SEO medible.
El cálculo económico que conviene hacer
La decisión de abordar la deuda técnica siempre tiene dos alternativas: pagar los intereses indefinidamente (mantenimiento creciente, velocidad de desarrollo decreciente) o pagar el principal (refactorización o reescritura con coste alto pero acotado).
El error más frecuente es comparar el coste de la reescritura con el coste del mantenimiento del próximo trimestre. La comparativa correcta es el coste del mantenimiento de los próximos dos o tres años, más el coste en oportunidades perdidas por la lentitud del equipo.
Hay proyectos donde una refactorización parcial —sin reescribir todo— resuelve el 80% de los problemas con el 20% del coste. Y hay proyectos donde la deuda es tan estructural que la refactorización cuesta casi lo mismo que reescribir con la arquitectura correcta desde el principio. Distinguir uno del otro requiere una auditoría técnica honesta.
Señales de alerta que puedes revisar hoy
- ¿Hay partes del código que el equipo evita tocar por miedo a efectos secundarios?
- ¿El coste de mantenimiento ha subido más de un 30% en los últimos dos años sin crecimiento equivalente del proyecto?
- ¿Alguna dependencia crítica lleva más de un año sin actualización de seguridad?
- ¿El LCP o el INP de tu site en PageSpeed Insights están en rojo para usuarios móviles?
- ¿Nuevas funcionalidades tardan significativamente más que al inicio del proyecto?
- ¿Hay lógica de negocio crítica sin tests automáticos?
- ¿El equipo que construyó el proyecto ya no está disponible para explicar las decisiones de arquitectura?
Preguntas frecuentes sobre deuda técnica
¿Cuándo es mejor refactorizar que reescribir?
Cuando la arquitectura base es sólida pero la implementación se ha descuidado en áreas concretas. Si el problema es de organización de código y no de decisiones estructurales, refactorizar es casi siempre más eficiente. Si la arquitectura no puede soportar los requisitos actuales, la refactorización es un parche sobre una base que no aguantará.
¿Cuánto tiempo tarda una auditoría técnica de un proyecto web?
Una auditoría que identifique los puntos críticos de deuda técnica, el estado del stack y un plan de priorización puede completarse en una o dos semanas, dependiendo de la complejidad del proyecto. No requiere acceso a todo el código: un análisis de la arquitectura, las dependencias y las métricas de rendimiento da suficiente información para tomar decisiones.
¿Se puede reducir la deuda técnica sin parar el desarrollo de nuevas funcionalidades?
Sí, con una estrategia de reducción incremental. La más efectiva es reservar un porcentaje fijo del tiempo de desarrollo —normalmente entre el 15% y el 20%— para trabajo de mejora técnica sin impacto visible para el usuario. Es más lento que una refactorización global, pero no interrumpe el producto en producción.
