Cosa chiedere prima di firmare un preventivo web

Il preventivo non è solo un prezzo: è un contratto

Un preventivo serio non è un numero su un foglio. È un documento contrattuale che descrive cosa verrà fatto, come, in quanto tempo e con quali condizioni. Eppure, la maggior parte dei clienti firma preventivi web senza fare le domande giuste — e i problemi emergono inevitabilmente a progetto avviato, quando le opzioni sono limitate e i costi per cambiare rotta sono alti.

Investire 15-30 minuti a fare le domande giuste prima di firmare può risparmiare settimane di discussioni e migliaia di euro di costi imprevisti dopo. Ecco le domande che fanno la differenza, organizzate per area.

Domande sullo scope: cosa è incluso e cosa no?

La causa numero uno dei conflitti tra cliente e sviluppatore è il disallineamento sullo scope: il cliente pensa che qualcosa sia incluso, lo sviluppatore pensa di no. Ecco le domande da fare:

• L'hosting è incluso? Per quanto tempo? Su quale provider? Con quali specifiche tecniche?
• Il dominio è incluso? Chi lo registra e a nome di chi?
• La SEO base è inclusa? Meta tag, sitemap, robots.txt, markup strutturato — o è un extra?
• I contenuti chi li scrive? Se li scrive lo sviluppatore, sono inclusi nel prezzo?
• La formazione è inclusa? Quanto tempo per insegnarti a usare il pannello admin?
• Il responsive è incluso? Dovrebbe essere ovvio nel 2026, ma meglio verificare

La regola d'oro: se non è scritto nel preventivo, non è incluso. Non importa cosa è stato detto a voce: conta quello che c'è nel documento firmato.

Domande sulle revisioni: quante e come?

Le revisioni sono il terreno più scivoloso di ogni progetto web. Senza limiti chiari, si entra nel loop infinito del "cambia questo, sposta quello, aggiungi quest'altro" che fa esplodere tempi e costi.

• Quante revisioni sono incluse? In genere 2-3 round sono ragionevoli per design e contenuti
• Cosa succede dopo il numero previsto? Si paga a ore? C'è un costo fisso per revisione aggiuntiva?
• Come si inviano i feedback? Email, documento condiviso, tool di annotazione? Un processo strutturato riduce i malintesi
• Qual è il tempo massimo per fornire feedback? Se il cliente non risponde per 3 settimane, il progetto si blocca — e lo sviluppatore nel frattempo ha preso altri lavori

Domande sulla proprietà: di chi è il codice?

Questa è forse la domanda più importante e la più trascurata. Alla fine del progetto, chi possiede cosa?

• Il codice sorgente è di mia proprietà? La risposta corretta è "sì, al saldo della fattura"
• Avrò accesso al repository Git? Se lo sviluppatore sparisce, devi poter continuare con un altro
• Le credenziali di hosting e dominio sono intestate a me? Hosting e dominio devono essere a tuo nome o della tua azienda
• Posso cambiare sviluppatore in futuro? Non devi essere vincolato a vita a un fornitore

Se uno sviluppatore ti dice che il codice resta suo e tu paghi solo una "licenza d'uso", è un red flag enorme. Stai pagando per un prodotto custom: quel prodotto è tuo.

Domande su tempi e pagamenti

Tempistiche

• Qual è la data di consegna prevista? Non "circa un mese" ma una data specifica
• Qual è il margine di ritardo accettabile? Una settimana? Due? Cosa succede se si sfora?
• Ci sono milestone intermedie? Vedere il progetto solo alla fine è rischioso: meglio checkpoint regolari
• I tempi tengono conto dei miei tempi di risposta? Se ci metti una settimana a rispondere, i tempi si allungano — e non è colpa dello sviluppatore

Pagamenti

• Qual è la struttura dei pagamenti? Il modello più comune è: 30-40% di acconto, 30% a milestone intermedia, 30% a consegna. Evita di pagare tutto in anticipo
• Cosa succede se interrompo il progetto? L'acconto è rimborsabile? Le ore lavorate vanno pagate?
• Ci sono costi ricorrenti? Hosting, manutenzione, licenze — tutto deve essere esplicito

Domande sulla manutenzione post-lancio

• È previsto un periodo di garanzia? In genere 30-90 giorni per correggere bug emersi dopo il lancio
• Offri pacchetti di manutenzione? Se sì, cosa includono e quanto costano?
• Qual è il tempo di risposta per le emergenze? 4 ore? 24 ore? 48 ore? Dipende dal livello di servizio
• Chi gestisce gli aggiornamenti di sicurezza? PHP, dipendenze, certificati SSL — qualcuno deve occuparsene

Segnali di un buon preventivo

Un preventivo trasparente e professionale ha queste caratteristiche:

• Voci dettagliate: non un prezzo unico ma una scomposizione per area (design, sviluppo, contenuti, test)
• Esclusioni esplicite: cosa NON è incluso, scritto nero su bianco
• Tempi realistici: con margine per imprevisti, non promesse aggressive
• Condizioni chiare: pagamenti, revisioni, proprietà, recesso — tutto documentato
• Validità limitata: un preventivo valido 30 giorni è normale; uno senza scadenza è sospetto

Se il preventivo è vago, non elenca le esclusioni, promette risultati irrealistici o è troppo bello per essere vero — probabilmente lo è. Un preventivo serio protegge entrambe le parti: cliente e sviluppatore. Investire tempo nella fase pre-contrattuale è il miglior investimento che puoi fare per il successo del progetto.