Sviluppatore WordPress specializzato: cosa cambia rispetto a un generalista.

Spostare un sito WordPress in produzione richiede più di un backup e un ripristino. Bisogna conoscere come WordPress serializza le URL nel database, gestire il TTL DNS prima della propagazione, aggiornare le regole di caching senza lasciare pagine stantie. Un passo sbagliato in sequenza e il sito va giù durante l'orario di punta.

Uno specialista ha un protocollo: search-replace su dati serializzati, verifica delle opzioni hardcoded, test su staging prima del cutover. Non si improvvisa ogni volta. Questo riduce il rischio di errori e rende il processo più rapido da eseguire e più facile da delegare.

La risposta tipica a un conflitto tra plugin è disabilitarne uno e cercarne un altro. Funziona finché si lavora su siti semplici. Su progetti strutturati — dove ogni plugin è lì perché serve — sostituire non è un'opzione. Bisogna capire su quale hook stanno collidendo, chi ha la priorità e se si può risolvere con un filtro custom.

Diagnosticare un conflitto WordPress richiede conoscere l'ordine di caricamento dei plugin, il sistema di hook e filter, e sapere come isolare il problema senza rompere il resto. È il tipo di lavoro che un generalista può fare, ma che uno specialista fa in un quinto del tempo.

ACF, custom post type e meta query sono strumenti comuni su qualsiasi progetto agenzia un po' strutturato. Scrivere query WordPress che scalano richiede di conoscere WP_Query in profondità: quando usare meta_query, quando è meglio una query SQL diretta, come sfruttare il caching degli oggetti per evitare round-trip ripetuti al database.

Un generalista produce codice funzionante. Uno specialista produce codice funzionante che non degrada quando il sito cresce da cento a diecimila post. Su un e-commerce o un portale con molti contenuti, la differenza si vede nei tempi di caricamento prima ancora che il cliente chieda un audit.

Qualsiasi sviluppatore sa aprire Lighthouse. Sapere cosa guardare dopo è un'altra cosa. Su WordPress i colli di bottiglia più comuni sono specifici della piattaforma: CSS render-blocking del tema, filtri su the_content che aggiungono peso al markup, script caricati in modo sincrono da plugin di form, immagini non ottimizzate perché la funzione wp_get_attachment_image non viene usata correttamente.

Uno specialista arriva già al problema con un framework diagnostico: sa che su certi builder il LCP dipende da come vengono caricate le immagini hero, sa che certi plugin di cache rompono il lazy loading nativo. La diagnosi è più rapida e le correzioni più mirate.

Il momento peggiore per coinvolgere uno specialista è a metà progetto, dopo che un generalista ha già costruito l'architettura. Riorientarsi su una base di codice altrui, capire le scelte fatte e correggerle senza rompere il resto costa più che partire da zero con la persona giusta.

Non è una critica ai generalisti: è la struttura del problema. Ogni tecnico ottimizza per ciò che conosce. Se il progetto richiede competenze specifiche di WordPress, coinvolgere uno specialista dall'inizio è quasi sempre più economico che coinvolgerlo dopo.

Le domande più utili non riguardano gli anni di esperienza. Riguardano situazioni concrete: hai mai gestito una migrazione zero-downtime? Come risolvi un conflitto tra plugin su un hook condiviso? Hai lavorato con ACF su architetture multi-post-type? Le risposte vaghe o generiche dicono già molto.

Un buon indicatore è anche il modo in cui descrive gli errori passati. Chi ha risolto problemi specifici di WordPress li ricorda in dettaglio — il tipo di problema, cosa ha provato prima, cosa ha funzionato. Chi li ha solo sfiorati tende a generalizzare.

La domanda giusta non è se esternalizzare lo sviluppo WordPress, e nemmeno se il candidato sa fare WordPress — quasi tutti lo sanno fare. È se riesce a inserirsi in un processo attivo, capire il contesto senza essere guidato per mano, e consegnare qualcosa che il team può gestire dopo di lui.

L'autonomia riduce il costo di coordinamento: uno sviluppatore che ha bisogno di essere indirizzato su compatibilità browser, scelta dei plugin o layout consuma il tempo dei senior come una dipendenza. La qualità della consegna è l'altra metà — una build che può manutenere solo chi l'ha costruita non è un progetto finito, è un contratto di supporto non dichiarato. Segnali concreti di una consegna solida: codice commentato dove le scelte non sono ovvie, ACF configurato per l'editing non tecnico, nessuna dipendenza da plugin non documentati, staging che si comporta come la produzione prima del cutover.

La comunicazione deve reggere il ritmo dell'agenzia: aggiornamenti asincroni con stato chiaro, domande che arrivano già con una proposta di risposta, escalation solo per decisioni che richiedono davvero il PM. Le domande di valutazione più utili non riguardano gli anni di esperienza — riguardano situazioni concrete: come gestisci uno scope ambiguo, raccontami una consegna che non è andata come previsto.

• Tariffa molto bassa senza spiegazione — spesso lo scope non è stato capito.
• Portfolio composto solo da lavori in solitaria — non dimostra capacità di operare nel workflow di un'agenzia.
• Risposte lente nella fase di valutazione — quella sarà la cadenza anche durante i lavori.
• Nessun processo definito su revisioni e consegna — le richieste informali continuano dopo il lancio.

Il confronto corretto non è tariffa oraria contro stipendio lordo. Un'assunzione in-house porta onboarding, hardware, software, ferie e tempo manageriale che si accumulano prima di produrre vera autonomia — e quel costo resta attivo anche quando il carico scende. Un profilo junior spesso richiede revisione continua che assorbe tempo senior; il supporto white-label funziona meglio quando serve capacità pronta a entrare su staging e consegnare senza un lungo ramp-up.

Regola pratica: se la saturazione prevista del ruolo resta sotto il 70-75% per più mesi, il costo fisso tende a pesare più del previsto, e una capacità white-label già pronta è spesso la scelta più difendibile sul margine. Se il volume è stabile per quasi tutto l'anno e l'agenzia ha già tempo senior per la supervisione, l'in-house può tornare più conveniente sul lungo periodo.