WordPress non mi è mai piaciuto particolarmente. Non perché sia un cattivo prodotto: ha reso possibile pubblicare e gestire siti a milioni di persone, dispone di un ecosistema enorme e per molti progetti è una scelta ragionevole.
Il mio disagio nasce altrove. Quando lavoro con una PMI, raramente il problema è avere accesso al maggior numero possibile di temi, plugin e funzioni. Il problema è costruire uno strumento chiaro, mantenerlo affidabile e farlo evolvere senza accumulare dipendenze difficili da governare.
La flessibilità ha un costo operativo
WordPress nasce per adattarsi a moltissimi scenari. Questa è la sua forza, ma significa anche partire da un sistema più ampio delle necessità di una singola azienda. Per colmare la distanza tra piattaforma generica e processo specifico si aggiungono spesso tema, page builder, plugin per moduli, SEO, cache, sicurezza, backup, e-commerce e integrazioni.
Ogni componente può essere valido. È la somma a richiedere attenzione: versioni, compatibilità, configurazioni, responsabilità e aggiornamenti provengono da soggetti differenti.
La stessa documentazione ufficiale di WordPress raccomanda di mantenere aggiornati core, temi e plugin, eliminare quelli inutilizzati, scegliere componenti da fonti affidabili e predisporre backup. Non è un difetto nascosto: è il normale costo di gestione di un ecosistema estensibile. La guida ufficiale all'hardening insiste proprio sulla riduzione dei punti di ingresso e sulla preparazione al ripristino.
Meno componenti, meno superficie da governare
Un CMS custom non è automaticamente sicuro. Codice proprietario scritto male può essere più fragile di una piattaforma diffusa e verificata da anni. La sicurezza non deriva dall'essere “diversi” o meno riconoscibili.
Il vantaggio potenziale è un altro: scegliere consapevolmente quali funzioni esistono, quali ruoli possono usarle e quali dipendenze sono davvero necessarie. Un sistema più piccolo può essere più semplice da comprendere, testare, aggiornare e monitorare.
Nel CMS VECTORdesign, per esempio, registrazione pubblica, e-commerce, newsletter o cataloghi non devono essere sempre presenti. Il nucleo editoriale rimane limitato e le capacità ulteriori vengono attivate soltanto quando servono.
Quando WordPress resta una buona scelta
il sito utilizza funzioni standard già coperte bene dall'ecosistema;
l'azienda vuole poter scegliere tra molti fornitori intercambiabili;
esistono competenze e budget per manutenzione, aggiornamenti e test;
un plugin maturo risolve il problema meglio e a minor costo di uno sviluppo dedicato;
tempi e budget iniziali rendono poco sostenibile una base custom.
Quando valuterei un CMS custom
il sito deve integrarsi con processi o dati aziendali specifici;
l'interfaccia amministrativa deve essere molto semplice per ruoli non tecnici;
gran parte delle funzioni della piattaforma standard rimarrebbe inutilizzata;
la roadmap prevede evoluzioni coordinate, non installazioni occasionali;
proprietà, tracciabilità e controllo del codice hanno un valore concreto;
l'azienda dispone di un partner tecnico che garantisce continuità e documentazione.
Custom non significa ricominciare ogni volta
Il rischio dello sviluppo su misura è reinventare funzioni risolte da tempo. Per evitarlo, un buon CMS custom deve avere un nucleo riutilizzabile, procedure di sicurezza, editor, revisioni, gestione media, moduli e strumenti diagnostici già collaudati.
La personalizzazione dovrebbe riguardare ciò che distingue l'impresa, non login, upload o routing riscritti frettolosamente per ogni sito.
La domanda utile non è “WordPress sì o no?”
La domanda è: quale soluzione permette a questa azienda di raggiungere il risultato con il minor costo complessivo di proprietà, manutenzione e cambiamento?
A volte la risposta è WordPress. In altri casi un CMS più piccolo, controllato e costruito intorno alla roadmap della PMI è una soluzione migliore. La mia preferenza va al secondo approccio perché mi consente di conoscere ogni parte del sistema e assumermi responsabilità diretta sulla sua evoluzione.
