WordPress sigue siendo infraestructura invisible de negocios muy distintos. Lo que cambió desde hace algunos años es la combinación exponencial de dependencias, las vulnerabilidades en cadenas poco vigiladas y la expectativa de performance que Lighthouse impone igual en sitios mediados como en SPAs grandes.
Las agencias siguen usando marketplaces porque aceleran el demo. El problema llega después: nadie tiene el inventario vivo de qué plugin hizo qué, en qué versión está el hook que parcheamos y cómo coexisten dos que tocan los mismos filters.
El coste oculto de «solo instalar uno más»
Un plugin nuevo no es una línea de CSS: suele cargar opciones persistentes en wp_options, añadir tablas nuevas si es «grande», ejecutar código en cada admin_init. Acumulas:
- Conflictos sutiles después de upgrades mayores PHP.
- Superficie de seguridad porque actualizamos lo visible pero no revisamos AJAX handlers heredados.
- Deuda conocida porque el cliente perdió login del autor original.
Construir algo acotado a medida permite solo lo que ese cliente necesita.
Principios sane para plugins propietarios
Mis guardrails prácticos:
- Namespaces únicos y prefijos coherentes incluso dentro de proyectos cortos (
cliente_feature_) para evitar colision globales accidental. - No mezcles lógicas de frontend con admin sin separar archivos compilados donde el proyecto lo permita.
- Migraciones versionadas usando el API de opciones/tablas igual que grandes plugins serios (
dbDeltadisciplined). - Tests mínimos para transformaciones datos críticas (¿qué pasa cuando el webhook JSON viene vacío pero status 200?).
Rendimiento cuando el KPI es conversión
Muy habitual: sliders de página de inicio con cinco sliders distintos. El plugin medido aisladamente anda bien pero el tiempo total scripting sube porque cada uno inicializa listeners.
Aquí desarrollos a medida te permiten encolar un solo punto de entrada y segmentar comportamiento mediante data attributes conocidos desde el equipo.
Seguridad: hooks save_post bien validados, nonces donde admin edita AJAX, sanitización igual de estricta en metabox como en frontend.
¿Cuándo terciarizar igual tiene sentido?
No pretendo tirar infra open source gratuita donde la comunidad aportó años de trabajo. Plugins maduros bien mantenidos —cache, seguridad nivel edge, SMTP serio— suelen mejor inversión que reinventar infraestructuras transversales.
La frontera donde yo empujo a custom es cuando el negocio gana diferenciador mediante reglas sólo conocidas internamente: tarifadores híbridos, integraciones con ERP argentinos, flujos B2B con estados paralelos donde el modelo mental no encaja ningún SaaS cerrado estándar.
Conclusión
En 2026 el mejor stack WordPress cliente serio suele verse como unos pocos cimientos sólidos + extensiones conscientes desarrolladas o auditadas a fondo, no como un mueble apilado donde cada mueble lleva candado incompatible con el siguiente. Así se reducen horas de soporte y se mantiene la seguridad al día.