Eliminé todos los plug-ins de mi WordPress y mi cliente me despidió.
O cómo aprendí que el código perfecto no paga facturas y que a veces la solución «fea» es la correcta
El momento exacto en que supe que había metido la pata fue cuando recibí el email. Asunto: «Necesitamos hablar urgente». Era Susana, mi cliente, dueña de una tienda online Print-On-Demand. Había pasado tres semanas rediseñando su WordPress desde cero, eliminando los 37 plug-ins que consideraba «innecesarios» y reemplazándolos con código limpio y elegante escrito a mano.
El sitio era técnicamente perfecto. Cargaba en 2.2 segundos, tenía una puntuación de 98 en PageSpeed Insights, el código era tan limpio que daba gusto leerlo. Me sentía como una artesana del desarrollo, como si acabara de esculpir una obra maestra digital. Entonces llegó ese email y todo se vino abajo.
«El formulario de contacto ya no envía copias a mi asistente», decía el primer párrafo. «No puedo cambiar los textos de la página de envíos sin llamarte», continuaba. «Antes podía duplicar productos con un clic, ahora tengo que crear cada uno desde cero».
Y el remate: «Necesito agregar cupones de descuento para el Black Friday que empieza en dos días. Me dijiste que te tomaría cuatro horas y costaría 300 euros. Antes instalaba un plugin gratis en cinco minutos».
Tres días después, Susana contrató a otra desarrolladora. Una que usaba plug-ins.
La purista del código que fui
Durante los últimos dos años me he convertido en lo que llamaríamos una «purista del código». Había leído todos los artículos sobre optimización, había visto las charlas de Word Camps donde desarrolladores experimentados despotricaban contra la «hinchazón de plug-ins», había escuchado una y otra vez que «el código custom es más seguro, más rápido, más profesional».
Y tenían razón, técnicamente hablando. Los plug-ins vienen con código que probablemente no vas a usar nunca, cargan librerías innecesarias, a veces entran en conflicto entre sí, y cada uno representa un potencial vector de ataque si no se mantiene actualizado. Las estadísticas son brutales: según datos de 2025, hay 64,782 vulnerabilidades documentadas en el ecosistema WordPress, y el 92% de todas las brechas exitosas en sitios WordPress durante 2025 se originaron en plug-ins y temas, no en la raíz del sistema.
Armada con estos datos, me convertí en una cruzada contra los plug-ins. Cada proyecto nuevo era una oportunidad para demostrar mi superioridad técnica. El proyecto de Susana fue mi obra cumbre.
Revisé cada uno de sus 37 plug-ins y me propuse eliminarlos todos. Contact Form 7, WooCommerce, Yoast SEO, WP Rocket, Wordfence Security, UpdraftPlus Backup, Advanced Custom Fields… todos fueron cayendo uno por uno, reemplazados por mi código elegante y minimalista.
La realidad que no quería ver
Lo que descubrí durante esas tres semanas fue algo que mi ego de desarrolladora se negaba a admitir: esos 37 plug-ins que consideraba «basura innecesaria» representaban literalmente cientos de miles de horas de desarrollo colectivo. Contact Form 7 no es solo un formulario, es un sistema robusto que maneja spam, validación, múltiples destinatarios, archivos adjuntos, integración con servicios de email, y mil casos edge que yo ni siquiera había considerado.
WooCommerce no es solo un carrito de compra, es una plataforma completa de comercio electrónico con gestión de inventario, cálculo de impuestos para diferentes países, múltiples pasarelas de pago, cupones de descuento con reglas complejas, y compatibilidad con otros miles de plug-ins que extienden su funcionalidad.
Yo, en mi arrogancia, creí que podía replicar todo eso en tres semanas.
Técnicamente, lo logré, más o menos. El sitio funcionaba. Pero había olvidado el factor más importante: el cliente no es desarrolladora.
Susana necesitaba autonomía, no perfección técnica. Necesitaba poder cambiar un texto sin contactarme, agregar un cupón de descuento sin esperar cuatro horas de desarrollo, duplicar un producto sin entender qué es un post type o un custom field.
Los plug-ins que yo consideraba «hinchazón innecesaria» eran en realidad herramientas de empoderamiento. Le daban a Susana control sobre su negocio. Mi código limpio y perfecto se lo quitó.
Los números que duelen
Hagamos las cuentas reales de este desastre. Le cobré a Marta 2,400 euros por el rediseño y optimización de su sitio. Tres semanas de trabajo a tiempo completo. El sitio pasó de cargar en 3.8 segundos a 1.2 segundos. Las métricas de rendimiento mejoraron dramáticamente. Técnicamente, era superior en todos los sentidos.
Pero los costos ocultos empezaron a aparecer inmediatamente.
Primera semana: Marta necesitó cambiar el texto de su página de políticas de envío. Con su configuración anterior de plug-ins, ella misma lo habría cambiado en dos minutos. Con mi código custom, necesitaba que yo accediera al código y modificara una plantilla. Tiempo: 15 minutos más su tiempo de espera. Costo: 30 euros que no le cobré por vergüenza.
Segunda semana: quiso agregar un nuevo método de pago. Con WooCommerce habría instalado una extensión en minutos. Con mi sistema custom necesitaba integración manual con la API del procesador de pagos. Tiempo: 6 horas de desarrollo. Costo: 450 euros que tampoco cobré porque era «parte del sistema que debería haber previsto».
Tercera semana: Black Friday. Necesitaba crear 15 cupones de descuento diferentes con reglas específicas. Con WooCommerce y un plugin de cupones avanzados esto le habría tomado media hora a ella misma. Con mi código custom necesitaba que yo programara cada cupón manualmente. Tiempo estimado: 8 horas. Costo: 600 euros.
Fue ahí cuando recibió el email de despido disfrazado de «creo que necesito buscar otro tipo de solución».
Las vulnerabilidades que nadie menciona
Una de mis principales justificaciones para eliminar plug-ins era la seguridad. Y sí, las estadísticas son aterradoras. Solo en diciembre de 2025, 150 nuevas vulnerabilidades emergieron en el ecosistema WordPress, 140 en plug-ins y 10 en temas. De esas, 26 permanecían sin parche al momento de ser reportadas.
Aproximadamente el 35% de todas las vulnerabilidades descubiertas en 2024 permanecieron sin parche durante 2025. Casos críticos han incluido el plugin Post SMTP con más de 400,000 instalaciones activas, que tenía una vulnerabilidad que permitía a atacantes tomar control de cualquier cuenta, con 4,500 ataques bloqueados solo en el primer día.
Armada con estos datos, mi argumento parecía sólido: si elimino todos los plug-ins, elimino todos estos vectores de ataque. Pero había un problema enorme con este razonamiento: asumía que mi código custom era inherentemente más seguro que el código de plug-ins desarrollados por equipos dedicados, revisados por comunidades de miles de desarrolladores, y constantemente auditados por empresas de seguridad.
La realidad es menos halagadora para mi ego. El código custom mal mantenido puede ser mucho más vulnerable que un plugin popular bien mantenido. ¿Por qué? Porque nadie está auditando mi código excepto yo. No hay una comunidad de investigadores de seguridad revisándolo constantemente. No hay actualizaciones automáticas cuando se descubre una vulnerabilidad. Si introduzco un bug de seguridad en mi código custom, podría pasar desapercibido durante meses o años.
Además, los plug-ins populares son atacados más frecuentemente precisamente porque son populares. Los hackers desarrollan exploits para plug-ins con millones de instalaciones porque el retorno de inversión es alto. Mi código custom, por más vulnerable que sea, probablemente nunca será objetivo de ataques específicos simplemente porque no vale la pena. Esto no significa que sea más seguro, sólo significa que es menos interesante como objetivo.
El costo real del mantenimiento
El código custom necesita mantenimiento continuo que raramente facturamos correctamente. Cuando reemplacé WooCommerce con mi sistema custom, estaba
asumiendo la responsabilidad de mantenerlo compatible con cada actualización futura de WordPress, con cada cambio en las APIs de los procesadores de pago, con cada nueva regulación de protección de datos, con cada navegador nuevo o actualizado.
Los plug-ins populares tienen equipos dedicados a esto. WooCommerce tiene docenas de desarrolladores a tiempo completo cuyo único trabajo es asegurarse de que funcione con cada nueva versión de WordPress. Y lo hacen gratis para el usuario final porque su modelo de negocio lo soporta. Yo, desarrolladora freelance, tenía que hacer ese mismo trabajo solo para el sitio de Susana, entre otros proyectos, y probablemente olvidaría hacerlo hasta que algo se rompiera.
Según datos de 2025, el costo de mantenimiento de WordPress varía de 70 a 1,000 euros o más al mes dependiendo de la complejidad del sitio. Para desarrollo custom, los costos suelen ser más altos porque requieren conocimiento especializado.
¿Cuánto le cobré a Susana por mantenimiento mensual después de mi brillante rediseño custom? Le ofrecí un plan de 80 euros al mes que incluía actualizaciones de seguridad y compatibilidad. Pero no incluía cambios funcionales, no incluía agregar nuevas características, no incluía debugging de problemas futuros.
La flexibilidad que perdimos
Uno de los momentos más reveladores fue cuando Susana me pidió agregar un sistema de reseñas de productos tres meses después del lanzamiento. Sus clientes lo pedían y la competencia lo tenía. Con WooCommerce habría sido instalar una extensión de reseñas, configurarla en media hora, y listo.
El coste: entre 30 y 80 euros por una extensión premium, o gratis con la funcionalidad nativa de WooCommerce.
Con mi sistema custom, necesitaba diseñar la base de datos para almacenar reseñas, crear el formulario de envío, implementar moderación anti-spam, diseñar la visualización de estrellas, agregar el sistema de respuestas del vendedor, implementar verificación de compra, y asegurarse de que todo funcionara sin romper nada.
Tiempo estimado: 20 horas de desarrollo y testing. Coste real: 1,500 euros mínimo. Tiempo de implementación: dos semanas.
Susana decidió que no valía la pena. Su competencia consiguió 47 reseñas en esas dos semanas. Las reseñas generaban confianza, mejoraban SEO, incrementaban la conversión. Todo eso lo perdió porque yo había decidido que WooCommerce era «hinchazón innecesaria».
Este patrón se repitió constantemente. Cada nueva necesidad de negocio se convertía en un proyecto de desarrollo. Cada proyecto tomaba tiempo y costaba dinero. El negocio de Susana necesitaba agilidad y yo le había dado rigidez técnica perfectamente optimizada.
La lección que no quería aprender
Pasaron seis meses desde que perdí a Susana como cliente. En ese tiempo hice mucha reflexión incómoda. Volví a trabajar con plug-ins no de forma indiscriminada, pero sí de forma estratégica y humilde.
Aprendí a hacer las preguntas correctas antes de decidir si algo debe ser custom o plugin.
La pregunta principal no es «¿puedo programar esto mejor que un plugin?». La pregunta principal es «¿puede el cliente mantener y modificar esto sin mí?».
Si la respuesta es no, probablemente necesita un plugin con interfaz administrativa, no código custom por más elegante que sea.
La segunda pregunta es «¿cuánto vale realmente esta optimización?». Si puedo reducir el tiempo de carga de 2.8 segundos a 1.2 segundos eliminando plug-ins eso suena genial. Pero la investigación muestra que después de los primeros 2 segundos, las mejoras de velocidad tienen retornos decrecientes en conversión. Ese segundo y medio adicional me costó tres semanas, le costó a Susana 2,400 euros, y le quitó autonomía sobre su sitio. ¿Valió la pena? Claramente no.
La tercera pregunta es «¿quién mantiene esto a largo plazo?». Un plugin popular con 2 millones de instalaciones tiene incentivos económicos claros para mantenerse actualizado y seguro. Mi código custom tiene exactamente un incentivo: mi sentido de responsabilidad profesional. Uno de esos es mucho más confiable a largo plazo.
El equilibrio que funciona
Ahora trabajo con lo que llamo el «principio de pragmatismo informado». Uso plug-ins para todo lo que el cliente necesita controlar directamente: contenido, formularios básicos, SEO, Analytics, backups, seguridad básica, caché. Estas son funcionalidades commodity donde reinventar la rueda es solo ego disfrazado de profesionalismo.
Escribo código custom solo para tres cosas específicas: funcionalidades genuinamente únicas del negocio que no tienen solución viable en plug-ins existentes, optimizaciones críticas donde la diferencia de rendimiento es medible y significativa para el negocio, e integraciones con sistemas internos del cliente que requieren lógica específica.
Para todo lo demás, busco el mejor plugin disponible, lo evalúo cuidadosamente revisando su historial de actualizaciones, su base de usuarios, sus reseñas, y entonces lo implemento sin vergüenza. He aprendido que usar un buen plugin no me hace menos desarrolladora, me hace mejor profesional.
También he aprendido a educar a los clientes sobre el costo real de las decisiones técnicas. Cuando alguien me pide «un sitio superoptimizado sin plug-ins innecesarios», ahora pregunto: ¿qué prefieres, un sitio que carga en 1.2 segundos pero donde cada cambio requiere llamar a una desarrolladora, o un sitio que carga en 2.3 segundos pero donde puedes agregar productos, modificar textos, y crear promociones tú misma?
La mayoría, cuando lo planteas así, elige autonomía sobre perfección técnica.
Los clientes que recuperé
Hace dos meses Susana me contactó de nuevo. La desarrolladora que me reemplazó había construido su nuevo sitio con aproximadamente 50 plug-ins muchos redundantes o innecesarios.
El sitio cargaba en 6.2 segundos, había conflictos constantes, y cada actualización era ruleta rusa de qué se iba a romper.
«Necesito un punto medio», me escribió. «No quiero tu versión superoptimizada donde no puedo tocar nada, pero tampoco quiero esto. “Quiero algo que funcione bien y que yo pueda controlar razonablemente».
Le propuse un rediseño usando un set curado de 12 plug-ins bien seleccionados, código custom solo donde genuinamente agregaba valor, y capacitación para que ella pudiera manejar las operaciones diarias sin mí. Aceptó.
El sitio resultante carga en 2.1 segundos, tiene una puntuación de PageSpeed de 89, y Susana puede agregar productos, crear cupones, modificar contenido, e incluso instalar plug-ins adicionales simples sin consultarme. El código no es tan elegante como mi versión purista, pero funciona mejor para el negocio real de ella. Y eso, finalmente aprendí, es lo que importa.
Los plug-ins no son el enemigo. Mi ego era el enemigo. La búsqueda de perfección técnica a expensas de usabilidad práctica era el enemigo. Los plug-ins son herramientas. Y como todas las herramientas, funcionan bien cuando las usas correctamente y mal cuando las usas indiscriminadamente o te niegas a usarlas por principio.
Ahora soy una desarrolladora que usa plug-ins sin vergüenza, que escribe código custom con humildad, y que nunca olvida que el código más elegante del mundo no sirve de nada si el cliente no puede pagar sus facturas porque perdió agilidad de negocio por mi perfeccionismo técnico.
A veces el código «feo» es la solución correcta. Y eso está bien.
Este artículo lo escribí después de perder un cliente y recuperar mi humildad. Los datos son reales. Las lecciones fueron costosas. El ego todavía me duele un poco, pero al menos ahora entiendo por qué los plug-ins existen y por qué usarlos bien no te hace peor profesional.
