Un sistema web custom sviluppato in PHP e JavaScript per centralizzare il monitoraggio, la manutenzione e la reportistica di tutti i siti WordPress gestiti — ospitato su server dedicato, separato e indipendente dai siti dei clienti.
Il problema che ha generato questo progetto
Gestire la manutenzione di più siti WordPress contemporaneamente è un lavoro che nessun tool esistente risolve bene per un freelance indipendente. Le soluzioni di mercato — ManageWP, MainWP, WP Remote — sono progettate per agenzie strutturate con team tecnici. Sono strumenti generalisti, complessi, e spesso costosi per chi gestisce 10-20 siti in autonomia.
Il problema reale non è solo tecnico. È comunicativo. La manutenzione WordPress — aggiornamenti, backup, monitoraggio sicurezza, ottimizzazione performance — è un lavoro continuativo e invisibile. Il cliente non lo vede, non lo percepisce, e fatica a capire perché dovrebbe pagarlo mensilmente. Fino a quando qualcosa non va storto.
Il valore reale della manutenzione WordPress non è nel lavoro tecnico in sé — è nella prevenzione di problemi che il cliente non vedrà mai perché sono stati risolti prima che diventassero visibili. Comunicare questo valore richiede documentazione, non solo competenza.
WP Maintenance Pro nasce da questa doppia esigenza: uno strumento che semplifichi il lavoro tecnico e che, al tempo stesso, generi documentazione automatica da condividere con il cliente come prova tangibile del servizio erogato. Un report mensile automatizzato non è un extra: è il modo in cui il valore diventa percepibile.
La soluzione: un sistema web dedicato, non un plugin
Perché un sistema separato e non un plugin WordPress
La scelta progettuale più rilevante è stata decidere di non costruire WP Maintenance Pro come plugin WordPress. Un plugin vive dentro WordPress, dipende dal suo ciclo di aggiornamento, è soggetto ai conflitti con altri plugin e non può operare se il sito è offline. Per uno strumento di manutenzione e monitoraggio, questa dipendenza è strutturalmente sbagliata.
Un sistema web ospitato su server dedicato è indipendente dai siti che monitora. Può operare anche quando un sito cliente è in errore — che è esattamente il momento in cui uno strumento di manutenzione deve essere operativo. È questa separazione architetturale che rende il progetto tecnicamente più interessante e più solido di qualsiasi plugin equivalente.
Componenti già sviluppati
1. Sistema di autenticazione
Il primo componente completato è il sistema di autenticazione degli utenti amministrativi — chi accede al pannello di controllo. L’implementazione include gestione sessioni sicura, protezione contro attacchi brute force, token di sessione con scadenza configurabile e log degli accessi. È il fondamento su cui poggiano tutte le altre funzionalità: nessun dato di monitoraggio ha senso se il pannello che lo mostra non è adeguatamente protetto.
2. Dashboard frontend
La dashboard è la componente visibile del sistema: l’interfaccia da cui il freelance o l’agenzia gestisce tutti i siti clienti. È stata progettata con un’estetica dark e professionale, costruita con Tailwind CSS in approccio mobile-first. La scelta del dark mode non è decorativa: riduce l’affaticamento visivo in sessioni di lavoro prolungate e rispecchia l’estetica dei tool professionali di sviluppo a cui il target è abituato.
La struttura della dashboard prevede una vista panoramica con lo stato sintetico di tutti i siti gestiti, e viste di dettaglio per ogni singolo sito con dati specifici su aggiornamenti, sicurezza, backup e performance.
3. Sistema di report e notifiche
Il modulo di reportistica è la funzionalità con il maggiore impatto commerciale per chi usa il sistema. Genera report personalizzabili per ogni cliente con il riepilogo delle attività svolte nel periodo: aggiornamenti applicati, backup verificati, interventi di sicurezza, metriche di performance. I report sono brandizzabili con il logo e i dati del freelance, e vengono inviati automaticamente via email alla cadenza configurata.
Questa funzionalità trasforma un’attività tecnica invisibile in una comunicazione professionale documentata. È il modo più efficace per giustificare un contratto di manutenzione ricorrente agli occhi di un cliente non tecnico.
Componente in progettazione — Modulo di connessione ai siti WordPress
- È il problema tecnico più complesso del progetto: come connettere in modo sicuro il sistema ai siti WordPress dei clienti
- Le opzioni in valutazione: API REST WordPress con autenticazione JWT, agent leggero installato sul sito cliente, o combinazione delle due
- Requisiti chiave: nessun impatto sulle performance del sito cliente, gestione robusta dei timeout e degli errori, autenticazione sicura senza esporre credenziali
- Questa scelta determinerà il modello di distribuzione del sistema: SaaS, self-hosted o ibrido
Le decisioni progettuali più rilevanti
Dark UI come scelta funzionale
L’interfaccia dark non è una tendenza estetica: è una scelta funzionale per il target. Un freelance che usa questo strumento lo fa durante sessioni di lavoro che possono durare ore, spesso in ambienti con illuminazione variabile. Una UI dark riduce l’affaticamento visivo, migliora la leggibilità dei dati a colpo d’occhio e si allinea all’estetica degli strumenti professionali di sviluppo — IDE, terminali, tool DevOps — a cui il target è naturalmente abituato.
Mobile-first in un contesto desktop
Scegliere un approccio mobile-first per uno strumento di gestione tecnica potrebbe sembrare controintuitivo. La ragione è pratica: un freelance che gestisce siti clienti deve poter verificare lo stato di un sito in qualsiasi momento, anche da smartphone, anche quando non è alla scrivania. La dashboard mobile non è una versione ridotta: è una versione ugualmente funzionale con layout ottimizzato per il tocco.
PHP sul backend come scelta deliberata
In un contesto in cui Node.js e i runtime JavaScript full-stack dominano il discorso sulle architetture moderne, scegliere PHP per il backend di un progetto personale è una decisione consapevole. PHP 8.x è un linguaggio maturo, performante e — soprattutto — è il linguaggio nativo dell’ecosistema WordPress. Costruire lo strumento di manutenzione nello stesso linguaggio dei sistemi che gestisce non è un’incoerenza: è coerenza tecnica.
Il problema aperto: la connessione ai siti
La scelta architetturale più critica — ancora aperta — riguarda il meccanismo di connessione ai siti WordPress dei clienti. Un sistema pull (il server centrale interroga i siti a intervalli) richiede credenziali di accesso conservate centralmente, con implicazioni di sicurezza rilevanti. Un sistema push (ogni sito invia dati al server centrale) richiede l’installazione di un componente su ogni sito cliente, avvicinando il progetto a un’architettura ibrida. La scelta tra questi approcci determinerà anche il modello di distribuzione finale del sistema.
Progettare prima di costruire
WP Maintenance Pro è il primo progetto in cui ho dedicato una fase strutturata alla progettazione prima di scrivere codice. Definire l’architettura, documentare le decisioni tecniche, mappare i flussi di dati e identificare i problemi aperti prima dell’implementazione sta producendo un codice più pulito e un sistema più coerente. È un approccio che sto trasferendo anche sui progetti cliente.
Il confine tra prodotto e servizio
Costruire uno strumento proprio cambia la prospettiva sul lavoro per i clienti. Quando sviluppi un sito per un avvocato o uno psicologo, la manutenzione è un servizio. Quando costruisci lo strumento per erogare quel servizio, diventa un prodotto. Le logiche sono diverse: un prodotto deve funzionare per utenti diversi in contesti diversi, con casi limite che un servizio su misura non incontra mai.
La sicurezza come requisito architetturale
Il modulo di autenticazione — il primo componente completato — mi ha messo di fronte a requisiti di sicurezza più stringenti di qualsiasi progetto cliente. Un sistema che ha accesso ai dati di manutenzione di più siti WordPress è un target ad alto valore per attacchi. Progettare la sicurezza fin dall’architettura, non aggiungerla in seguito, è la lezione principale di questa fase del progetto.
Perché questo progetto appare nel mio portfolio
WP Maintenance Pro non è un progetto cliente. Non ha un committente, non ha una deadline esterna, non ha un budget definito. È un progetto personale che esiste perché ho identificato un problema reale nel mio lavoro quotidiano e ho deciso di costruire la soluzione invece di adattarmi a quelle esistenti.
Lo includo nel portfolio per una ragione precisa: mostra un tipo di ragionamento che i lavori per i clienti non sempre rendono visibile. La capacità di identificare un problema, progettare un’architettura, prendere decisioni tecniche motivate e documentare un percorso ancora in corso.