Download Word gratuito • Modifica online • Salva e condividi con Drive • Esporta in PDF
Un contratto di sviluppo del software personalizzato è un accordo legale che disciplina la relazione tra un cliente e uno sviluppatore (freelancer, consulente o agenzia) per la creazione di un software custom. Il contratto definisce le specifiche funzionali del software, il piano di sviluppo, le scadenze, i pagamenti, il rimborso delle spese, le responsabilità di entrambe le parti e le clausole su riservatezza e proprietà intellettuale. È disponibile in formato Word modificabile, pronto per essere personalizzato con i dati della tua azienda, dello sviluppatore, gli importi, i termini di pagamento e le specifiche del progetto. Puoi scaricarlo gratuitamente, compilarlo online o offline, e esportarlo in PDF quando è pronto per la firma.
Commissionare uno sviluppo software senza un contratto scritto è rischioso per entrambe le parti. Il cliente rischia di ricevere un software che non corrisponde alle aspettative, senza diritti di proprietà chiari o protezione in caso di ritardi e costi imprevisti. Lo sviluppatore rischia di ricevere critiche sul lavoro senza aver ricevuto specifiche dettagliate e approvate, oppure di non essere pagato se il cliente cambia idea. Un contratto scritto e sottoscritto dalle due parti crea chiarezza: definisce cosa si aspetta il cliente, quanto costa, quanto tempo serve, chi paga eventuali spese extra, e chi possiede il codice quando il progetto è finito. Protegge i tuoi investimenti e velocizza il progetto, perché tutte le parti sanno esattamente cosa fare, quando e per quanto. Se il valore del progetto è superiore a 2.000–3.000 euro oppure il software è critico per il tuo business, il contratto è indispensabile per evitare disputes legali e perdite economiche.
| Se la tua situazione è… | Usa questo modello |
|---|---|
| Progetto con requisiti incerti o che può evolvere durante sviluppo | Accordo a tempo e materiale |
| Progetto ben definito, ambito chiaro e volontà di costi predeterminati | Accordo a prezzo fisso |
| Progetti complessi che richiedono approvazione delle specifiche prima di iniziare | Con piano di sviluppo dettagliato |
| Piccoli incarichi di sviluppo sotto mille euro con documentazione minimale | Versione semplificata |
| Software che rimane proprietà del cliente o trasferimento di diritti | Con clausole sulla proprietà intellettuale |
| Include garanzie di disponibilità, performance e supporto post-sviluppo | Con service level agreement |
Perché conta: Quando il software è pronto, il cliente e lo sviluppatore litigano su cosa effettivamente era stato concordato, causando ritardi e costi extra.
Fix: Crea un Documento A molto dettagliato con screenshot, mockup, diagrammi, elenchi di funzionalità e criteri di accettazione chiari.
Perché conta: Il cliente rifiuta il piano senza una soluzione alternativa, lo sviluppatore chiede compenso, il contratto rimane bloccato e il progetto non decolla.
Fix: Inserisci un numero massimo di cicli di revisione (es. 2 revisioni gratuite, la 3ª è a pagamento) e una clausola di risoluzione con compenso limitato.
Perché conta: Lo sviluppatore fattura ore impreviste, il cliente ritiene di aver già pagato tutto, nasce conflitto sui pagamenti aggiuntivi.
Fix: Scegli una modalità unica (ore oppure fisso), indicala chiaramente, e se a prezzo fisso, dettaglia il calendario delle rate nel Piano di Sviluppo.
Perché conta: Lo sviluppatore presenta fatture per spese impreviste (viaggi, software, hosting) che il cliente non aveva previsto; conflitto su responsabilità.
Fix: Elenca le categorie di spesa ammesse, chiedi stime preventive e fissa un importo massimo mensile o totale.
Perché conta: Lo sviluppatore aspetta accessi che non arrivano, il progetto rimane fermo, gli attribuiscono il ritardo anche se la colpa è del cliente.
Fix: Crea una lista dettagliata di accessi, database, credenziali e dati; scrivi una data di fornitura realistica, concordata con il cliente.
Perché conta: Dopo il progetto, il cliente scopre che lo sviluppatore potrebbe rivendicare diritti sul codice oppure divulgare dati sensibili; conflitto legale.
Fix: Aggiungi una clausola che assegni la proprietà del software al cliente e che obblighi entrambe le parti a non divulgare informazioni aziendali senza consenso scritto.
In linguaggio semplice: Identifica il cliente, lo sviluppatore, il loro stato legale e il giorno in cui il contratto entra in vigore.
Il presente Contratto è concluso dal [DATA] tra [NOME DEL CLIENTE], con sede in [INDIRIZZO], e [IL NOME DELLA TUA IMPRESA], con sede in [IL TUO INDIRIZZO].
Errore comune: Non specificare lo stato/provincia di costituzione delle parti, rendendo incerta la giurisdizione applicabile.
In linguaggio semplice: Descrive in che qualità il cliente assume lo sviluppatore e che cosa il software deve fare.
Il Cliente desidera dare incarico allo Sviluppatore per sviluppare il software [DESCRIZIONE BREVE], secondo le Specifiche Funzionali di cui al Documento A.
Errore comune: Descrivere il software in modo troppo generico, senza collegare a documenti specifici o requisiti chiari.
In linguaggio semplice: Stabilisce che lo sviluppatore deve consegnare un piano che includa specifiche dettagliate, consegni, scadenze e calendario di pagamento.
Il Piano di Sviluppo dovrà comprendere: Specifiche Dettagliate per il Software; Un elenco dei Prodotti Consegnabili; Un piano di consegna con date precise; Un calendario di pagamento.
Errore comune: Non quantificare i giorni per la revisione o la modifica del piano, causando ritardi o dispute sui tempi.
In linguaggio semplice: Indica il processo e i tempi per cui il cliente approva il piano; una volta approvato, diventa parte del contratto.
Il Cliente avrà [NUMERO] giorni per rivedere il Piano. Se insoddisfatto, dovrà redigere una dettagliata obiezione entro [NUMERO] giorni. Lo Sviluppatore avrà [NUMERO] giorni per modificare il Piano.
Errore comune: Non prevedere una procedura di escalation se cliente e sviluppatore non riescono ad accordarsi sul piano, lasciando il contratto in sospeso.
In linguaggio semplice: Se il cliente risolve il contratto per insoddisfazione del piano, stabilisce come compensare lo sviluppatore per il lavoro già svolto.
Lo Sviluppatore avrà diritto al compenso a tariffa oraria di [TARIFFA ORARIA] per la preparazione del Piano, con limite massimo di [IMPORTO].
Errore comune: Non fissare un tetto massimo di compenso, rischiando che il costo della sola preparazione del piano diventi eccessivo.
In linguaggio semplice: Specifica la modalità retributiva: oraria oppure importo fisso per l'intero progetto, con termini di pagamento.
Tempo e Materiale: [AMMONTARE] l'ora. Prezzo Fisso: [IMPORTO INIZIALE] alla firma, [IMPORTO] dopo approvazione del Piano, resto a rate secondo il programma del Piano.
Errore comune: Non concordare per iscritto il modello di pagamento (fisso vs. orario), causando malintesi su fatturazione e importi dovuti.
In linguaggio semplice: Elenca le tipologie di spese (comunicazione, viaggi, database, multimedia) che il cliente rimborsa oltre al compenso.
Il Cliente rimborsa: Oneri di comunicazione, Costi di conversione database, Spese di viaggio [CENTESIMI PER MIGLIA], Costi multimediali, altre spese derivanti dal lavoro.
Errore comune: Non specificare quali spese sono rimborsabili, portando a conflitti quando lo sviluppatore presenta spese impreviste.
In linguaggio semplice: Stabilisce l'interesse mensile applicato agli importi non pagati entro la scadenza.
I ritardi nei pagamenti saranno soggetti a penale di ritardo del [%] al mese dalla data di scadenza fino al pagamento.
Errore comune: Omettere questa clausola oppure fissare una percentuale troppo bassa, riducendo l'incentivo del cliente a pagare puntualmente.
In linguaggio semplice: Elenca attrezzature, accesso a sistemi e materiali che il cliente deve fornire allo sviluppatore per il progetto.
Il Cliente dovrà mettere a disposizione dello Sviluppatore: [LISTA], da fornire entro il [DATA].
Errore comune: Non specificare la data di fornitura, causando ritardi nel progetto e dispute su chi è responsabile.
In linguaggio semplice: Protegge informazioni sensibili scambiate dalle due parti durante il progetto (non menzionata esplicitamente nel corpo, ma implicita).
Entrambe le parti si impegnano a mantenere riservate tutte le informazioni aziendali, dati e codice sviluppato durante il Contratto, salvo autorizzazione scritta dell'altra parte.
Errore comune: Non definire cosa sia considerato riservato o non stabilire una durata dell'obbligo, riducendo la protezione.
In linguaggio semplice: Regola come il cliente può richiedere cambiamenti alle specifiche e come questi influenzano tempi e costi.
Qualsiasi richiesta di modifica del Software dovrà essere presentata per iscritto allo Sviluppatore, che valuterà l'impatto su scadenze e compenso.
Errore comune: Permettere modifiche informali senza documentazione, rendendo impossibile tracciare cosa sia stato concordato.
In linguaggio semplice: Specifica le circostanze in cui una delle parti può interrompere il contratto e gli effetti della risoluzione.
Se il Piano di Sviluppo non venisse accettato, il Cliente potrà risolvere il Contratto con preavviso scritto, mantenendo obbligo di pagare quanto dovuto per il Piano.
Errore comune: Non differenziare tra risoluzione per insoddisfazione del piano e risoluzione per inadempimento, creando incertezza su diritti e doveri.
Scrivi il nome legale completo, la forma giuridica (s.r.l., s.p.a., ditta individuale) e l'indirizzo della sede legale di entrambi. Indica il giorno in cui il contratto entra in vigore.
💡 Usa il nome esatto come risulta nei documenti ufficiali o dal registro imprese; evita abbreviazioni o soprannomi.
Crea un documento dettagliato che descriva cosa deve fare il software, i requisiti tecnici, gli input/output, gli utenti e i casi d'uso. Allegalo come Allegato A.
💡 Più è specifico il documento, meno dispute avrai in fase di collaudo. Includi screenshot di mockup o prototipi se disponibili.
Decidi se pagare a ore (tempo e materiale) oppure a importo fisso. Se a ore, scrivi la tariffa. Se a importo fisso, scrivi l'importo totale e le rate.
💡 Progetti incerti convengono a ore; progetti ben definiti convengono a prezzo fisso per controllare il budget.
Specificare i giorni entro cui sviluppatore e cliente devono consegnare il piano, le revisioni e gli eventuali pareri. Esempio: 10 giorni per la revisione, 7 giorni per risposte.
💡 Usa numeri realistici; periodi troppo brevi causano stress, periodi troppo lunghi rallentano il progetto.
Specifica quale categorie di spese (viaggi, comunicazione, licenze, hosting) il cliente rimborsa oltre al compenso. Aggiungi limiti se necessario.
💡 Chiedi stime preventive delle spese; fissa un importo massimo per evitare sorprese in fattura.
Elenca accessi a sistemi, database, credenziali, hardware, librerie software o dati di cui lo sviluppatore ha bisogno. Scrivi la data entro cui vanno forniti.
💡 Coordinati con lo sviluppatore prima di firmare; un accesso mancante può bloccare il progetto per settimane.
Se il software rimane proprietà del cliente (caso più comune), specificalo. Se il cliente usa librerie open-source o codice di terzi, indicalo.
💡 Consulta un avvocato se il software contiene algoritmi, brevetti o know-how strategico per la tua azienda.
Leggi il contratto completo insieme allo sviluppatore, assicurati che tutti i [SEGNAPOSTI] siano compilati. Firma con firma digitale qualificata o autografa + copia.
💡 Conserva copia firmata per entrambe le parti; se possibile, fatti assistere da un avvocato per progetti sopra i 5.000 euro.
Un contratto di sviluppo software è consigliato quando il progetto dura più di poche settimane, ha un valore significativo (sopra i 2.000–3.000 euro), oppure quando il software andrà a supportare funzioni critiche della tua azienda. Se commissionai sviluppo a un freelancer per un semplice plugin di poche ore, puoi usare un ordine semplice; se commissioni un'applicazione custom, un gestionale o un e-commerce, il contratto è essenziale per proteggere entrambe le parti.
Con il tempo e materiale, paghi lo sviluppatore per ogni ora o giorno di lavoro; il costo totale dipende da quanto tempo serve effettivamente. È utile quando i requisiti non sono chiari o il progetto potrebbe evolvere, ma il budget è meno prevedibile. Con il prezzo fisso, concordi un importo totale prima di iniziare; lo sviluppatore consegna il software per quell'importo, indipendentemente dalle ore impiegate. Il prezzo fisso protegge il tuo budget, ma il progetto deve avere specifiche molto chiare.
La clausola di riservatezza obbliga sia il cliente che lo sviluppatore a non divulgare informazioni aziendali, codice sorgente, dati personali o algoritmi scambiati durante il progetto. Deve specificare quali informazioni sono considerate riservate, per quanto tempo rimangono riservate (es. 3 anni dopo la fine del contratto) e quali eccezioni esistono (es. se richiesto da un tribunale). Chiedi al tuo avvocato di inserire anche clausole sulla cancellazione di copie dei dati al termine del contratto.
Sì, ma dipende da come lo gestisci contrattualmente. Se il contratto è a prezzo fisso, le modifiche di rilievo al Piano di Sviluppo possono giustificare un aumento del compenso o una proroga delle scadenze. Se è a tempo e materiale, la modifica aumenta semplicemente le ore fatturabili. Il contratto deve prevedere una procedura: il cliente presenta la richiesta di modifica per iscritto, lo sviluppatore valuta l'impatto su tempi e costi, si concordano i dettagli. Modifiche informali o non documentate causano dispute su quanto era stato concordato.
Il Piano di Sviluppo è un documento che lo sviluppatore prepara dopo aver capito i tuoi bisogni. Contiene: specifiche tecniche dettagliate, lista dei "prodotti consegnabili" (es. codice, documentazione, training), scadenze per ogni fase, e calendario dei pagamenti. Tu hai un numero di giorni (es. 10) per revisionarlo. Se ti piace, lo approvi per iscritto e diventa parte vincolante del contratto. Se non ti piace, presenti obiezioni dettagliate entro un certo numero di giorni; lo sviluppatore avrà poi giorni per modificare e tu potrai rivedere di nuovo. Se ancora non siete d'accordo, il contratto prevede una procedura di escalation o la possibilità di risolvere con compenso limitato per la preparazione del piano.
Quando lo sviluppatore consegna il software, tu lo provi per verificare che rispetti le specifiche concordate nel Piano di Sviluppo. Se funziona correttamente, emetti una "accettazione" scritta (es. email). Se non funziona, descrivi i bug o i requisiti non soddisfatti per iscritto; lo sviluppatore avrà giorni per correggerli. Solo dopo l'accettazione formale, procedi con il pagamento finale se previsto. Documenta tutto: screenshot di test, email di accettazione, list di bug corretti. Questo protegge entrambi e chiarisce quando il progetto è veramente finito.
Il contratto dovrebbe specificare cosa succede: il cliente può chiedere una spiegazione scritta, estendere le scadenze se le cause sono del cliente (accessi mancanti, requisiti non chiari), o in caso di inattività prolungata dello sviluppatore, risolvere il contratto e chiedere rimborso (almeno parziale) delle somme già versate. Se il ritardo è critico per il tuo business, puoi anche includere una "penale per il ritardo" (importo forfettario o percentuale giornaliera) che lo sviluppatore deve pagare se consegna in ritardo. Consulta un avvocato per clausole di questo tipo se il valore del progetto è alto.
Il contratto deve specificarlo chiaramente. Nel caso più comune e consigliato, tutto il software sviluppato diventa proprietà del cliente (tu). Lo sviluppatore cede tutti i diritti; non può usare il codice per altri clienti o venderlo. Se lo sviluppatore usa librerie open-source o codice di terzi, deve documentarlo e assicurarsi che la licenza sia compatibile con il tuo uso. Se il software include algoritmi, brevetti o know-how strategico, consulta un avvocato per proteggere ulteriormente i diritti.
Il contratto dovrebbe limitare il numero di cicli di revisione, ad esempio 2 revisioni gratuite incluse nel compenso del Piano di Sviluppo, e ogni revisione ulteriore a pagamento (a tariffa oraria oppure importo fisso). Questo incentiva entrambe le parti a essere chiare nei requisiti iniziali. Se il numero di revisioni è illimitato, il Piano di Sviluppo diventa un progetto infinito e lo sviluppatore non può mai iniziare il lavoro vero. Se non concordate un numero nel contratto, usa il buon senso: 2–3 cicli di revisione sono ragionevoli per un progetto medio.
Un ordine di lavoro è sufficiente per piccoli incarichi di poche ore (es. correzione di bug, modifica minore). Un contratto di sviluppo software è necessario per progetti di settimane o mesi, perché include specifiche dettagliate, piano di sviluppo, procedure di approvazione, e protezioni legali su riservatezza e proprietà intellettuale. Se il progetto vale più di 2.000–3.000 euro oppure è critico per il tuo business, scegli il contratto.
Un accordo di servizi IT generico copre manutenzione, supporto e consulenza continua. Un contratto di sviluppo software è specifico per la creazione di un nuovo software con specifiche, scadenze e consegni definiti. Se commissionai sviluppo custom oppure una versione custom di un software esistente, usi il contratto di sviluppo; se commissionai supporto, manutenzione o consulenza ricorrente, usi un accordo di servizi.
Una lettera di intenti è un documento breve e non vincolante che il cliente e lo sviluppatore sottoscrivono per esprimere l'intenzione di collaborare prima di negoziare il contratto definitivo. Una lettera di intenti non è un contratto; il contratto di sviluppo software è il documento legalmente vincolante che regola il progetto. Se vuoi muoverti rapidamente, puoi partire con una LOI seguita poi dal contratto completo.
Questo template è generico, adatto sia a freelancer che ad agenzie. Se tratti con un'agenzia grande, è possibile che propongano il loro contratto standard; puoi usare questo template come base per negoziare condizioni migliori. Se negozi con un freelancer, questo template è più equilibrato e pone le due parti su un piano paritario."
Template diretto per agenzie di sviluppo, consulenti IT e freelancer che commissionano progetti software.
Essenziale per lo sviluppo di piattaforme e-commerce, app di vendita online e sistemi di gestione inventario personalizzati.
Applica a sviluppo di software bancario, gestionali contabili custom, piattaforme di trading; richiede enfasi su sicurezza e conformità normativa.
Regola lo sviluppo di software per automazione di impianti, gestione della produzione, IoT e sistemi di controllo di qualità.
Disciplina lo sviluppo di cartelle cliniche digitali, app mediche e sistemi di gestione dei pazienti con enfasi su privacy e protezione dati.
Applica a gare e appalti per sviluppo software pubblico, con clausole su trasferimento di proprietà, certificazioni e conformità normativa.
Questo contratto segue la legge italiana, con specifiche riferite al Codice Civile, al diritto d'autore (L. 633/1941) e alla normativa sulla protezione dei dati (GDPR). È adatto a sviluppatori e clienti italiani, oppure a situazioni in cui una parte è italiana e il contratto sceglie la legge italiana come applicabile.
Per contratti con sviluppatori o clienti in Ticino (Svizzera), il template italiano è largamente compatibile, ma la giurisdizione dovrebbe essere scelta in accordo reciproco. Si consiglia di specificare nel contratto se applies il diritto italiano (per semplicità) oppure il diritto svizzero (Codice Obbligazioni). Verifica con un avvocato ticinese se il progetto è di rilievo.
| Percorso | Ideale per | Costo | Tempo |
|---|---|---|---|
| Usa il modello | Progetti di sviluppo sotto i 5.000 euro, con sviluppatore affidabile, specifiche chiare e rischio basso. | 0 euro (download gratuito); 0–50 euro se personalizzi con consulenza online. | 1–2 ore per adattare il template e compilare i dati. |
| Modello + revisione legale | Progetti di 5.000–20.000 euro, requisiti complessi, oppure rapporto con sviluppatore per la prima volta. | 300–600 euro per revisione legale di base; 600–1.200 euro se include consulenza negoziale. | 2–3 ore per adattare il template; 2–3 giorni per revisione legale. |
| Redatto su misura | Progetti oltre i 20.000 euro, software critico o ad alta complessità, nuove partnership strategiche. | 1.200–2.500 euro per stesura completamente personalizzata; 2.500–5.000 euro se include negoziazione. | 5–7 giorni per negoziazione e finalizzazione. |
Questo documento è uno dei 3,000+ modelli aziendali e legali inclusi in Business in a Box.
Accedi a oltre 3,000+ modelli aziendali e legali per qualsiasi attività, progetto o iniziativa.
Personalizza il tuo modello di documento aziendale pronto all'uso e salvalo nel cloud.
Condividi i tuoi file e cartelle con il tuo team. Crea uno spazio di collaborazione fluida.
"Idea fantastica! Non so come farei senza. Vale ogni centesimo, e come investimento si è ripagato più volte."
"Ho usato Business in a Box per 4 anni. È stata la fonte di modelli più utile che abbia mai trovato. Lo raccomando a chiunque."
"Mi ha salvato la vita così tante volte che ho perso il conto. Business in a Box mi ha fatto risparmiare tantissimo tempo e, come sapete, il tempo è denaro"
Smetti di scaricare documenti. Inizia a operare con chiarezza. Business in a Box ti offre il sistema operativo aziendale utilizzato da oltre 250.000 aziende in tutto il mondo per strutturare, gestire e far crescere la tua attività.
Piano gratuito per sempre · Nessuna carta di credito richiesta
