1. La domanda sbagliata
Molte discussioni tra sviluppatori partono da un presupposto fisso: il custom è sempre meglio. Non è così.
Un tema custom richiede più tempo di sviluppo iniziale, più manutenzione nel lungo periodo e uno sviluppatore disponibile ogni volta che il cliente vuole cambiare un dettaglio di layout che con un builder gestirebbe da solo. La domanda corretta è: chi gestisce questo sito tra un anno e cosa deve poter cambiare senza coinvolgere il reparto tecnico?
2. Quando un tema custom ha senso
Ci sono progetti in cui sviluppare un tema custom è la scelta più difendibile.
- Il design ha componenti molto personalizzati che nessun builder gestisce bene senza decine di moduli aggiuntivi.
- Le performance sono un requisito tecnico preciso: audit Lighthouse richiesti dal cliente o standard definiti nel contratto.
- Il progetto ha logiche PHP complesse: custom post type avanzati, query personalizzate, plugin su misura.
- Il cliente non ha mai bisogno di modificare layout, solo contenuti testuali e immagini.
- Il team ha le competenze per mantenere il tema nel tempo senza affidarsi a documentazione esterna.
3. Quando un builder è la scelta giusta
Un builder non è una scorciatoia. In molti contesti è semplicemente la soluzione più adatta.
- Il cliente deve poter modificare il layout in autonomia: spostare sezioni, aggiungere blocchi, cambiare l'ordine degli elementi.
- Il progetto ha scadenze strette e i tempi di un tema custom non sono compatibili con la pipeline dell'agenzia.
- Il design è relativamente standard: hero, sezioni, card, moduli — componenti che ogni builder gestisce già bene.
- L'agenzia ha una libreria di template consolidata in Elementor o Bricks che riduce i tempi su ogni nuovo progetto.
- La manutenzione futura ricade su chi non ha competenze di sviluppo.
4. I costi nascosti di ciascuna scelta
Un tema custom richiede uno sviluppatore ogni volta che il cliente vuole modificare il layout. Questo è un costo operativo che si accumula nel tempo e pesa sul rapporto tra agenzia e cliente.
Un builder gestito male accumula sovrascritture CSS, moduli aggiuntivi e template duplicati. Diventa difficile da mantenere, lento da aggiornare e fragile agli aggiornamenti di versione.
| Criterio | Tema custom | Page builder |
|---|---|---|
| Tempo di sviluppo iniziale | Più lungo | Più breve |
| Autonomia del cliente sul layout | Nulla o molto limitata | Alta se configurato con cura |
| Output DOM e performance | Più pulito e controllabile | Dipende dal builder e da come viene usato |
| Manutenzione nel tempo | Richiede sviluppatore per modifiche strutturali | Autonoma per il cliente, tecnica per chi sviluppa |
| Flessibilità futura | Alta per chi sviluppa, bassa per chi gestisce | Alta per chi gestisce, limitata per modifiche strutturali |
5. Il criterio decisionale in pratica
Una regola semplice: se il cliente deve poter cambiare il layout da solo, usa un builder. Se il layout è fisso e il cliente gestisce solo contenuti, un tema custom è più difendibile.
In molti progetti agenzia la risposta è mista: tema custom per la struttura, Gutenberg o ACF Blocks per le parti editoriali. Questo dà controllo tecnico sullo scheletro del sito e autonomia al cliente su ciò che aggiorna ogni settimana.
Domande frequenti
Un sito costruito con un page builder è tecnicamente più debole?
Non necessariamente. Dipende da come è stato costruito. Un builder con classi globali, markup pulito e governance chiara produce siti solidi. Un tema custom sviluppato male pesa quanto qualsiasi builder gestito in modo approssimativo.
Si può passare da builder a tema custom in un secondo momento?
Sì, ma richiede lavoro reale. Nella maggior parte dei casi è più sensato pianificare l'approccio giusto fin dall'inizio che migrare in seguito con il sito già in produzione.
Prossimo passo
Non sei sicuro di quale approccio sia giusto per il tuo progetto?
Posso aiutarti a valutare la scelta tecnica in base a requisiti reali, tempi e autonomia del cliente.
Parliamo del progetto