Download Word gratuito • Modifica online • Salva e condividi con Drive • Esporta in PDF
Un contratto tra cliente e sviluppatore è un accordo legale che formalizza i termini e le condizioni di un incarico di sviluppo software, programmazione, analisi di sistemi o servizi informatici correlati. Il contratto stabilisce diritti e obblighi di entrambe le parti, proteggendo il cliente sulla proprietà del codice e lo sviluppatore sul compenso e sulla proprietà intellettuale preesistente. È disponibile come download Word completamente modificabile, esportabile in PDF, e pronto per essere compilato con i dati specifici del vostro progetto.
Il modello copre tipi di progetto diversi — da un incarico a prezzo fisso (con deliverable e importo definiti) a un progetto su base tempo e materiale (pagamento orario o giornaliero) — ed è strutturato attorno a una Dichiarazione di Lavoro (SOW) allegata che descrive il progetto nel dettaglio. Include definizioni complete di ruoli, clausole su proprietà intellettuale, riservatezza, pagamenti e accettazione del lavoro, così da proteggere sia il cliente che lo sviluppatore da dispute e malintesi durante e dopo l'esecuzione.
Assegnare un progetto di sviluppo software senza un contratto espone il tuo business a rischi legali e finanziari significativi. Senza un accordo formale, non è chiaro chi possiede il codice sviluppato: il cliente crede di essere proprietario, ma lo sviluppatore potrebbe rivendicare diritti di copyright e riutilizzare il software per altri clienti o concorrenti. Allo stesso modo, non è chiaro cosa lo sviluppatore deve consegnare, quando, a quale prezzo e con quali revisioniammesse: questa vaghezza genera scope creep infinito, dispute sul pagamento e progetti che slittano indefinitamente.
Un contratto professionale e ben scritto elimina questi rischi formalizzando scope, deliverable, timeline, pagamenti e diritti di proprietà intellettuale. Protegge il cliente assicurando che il codice e la documentazione consegnati siano di sua esclusiva proprietà, e che lo sviluppatore non lo riutilizzi per rivali o lo divulghi a terzi. Allo stesso tempo, protegge lo sviluppatore salvaguardando il suo diritto al compenso, la proprietà dei suoi strumenti preesistenti, e il diritto di non essere vincolato a divieti di non-concorrenza eccessivi o irrealistici. In breve: un contratto chiaro è il fondamento di una relazione professionale che funziona.
| Se la tua situazione è… | Usa questo modello |
|---|---|
| Scope ben definito, deliverable chiari, pagamento unico o a milestone predefinite | Progetto a prezzo fisso |
| Requisiti fluidi, lavoro orario tracciato, pagamento mensile o su fatturazione periodica | Progetto tempo e materiale |
| Focus su interfaccia utente, integrazione API, deployment in cloud | Sviluppo web e applicazioni mobile |
| Audit, design architetturale, migrazione dati senza sviluppo custom | Analisi di sistemi e consulenza tecnica |
| Supporto post-lancio, bug fix, aggiornamenti periodici con SLA | Manutenzione e supporto continuativo |
| L'agenzia principale subappalta parti del progetto; necessita clausola su sub-sviluppatori riconosciuti | Sviluppo con sub-fornitori |
Perché conta: Il contratto generale è vuoto senza una SOW; il cliente non sa cosa aspettarsi e lo sviluppatore non sa cosa consegnare, causando dispute infinite.
Fix: Redigi una SOW separata con scope, deliverable specifici, timeline, criteri di accettazione, e allegala al contratto prima della firma.
Perché conta: Senza una clausola esplicita, sorge il dubbio legale su chi possiede il codice e i diritti: il cliente crede di possedere il software ma lo sviluppatore lo rivendica.
Fix: Specifica che tutto il codice sviluppato nel progetto appartiene al Cliente; l'IP preesistente dello Sviluppatore rimane suo e può essere riutilizzato.
Perché conta: Senza una linea netta, nascono dispute sulla fatturazione: il cliente non sa se paga il totale fisso o se aggiungere ore extra, e lo sviluppatore non sa il budget.
Fix: Scegli uno dei due modelli per progetto; se un sub-componente cambia, ridefinisci il SOW e il prezzo con un Ordine di Modifica scritto.
Perché conta: Se il cliente non ha una persona designata per approvare il lavoro, lo sviluppatore riceve ordini contraddittori da più contatti, causando ritardi e costi extra.
Fix: Nomina formalmente un Coordinatore Tecnico del Cliente nel contratto; tutti gli input tecnici e approvazioni passano da lui.
Perché conta: Lo sviluppatore potrebbe usare il codice per un concorrente diretto, rivelare strategie aziendali, o copiare il progetto; il cliente perde il vantaggio competitivo.
Fix: Includi clausole di riservatezza forte (durata almeno 2-3 anni dopo il progetto) e vieta il lavoro per concorrenti diretto durante il progetto + periodo lock-out.
Perché conta: Quando il lavoro è 'completo'? Lo sviluppatore chiede pagamento ma il cliente vuole revisioni indefinite; non c'è una procedura formale per chiudere il progetto.
Fix: Crea un processo di accettazione nella SOW: il cliente ha X giorni per approvare o richieste revisioni specifiche; dopo l'approvazione, il deliverable è accettato e il pagamento è dovuto.
In linguaggio semplice: Chiarisce i significati di termini chiave come 'Contratto', 'Sviluppatore', 'Cliente', 'Progetto', 'Documentazione' e 'Software' per evitare malintesi nell'esecuzione.
Con il termine 'Contratto' si intendono i termini e le condizioni, tutti i Documenti allegati, e qualsiasi altro documento parte del presente Contratto o incorporati per riferimento, comprese le eventuali modifiche scritte sottoscritte dai Firmatari Autorizzati di entrambe le parti.
Errore comune: Non definire con precisione cosa sia 'Documentazione' o 'Software', creando dispute su cosa deve essere consegnato.
In linguaggio semplice: Nomina e identifica formalmente il Cliente e lo Sviluppatore, con relative sedi legali e rappresentanti autorizzati.
[IL NOME DELLA TUA IMPRESA] (il 'Cliente'), una persona giuridica costituita e regolata in conformità alle leggi di [Stato/Provincia], avente sede legale in: [IL TUO INDIRIZZO COMPLETO].
Errore comune: Usare nomi informali o non indicare la sede legale corretta, rendendo il contratto vago e difficile da esecutore in giudizio.
In linguaggio semplice: Specifica che lo Sviluppatore fornisce servizi di programmazione, analisi di sistemi e servizi correlati secondo le Dichiarazioni di Lavoro (SOW) concordate.
Lo Sviluppatore esegue programmi e servizi di analisi dei sistemi; il Cliente desidera avvalersi della programmazione dello Sviluppatore e i servizi di analisi dei sistemi.
Errore comune: Essere troppo vago sui servizi; le SOW separate devono integrare con specifiche tecniche esatte per evitare scope creep.
In linguaggio semplice: Distingue tra Progetti a Prezzo Fisso (con deliverable specifici e prezzo concordato) e Progetti Tempo & Materiale (pagamento su base oraria/giornaliera).
Un 'Progetto Prezzo Fisso' è un Progetto nell'ambito del quale lo Sviluppatore fornisce al Cliente del Lavoro il cui pagamento è basato su Prodotti di Lavoro specifici da fornire, il cui prezzo è indicato nel Documento B.
Errore comune: Mescolare i due modelli in un unico progetto senza una chiara demarcazione, causando dispute su obbligazioni di pagamento.
In linguaggio semplice: Stabilisce che l'IP sviluppato nel progetto appartiene al Cliente, mentre l'IP preesistente dello Sviluppatore (framework, tool, librerie) rimane dello Sviluppatore.
'IP Preesistenti dello Sviluppatore' sono tutti i diritti di proprietà intellettuale di proprietà dello Sviluppatore che (A) anticipano la Data della Dichiarazione di Lavoro oppure (B) si verificano solo come risultato di sviluppo indipendente e non dell'esecuzione del presente Contratto.
Errore comune: Non chiarire quale IP appartiene a chi, creando contenziosi legali su diritti d'autore e brevetti sul software consegnato.
In linguaggio semplice: Vincola entrambe le parti a non divulgare dati, codice sorgente, specifiche e strategie dell'altra parte a terzi senza autorizzazione.
Le 'Informazioni Riservate' sono tutte le informazioni comunicate tra le parti relative al progetto, incluso codice, architettura, dati del cliente, che non possono essere divulgate a concorrenti o terze parti.
Errore comune: Non includere clausole di riservatezza specifiche; lo sviluppatore potrebbe usare il codice per altri clienti o rivelare strategie aziendali.
In linguaggio semplice: Chiarisce che i dipendenti dello Sviluppatore e i sub-fornitori non sono dipendenti del Cliente, e definisce il ruolo del 'Sub-Sviluppatore Riconosciuto'.
Il 'Personale di Sviluppo' comprende tutti i dipendenti, agenti e Sub Sviluppatori dello Sviluppatore; in nessun caso tali persone saranno considerate dipendenti del Cliente.
Errore comune: Non distinguere il rapporto contrattuale; il cliente potrebbe essere ritenuto responsabile dei diritti del lavoro dello sviluppatore.
In linguaggio semplice: Nomina un Coordinatore Tecnico del Cliente responsabile di sovrintendere il lavoro e comunicare con lo Sviluppatore.
Il 'Coordinatore Tecnico del Cliente' è il dipendente del Cliente assegnato per sovraintendere e coordinare l'attività lavorativa con lo Sviluppatore.
Errore comune: Non nominare un contatto unico, creando confusione su chi approva i deliverable e autorizza pagamenti.
In linguaggio semplice: Vieta allo Sviluppatore di fornire servizi ai concorrenti diretti del Cliente durante l'esecuzione del contratto, con eccezioni negoziate.
Un 'Concorrente del Cliente' è qualsiasi entità che faccia parte dell'attività in qualsiasi parte del mondo, incluso [SPECIFICARE] e qualsiasi affiliato, purché [IL FORNITORE DEL SERVIZIO] e le imprese affiliate non siano considerati Concorrenti.
Errore comune: Non definire chiaramente chi è 'concorrente'; lo sviluppatore potrebbe lavorare per rivali senza violazione tecnica.
In linguaggio semplice: Specifica che tutta la documentazione (codice sorgente, diagrammi, manuali, specifiche) generata durante il progetto è parte dei deliverable e appartiene al Cliente.
La 'Documentazione' include tutto il materiale generato dallo Sviluppatore: sintesi di Software, diagrammi di flusso, codice sorgente, specifiche tecniche, manuali, guide per l'installazione e qualsiasi materiale di supporto.
Errore comune: Dimenticare di includere la documentazione come deliverable; il cliente riceve il software ma non i diagrammi o i manuali di manutenzione.
In linguaggio semplice: Descrive il processo formale di accettazione dei deliverable, con revisioni e criteri di conformità definiti nella SOW.
L'Accettazione dei Prodotti di Lavoro è basata sul soddisfacimento dei criteri specificati nella Dichiarazione di Lavoro e nei Documenti Necessari concordati.
Errore comune: Mancanza di una procedura di accettazione formale; le dispute nascono su quando il lavoro è 'completato' per richiedere il pagamento.
Compila il nome completo della tua azienda (Cliente), la provincia di registrazione, l'indirizzo legale. Fai lo stesso per lo Sviluppatore (nome, sede, rappresentante legale). Questi dati vanno nella sezione iniziale 'TRA'.
💡 Usa l'indirizzo legale registrato in Camera di Commercio, non l'indirizzo operativo; è più importante legalmente.
Indica il nome completo e la qualifica di chi firma il contratto per conto del Cliente e dello Sviluppatore. Questo deve essere un amministratore, direttore o chi ha poteri di rappresentanza.
💡 Verifica che il firmatario abbia potere di firma; un contratto firmato senza autorità non è valido.
Scegli se il progetto è a Prezzo Fisso (con deliverable e prezzo definiti) o Tempo & Materiale (pagamento orario/giornaliero). Questa scelta determina la struttura di pagamento.
💡 Prezzo Fisso = meno rischio per il Cliente ma più rischio per lo Sviluppatore. T&M = trasparenza oraria ma costi variabili.
La SOW è il documento che descrive nel dettaglio il progetto: scope, deliverable, timeline, criteri di accettazione e prezzo. Deve essere allegata e concordata prima della firma.
💡 Una SOW vaga è la causa numero uno di contenziosi; più è dettagliata e più sono protette entrambe le parti.
Se è Prezzo Fisso, indica il prezzo totale e le milestone di pagamento. Se è T&M, compila il Documento B con le tariffe orarie/giornaliere e i limiti di budget.
💡 Per progetti lunghi, richiedi pagamenti a milestone per ridurre il rischio di mancato pagamento.
Nomina un dipendente del Cliente che farà da punto di contatto con lo Sviluppatore per approvazioni tecniche, comunicazioni di progetto e accettazione deliverable.
💡 Un buon coordinatore evita ritardi e confusione; assicurati che abbia tempo dedicato.
Se applicabile, elenca i concorrenti diretti per cui lo Sviluppatore NON può lavorare durante il progetto. Sii realistico: elenchi troppo lunghi potrebbero essere contestati.
💡 Limita la restrizione al periodo del progetto + un periodo di lock-out ragionevole (es. 6 mesi dopo); restrizioni infinite sono difficili da imporre.
Assicurati che le clausole su Informazioni Riservate e IP Preesistenti riflettano cosa vuoi proteggere. Se usi framework open source, indicalo esplicitamente.
💡 Se lo Sviluppatore usa librerie open source con licenza copyleft (es. GPL), il cliente potrebbe ereditare obblighi di licenza; discuti in anticipo.
Il contratto deve includere una data di consegna nella SOW con conseguenze chiare: penalità di ritardo, diritto di rescissione, o ricalcolo del prezzo per T&M. Specifica se la data è vincolante o indicativa. Se non è indicato, il cliente avrà diritto a danno forfetario o rescissione solo se il ritardo è colposo dello sviluppatore. Consulta un avvocato per includere clausole di penalità realistiche.
Se il progetto è a Prezzo Fisso, un cambio di requisiti è una modifica del scope e deve essere autorizzato per iscritto con aumento di prezzo o di timeline. Se il progetto è T&M, il costo extra è incluso nelle ore fatturate. La SOW deve chiarire il processo di richiesta modifica: il cliente invia un Change Request formale, lo sviluppatore stima l'impatto (tempo/costo), entrambi approvano per iscritto, e poi si lavora sulla modifica.
Il contratto deve specificare una clausola di ritenzione: lo sviluppatore non consegna il codice sorgente fino al pagamento finale. Se il cliente non paga una milestone, lo sviluppatore può sospendere il lavoro. In caso di disputa, il codice rimane in possesso dello sviluppatore finché il pagamento non è saldato, a meno che una sentenza non ne ordini diversamente. Consulta un avvocato per formalizzare questa clausola.
Dipende dal contratto. Se include una clausola di Non-Concorrenza (vedi sezione 'Concorrenti del Cliente'), lo sviluppatore non può lavorare per i tuoi rivali diretti durante il progetto e per un periodo successivo concordato (es. 6-12 mesi). Se il contratto non la include, lo sviluppatore è libero di lavorare per chiunque. Se vuoi esclusività, aggiungi questa clausola e negozia un compenso aggiuntivo per lo sviluppatore.
Sono strumenti, librerie, framework, moduli, template, o altro codice/proprietà intellettuale che lo sviluppatore ha creato PRIMA di questo progetto e che possiede già. Ad esempio, se lo sviluppatore ha una libreria di autenticazione usata in 10 progetti, questa rimane proprietà dello sviluppatore anche se la usa per il tuo progetto. È importante specificare cosa conta come IP preesistente nel contratto: se lo sviluppatore riutilizza il suo codice, il cliente accetta la licenza d'uso ma non la proprietà.
Una buona SOW include: (1) descrizione chiara dello scope e dei deliverable; (2) timeline e date milestone; (3) criteri di accettazione tecnica (quante ore di testing, quali browser/device, performance target, ecc.); (4) prezzo totale e calendario di pagamento; (5) chi approva quale lavoro; (6) cosa succede se i requisiti cambiano. Più è dettagliata la SOW, meno dispute sulla consegna finale.
Dipende dai termini. Il contratto deve includere una clausola di rescissione: se è a volontà di entrambi, ogni parte può uscire con un preavviso (es. 30 giorni). Se è a termine fisso, una rescissione anticipata potrebbe richiedere il pagamento di una penalità o dei costi sostenuti. Per T&M, il cliente può di solito rescindere fornendo un breve preavviso. Per Prezzo Fisso, è più complesso: il cliente potrebbe aver bisogno di causa (mancanza grave dello sviluppatore) o di negoziare una compensazione. Consulta un avvocato per le clausole di exit.
Il contratto deve includere una clausola di danno forfetario (es. multa per violazione di riservatezza) e una clausola di risarcimento danni. Se lo sviluppatore divulga il tuo codice o le tue strategie, puoi chiedere il pagamento della multa concordata più i danni effettivi (perdita di mercato, costi di ri-sviluppo, ecc.). Per proteggere il tuo diritto, documentate subito la violazione con prove (email, prove della divulgazione) e notificate allo sviluppatore per iscritto. La clausola di riservatezza deve durare almeno 2-3 anni dopo la fine del progetto.
Il contratto e la SOW devono definire il periodo di garanzia (warranty period): ad esempio, 30 o 60 giorni dopo la consegna e accettazione. Durante questo periodo, lo sviluppatore ripara i bug gratuitamente. Dopo la garanzia, i bug sono costi di manutenzione extra, a meno che non sia incluso un contratto di supporto continuativo. È importante che la SOW specifichi cosa è un 'bug' (deviazione dalle specifiche concordate) vs. una 'feature richiesta' (nuovo requisito).
Un MSA è un contratto quadro che fissa i termini generali tra cliente e fornitore per una relazione a lungo termine con più progetti. Un Contratto Cliente-Sviluppatore è specifico per un progetto unico, con deliverable definiti. Se hai una relazione continuativa (es. supporto annuale con più release), usa un MSA + SOW per progetto. Se è un progetto singolo (es. sviluppo di un'app), usa direttamente questo contratto con una SOW allegata.
Una lettera di incarico è un documento informale e breve, adatto a consultazioni iniziali o incarichi minori. Questo contratto è formale, completo e legalmente vincolante. Se il progetto è complesso, coinvolge IP, richiede NDA e tiene mesi/anni, usa questo contratto. Se è una consulenza breve (es. "dammi 2 ore di advice"), basta una lettera di incarico.
Un NDA è un contratto a sé stante che protegge solo la riservatezza; non affronta pagamento, deliverable, timeline. Questo contratto include clausole di riservatezza integrate. Se hai una relazione pre-contrattuale con uno sviluppatore e vuoi discutere di idee sensibili prima di firmare il contratto, usa un NDA. Poi allegati il NDA al contratto principale.
Una SOW è un documento tecnico che descrive il cosa, come, quando e quanto di un progetto specifico. Un Contratto Cliente-Sviluppatore è il framework legale che stabilisce obbligazioni, responsabilità e diritti. In pratica, usa entrambi: il contratto come base legale permanente, la SOW come allegato tecnico per ogni progetto. Se hai progetti ripetuti, il contratto rimane uguale; la SOW cambia per ogni incarico.
Questo contratto standardizza i termini con clienti aziendali, proteggendo la proprietà intellettuale dell'agenzia e chiarendo scope, timeline e pagamenti per evitare contenziosi ricorrenti.
Una startup che commissiona sviluppo a fornitori esterni (backend, mobile, AI) usa questo contratto per proteggere il proprio codice, il marchio e le strategie, limitando il riutilizzo da parte dello sviluppatore.
Un'azienda manifatturiera o commerciale che digitalizza i processi (ERP, app interna) usa questo contratto per assicurarsi che il software consegnato sia di sua proprietà e che il fornitore non lo rivenda a concorrenti.
Un'azienda di consulenza che offre servizi di analisi, design e implementazione di sistemi usa questo contratto per formalizzare il rapporto con i clienti corporate, con clausole su SLA, manutenzione e supporto.
Uno sviluppatore freelance usa questo contratto come cliente (commissiona lavoro a sub-fornitori) o come fornitore (protegge il proprio IP preesistente e i diritti di pagamento), a seconda del ruolo nel progetto.
Un ente pubblico che commissiona sviluppo di software usa questo contratto per garantire il proprio controllo sul codice e sulla documentazione, con clausole su trasparenza, dati aperti e archivi pubblici.
Questo contratto è redatto secondo le norme del diritto civile italiano e applica la Legge italiana in materia di diritto d'autore (D.Lgs 633/1941), contratti (Codice Civile artt. 1321-1469), e proprietà intellettuale (Codice della Privacy, norme su dati). È adatto a rapporti tra Cliente italiano e Sviluppatore italiano, o tra imprese EU quando è applicabile la legge italiana per accordo. Personalizza con le province di registrazione delle parti.
In Svizzera (Ticino), il contratto s'applica se entrambe le parti sono svizzere e scelgono il diritto svizzero, oppure se è applicabile il Codice delle obbligazioni svizzero (CO). I principi di proprietà intellettuale, riservatezza e pagamenti sono simili ma la procedura di impugnazione varia. Consulta un avvocato ticinese se il cliente è CH per adattamenti su currency (CHF), legge vigente, e giurisdizione (tribunale di Lugano o Bellinzona).
| Percorso | Ideale per | Costo | Tempo |
|---|---|---|---|
| Usa il modello | Progetto semplice, sviluppatore freelance affidabile, budget limitato, relazione a basso rischio. | €0 (scarica il modello); 1-2 ore di compilazione interna. | 2-3 giorni (compilazione e approvazione interno); firma in 1 settimana. |
| Modello + revisione legale | Progetto di media complessità, importo significativo (>€10.000), voglia protezione legale extra senza costi di redazione completa. | €0 (modello) + €500–€1.200 (revisione avvocato); totale €500–€1.200. | 3-5 giorni di compilazione + 3-5 giorni di revisione legale; firma in 2 settimane. |
| Redatto su misura | Progetto complesso e alto valore (>€50.000), tecnologia critica (AI, fintech, dati sensibili), relazione pluriennale, voglia massima protezione. | €2.000–€5.000+ (redazione completa da avvocato); eventualmente +€500–€1.000 se include supporto nell'esecuzione. | 7-10 giorni (brief dell'avvocato + redazione iterativa + approvazione). Firma in 3-4 settimane. |
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à.
Inizia gratis · Nessuna carta di credito richiesta
