31 Jul 2026

“Per quando è pronto?” è la domanda che arriva subito dopo a “quanto costa”. E come per il prezzo, la risposta onesta è che dipende — ma a differenza del prezzo, qui la variabile principale non siamo noi: siete voi.

Non è una scusa da fornitore: il Pulse of the Profession del Project Management Institute rileva che solo il 57% dei progetti si chiude nei tempi previsti e che il 52% subisce modifiche di perimetro non controllate.

Nella nostra esperienza, i progetti che sforano non lo fanno per problemi tecnici. Sforano perché i testi della pagina “Chi siamo” arrivano tre settimane dopo, o perché il responsabile che deve approvare la grafica è in ferie. Vediamo quindi non solo i tempi tipici... ma dove si perdono davvero i giorni.

I tempi tipici per tipologia

Tempi indicativi dal via libera alla pubblicazione, con contenuti forniti in tempi ragionevoli.

  • Landing page / sito one-page: 2-3 settimane
  • Sito vetrina aziendale (5-12 pagine): 4-8 settimane
  • Sito corporate o multilingua: 8-16 settimane
  • E-commerce: 8-20 settimane, a seconda del catalogo e delle integrazioni
  • Portale o web app su misura: da 3 mesi in su, con rilasci progressivi

Se qualcuno vi promette un sito vetrina completo in tre giorni, sta parlando di un template popolato con i vostri contenuti messi dentro senza pensare, facendo copia e incolla. Può anche andarvi bene, purché sappiate cosa state comprando: ne parliamo in sito fai da te o professionista.

Le fasi di un progetto, con i tempi reali

1. Analisi e definizione (1-2 settimane)

Obiettivi, pubblico, analisi dei concorrenti, ricerca delle parole chiave, mappa del sito. Ne esce anche la struttura definitiva degli URL: deciderla qui evita di doverla cambiare a sito pubblicato.

È la fase che i clienti percepiscono come “ancora non è successo niente” ed è quella che determina se il sito funzionerà. Saltarla non fa risparmiare tempo: lo sposta più avanti, quando costa di più.

2. Progettazione e design (2-4 settimane)

Wireframe delle pagine chiave, poi il design vero e proprio, di norma su homepage e una pagina interna tipo. Non due immagini, ma un sistema: componenti, breakpoint e gli stati che nessuno chiede nel brief e servono tutti — focus da tastiera, campo in errore, elenco vuoto, caricamento. Se non si decidono qui, si improvvisano dopo.

Le revisioni sono normali e previste; il problema nasce quando le richieste cambiano direzione dopo l’approvazione. Un buon contratto stabilisce quante tornate di revisione sono incluse: oltre quelle, i tempi si allungano e i costi salgono.

3. Sviluppo (2-8 settimane)

Qui si costruisce: markup, responsive, CMS, moduli, integrazioni, prestazioni. È la fase più lunga e la più silenziosa. È anche quella in cui il cliente dovrebbe già stare lavorando ai contenuti mancanti, e quasi mai lo fa.

Sulle prestazioni le soglie sono pubbliche: i Core Web Vitals di Google chiedono LCP entro 2,5 secondi, INP entro 200 millisecondi e CLS entro 0,1, misurati al 75° percentile degli utenti reali. Si rispettano decidendo dall’inizio peso delle immagini, font e script di terze parti: non si recuperano con un plugin la settimana prima del lancio.

4. Contenuti e popolamento (1-3 settimane, spesso molte di più)

È qui che si perde il tempo. Testi, foto, schede prodotto, traduzioni. Se i contenuti sono pronti, questa fase dura giorni. Se vanno prodotti mentre il sito è già sviluppato, può durare mesi.

Vale la pena quantificare: un sito vetrina da otto pagine sono 6.000-10.000 parole e 30-60 immagini a risoluzione utile; un e-commerce da 300 prodotti chiede titolo, descrizione, attributi, prezzo, disponibilità e foto trecento volte. E la traduzione parte solo quando l’italiano è definitivo.

5. Test, correzioni e pubblicazione (5-10 giorni)

Verifica su browser e dispositivi diversi, certificato SSL, backup. Poi una lista tecnica che nessun utente vedrà mai e che decide se il sito parte bene o parte zoppo: canonical, meta description, Open Graph, hreflang se il sito è multilingua, sitemap.xml e robots.txt coerenti, Search Console verificata. Sono aspetti che si implementano durante lo sviluppo e si verificano con calma prima del rilascio.

Se state rifacendo un sito che esiste già, a questa lista si aggiunge la voce più delicata di tutte: la mappa dei redirect 301, cioè l’elenco che collega ogni vecchio indirizzo al suo corrispondente nuovo. È ciò che determina se il traffico e il posizionamento accumulati negli anni sopravvivono al passaggio o si azzerano il giorno del lancio. Non è un lavoro da mezz’ora: su un sito di qualche centinaio di pagine sono giorni, e Google raccomanda di tenere i redirect attivi per almeno un anno. Se il sito è nuovo, invece, il problema non si pone: mettetelo in conto solo nel caso del restyling.

A questo si aggiunga un controllo che quasi tutti dimenticano: il recapito effettivo delle email dei moduli. Senza SPF, DKIM e DMARC configurati sul dominio le richieste finiscono nello spam, e il sito sembra semplicemente non generare contatti.

Le cinque cause di ritardo più frequenti

  1. I testi e/o le immagini non arrivano. Prima causa in assoluto, con ampio distacco su tutte le altre. Se non avete tempo per scrivere i testi, mettete a preventivo il copywriting: costa meno delle settimane perse. Se le foto le mandate voi, mettete in conto il tempo di raccoglierle, con didascalie e spiegazioni.
  2. Troppi decisori. Ogni persona in più nel processo di approvazione aggiunge giorni. Nominate un referente unico con potere di firma.
  3. Richieste che cambiano a sviluppo iniziato. Aggiungere una funzionalità in fase di analisi costa un’ora di discussione; aggiungerla a sviluppo avviato può costare una settimana. È il fenomeno che il PMI misura nel 52% dei progetti.
  4. Materiali di terzi. Accessi al gestionale, chiavi API del corriere, credenziali del vecchio hosting, controllo del pannello DNS, dati del vecchio fornitore. Recuperarli richiede sempre più tempo del previsto: iniziate subito.
  5. Le ferie. Agosto e le due settimane a cavallo di Natale non esistono. Tenetene conto quando fissate una data di lancio.

Come far andare il progetto più veloce (davvero)

  • Preparate i contenuti prima del via libera, non durante. Anche in bozza grezza: il copywriter li sistema, ma la sostanza deve esserci.
  • Raccogliete subito le credenziali: registrar del dominio, accesso ai DNS, hosting attuale, analytics, profili social, eventuali gestionali.
  • Concentrate i feedback: un documento unico con tutte le osservazioni invece di dodici email in tre giorni.
  • Distinguete “bloccante” da “migliorabile”. Il sito può andare online e migliorare dopo. Rimandare la pubblicazione per una virgola significa rimandare anche i contatti che il sito genererebbe.
  • Fissate una data di lancio reale, legata a un evento (una fiera, una campagna, il rinnovo dell’hosting). Le scadenze senza conseguenze slittano sempre.

Si può accelerare pagando di più?

In parte. Un fornitore può dare priorità al vostro progetto e allocare più persone in parallelo su design e sviluppo, ma il rendimento non è lineare: già nel 1975 Fred Brooks osservava in The Mythical Man-Month che aggiungere persone a un progetto software in ritardo lo fa ritardare ancora di più.

Soprattutto esiste un limite fisico: le fasi che dipendono dalle vostre approvazioni e dai vostri contenuti non si comprimono con il budget. Il metodo più efficace per accorciare i tempi resta ridurre il perimetro della prima versione.

Meglio pubblicare in sei settimane un sito con otto pagine fatte bene, e aggiungerne quattro in autunno, che aspettare cinque mesi per pubblicarne dodici tutte insieme.

E dopo la pubblicazione?

Il sito online non è la fine del progetto. I primi mesi servono a osservare i dati reali: quali pagine funzionano, dove le persone abbandonano, quali ricerche portano traffico. Anche il posizionamento organico ha tempi propri, e qui conviene citare la fonte diretta: Google scrive che servono in genere “da quattro mesi a un anno” da quando si iniziano a fare le modifiche a quando se ne vedono i benefici. Ne parliamo in l’articolo su SEO e sito web.

Se avete una scadenza precisa da rispettare, parlatecene all’inizio: si può quasi sempre costruire un percorso a rilasci successivi. Scriveteci o partite dal configuratore di preventivo, che oltre alla stima economica vi dà un’idea della complessità del progetto.