WordPress resuelve muchísimo más de lo que a veces se le reconoce. También puede convertirse en una mala elección cuando se lo obliga a hacer cosas para las que no fue pensado. Usar WordPress no es el problema. Elegirlo por costumbre, sin revisar cuánto aporta al producto, sí puede serlo.
Cuando WordPress alcanza de sobra
Para sitios institucionales, medios, catálogos, landing pages, blogs, tiendas y muchos proyectos con contenido administrable, WordPress sigue siendo una herramienta muy eficiente. Tiene un ecosistema enorme, un editor conocido, usuarios no técnicos pueden trabajar sobre el contenido y hay soluciones maduras para problemas que no tendría sentido desarrollar desde cero.
Si el proyecto necesita publicar, organizar y administrar contenido, WordPress normalmente merece estar entre las primeras opciones. Y con una implementación bien hecha no tiene por qué significar un sitio lento, inseguro o lleno de plugins.
El problema empieza cuando el contenido deja de ser el centro
Hay proyectos que empiezan pareciendo un sitio web y terminan siendo otra cosa. Un sistema interno. Una plataforma con reglas de negocio complejas. Un producto donde distintos usuarios tienen permisos, estados, procesos y datos que cambian constantemente.
Una aplicación que necesita comunicarse en tiempo real con otros servicios. Ahí conviene frenar antes de convertir cada requisito nuevo en otro custom post type, otro campo y otra capa de lógica dentro de WordPress. WordPress puede hacerlo. La pregunta es si debería hacerlo.
Poder no significa que convenga
Con suficiente PHP se puede llevar WordPress muy lejos. Ese no es un argumento suficiente para elegirlo. Si la mayor parte del desarrollo termina evitando, modificando o rodeando el comportamiento natural del CMS, probablemente estemos usando la herramienta equivocada. Un buen indicador es este:
si WordPress aporta menos al proyecto de lo que obliga a adaptar, conviene revisar la arquitectura.
WooCommerce merece una discusión aparte
Con WooCommerce pasa algo parecido. En una tienda activa, además, decisiones de plataforma condicionan tareas críticas como migrar pedidos y clientes sin perder cambios. Para una tienda tradicional puede ahorrar meses de desarrollo. Productos, pedidos, impuestos, cupones, medios de pago y un ecosistema enorme ya existen.
Pero cuando el comercio tiene reglas extremadamente particulares, múltiples fuentes de inventario, flujos de compra poco convencionales o integraciones centrales con otros sistemas, WooCommerce puede terminar funcionando como una capa que hay que pelear constantemente. No significa que haya que reemplazarlo al primer requerimiento raro.
Significa que el costo de adaptación también forma parte de la decisión técnica.
Salir de WordPress tampoco significa desarrollar todo desde cero
La alternativa no siempre es: WordPress o una aplicación completamente hecha a mano. Se puede usar WordPress únicamente como CMS y consumir su contenido desde otro frontend. Se puede separar una parte específica del sistema.
Se puede mantener WooCommerce para comercio y desarrollar afuera los procesos que no pertenecen a una tienda. O directamente elegir otro stack cuando el producto lo justifica. La arquitectura no tiene por qué responder a una religión tecnológica.
Elegir por el problema
WordPress es una excelente herramienta cuando el proyecto se parece a los problemas que WordPress sabe resolver bien. Cuando deja de parecerse, conviene reconocerlo temprano. Cambiar de arquitectura al principio puede costar algunos días. Descubrir dos años después que todo el producto está sostenido por excepciones suele costar bastante más.
La pregunta final no es si WordPress puede hacerlo, sino cuánto habrá que adaptar su modelo para sostenerlo durante los próximos años.