Come funziona un progetto web custom: dal brief alla consegna

Dalla conversazione iniziale al codice

Un progetto web custom non inizia con il codice: inizia con una conversazione. Capire il problema reale, chi userà l'applicazione, quali flussi devono funzionare dal giorno uno e quali possono aspettare. Senza questa fase il rischio è costruire qualcosa di tecnicamente corretto ma funzionalmente inutile — e succede più spesso di quanto si pensi.

Questa prima fase dura tipicamente da una a due settimane, a seconda della complessità. Non è tempo perso: è l'investimento che evita mesi di rework. Un brief ben fatto risponde a domande fondamentali: chi sono gli utenti? Quanti saranno? Quali azioni devono compiere ogni giorno? Quali dati sono critici e quali accessori? Quali sistemi esterni devono essere integrati?

Il documento di requisiti: mappa, non contratto

Dopo il brief scrivo un documento sintetico con requisiti, priorità e vincoli tecnici. Questo documento diventa il riferimento condiviso per tutto il progetto — non un contratto rigido, ma una mappa che evolve insieme al lavoro. Include una sezione dedicata alle assunzioni: tutto ciò che diamo per scontato e che, se cambia, impatta tempi e costi. Essere espliciti sulle assunzioni evita il 90% delle discussioni a progetto avviato.

Il documento include anche una stima per moduli, non un numero unico. Questo permette al cliente di capire dove va il budget e di fare scelte consapevoli: "Se togliamo il modulo di reportistica avanzata, risparmiamo 40 ore e lo aggiungiamo nella fase due." Questo livello di trasparenza costruisce fiducia e rende il progetto governabile.

Sviluppo iterativo e consegne frequenti

Non lavoro a porte chiuse per tre mesi e poi consegno tutto insieme. Preferisco iterazioni brevi: ogni una o due settimane c'è qualcosa di visibile, testabile, commentabile. Questo riduce il rischio di andare fuori strada e permette al cliente di vedere il progetto prendere forma, di toccare con mano l'applicazione e di dare feedback quando il costo di una modifica è ancora basso.

Ogni iterazione segue un ciclo preciso: pianificazione breve, sviluppo, test, demo al cliente. La demo non è una presentazione formale — è una sessione dove il cliente usa l'applicazione, prova i flussi, trova i punti che non tornano. I feedback raccolti in queste sessioni hanno un valore enorme: spesso rivelano esigenze che nessun brief avrebbe catturato.

Il prototipo funzionale: validare prima di costruire

Per progetti complessi, le prime due settimane producono un prototipo funzionale — non un mockup grafico, ma un'applicazione che funziona davvero, anche se con dati finti e interfaccia minimale. Il prototipo serve a validare le scelte architetturali e i flussi principali prima di investire settimane nello sviluppo completo. Se qualcosa non funziona a livello di prototipo, meglio scoprirlo subito che dopo aver scritto 10.000 righe di codice.

Tecnologia e architettura: scelte pragmatiche

La scelta dello stack tecnologico non è un esercizio teorico — è una decisione pratica che influenza costi, tempi e manutenibilità per anni. Per la maggior parte dei progetti web custom, PHP resta una scelta eccellente: ecosistema maturo, hosting economico, pool di sviluppatori ampio per la manutenzione futura, performance più che adeguate per il 95% dei casi d'uso.

Framework come Laravel o Symfony offrono una base solida e ben documentata. Per progetti con esigenze specifiche, un framework custom leggero può essere la scelta giusta — meno magia, più controllo, meno dipendenze da aggiornare. La decisione dipende dal contesto: team che dovrà manutenere il codice, complessità del dominio, vincoli di performance.

• Brief iniziale e documento di requisiti condiviso — la base di tutto il progetto
• Prototipo funzionale nelle prime settimane — validare prima di costruire
• Iterazioni con consegne visibili ogni 1-2 settimane — feedback continuo, rischio basso
• Test continui durante lo sviluppo, non solo alla fine — ogni modulo è verificato prima di procedere
• Deploy su ambiente di staging prima della produzione — il cliente testa in un ambiente realistico
• Code review e refactoring costante — il codice resta pulito per tutta la durata del progetto
• Documentazione tecnica e passaggio di consegne — il progetto non dipende da una sola persona

Il deploy e il passaggio di consegne

Il deploy non è premere un bottone — è un processo che va pianificato. Include la configurazione dell'ambiente di produzione, la migrazione dei dati, i test finali, il piano di rollback in caso di problemi. Un deploy ben fatto è invisibile: gli utenti iniziano a usare il sistema e tutto funziona.

Il passaggio di consegne include documentazione tecnica (architettura, scelte progettuali, come fare deploy), documentazione utente se necessaria, e una sessione di handover con chi dovrà gestire il sistema. L'obiettivo è che il progetto possa vivere anche senza il freelance che lo ha costruito — se il cliente decide di continuare con un team interno o un altro fornitore, deve poterlo fare senza ostacoli.

Alla fine del progetto il cliente riceve codice funzionante, testato e documentato. Ma soprattutto riceve qualcosa che ha seguito passo passo, senza sorprese dell'ultimo minuto. E questa è la differenza tra un progetto web custom fatto bene e uno che "alla fine è venuto fuori qualcosa".