Freelance o Agenzia di Sviluppo Software: Guida 2026

Come scegliere il fornitore giusto: costi reali, fattori di rischio, quando assegnare frontend e backend a due fornitori, e quando serve uno specialista UI/UX

La scelta fra un freelance e un'agenzia di sviluppo software viene quasi sempre affrontata come un confronto di preventivi, e quasi sempre è la domanda sbagliata. Le due formule non vendono la stessa cosa: con un freelance compri una persona e la sua competenza, con un'agenzia compri una struttura e la sua continuità. Quale delle due convenga dipende da cinque variabili — durata prevista, ampiezza delle competenze necessarie, quanto è definito il perimetro, quanto costa un fermo e chi gestirà il software fra due anni — e nessuna di queste compare in un preventivo.

Questa guida mette in fila i criteri di scelta con i dati che esistono davvero, e dice chiaramente quali dei numeri più citati in rete non hanno una fonte verificabile. Affronta poi le due domande che nella pratica pesano più della prima: quando conviene separare il frontend dal backend affidandoli a fornitori diversi — una decisione che secondo una legge nota da quasi sessant'anni finisce inevitabilmente dentro l'architettura del prodotto — e quando serve un professionista dedicato di UI/UX, che in Italia costa meno di quanto si creda e che dal 2025 non è più solo una scelta di qualità, ma un requisito di conformità.

Il filo che tiene insieme tutto è uno solo: nello sviluppo su commessa, i problemi costosi non nascono quasi mai dal codice. Nascono da confini mal disegnati — fra fornitori, fra frontend e backend, fra ciò che è scritto nel contratto e ciò che è stato dato per scontato.

INDICE DEI CONTENUTI

1. Che cosa stai comprando davvero
2. Le cinque domande che decidono, prima dei prezzi
3. Il modello freelance: vantaggi e svantaggi
   1. I vantaggi
   2. Gli svantaggi
4. Il modello agenzia: vantaggi e svantaggi
   1. I vantaggi
   2. Gli svantaggi
5. Il terzo modello: il team composto
6. Quanto costa davvero: perché la tariffa oraria inganna
7. Il rischio non è la media, è la coda
8. Separare frontend e backend: quando ha senso
   1. La legge che devi conoscere prima di decidere
   2. Quando la separazione funziona
   3. Quando è un errore
   4. In sintesi
9. Quanto pesano davvero le decisioni sulla presentazione
10. Lo specialista UI/UX: quando serve e quando no
    1. Perché costa meno di quanto pensi
    2. Quando serve davvero
    3. Quando non serve
    4. Gli svantaggi di aggiungere un designer
11. Accessibilità: il vincolo che cambia la squadra
12. Il contratto: di chi è il software che hai pagato
13. La scelta in pratica, per tipo di progetto
14. Il mercato italiano: la scarsità conta più del prezzo
15. Conclusioni
16. Domande frequenti
    1. Costa meno un freelance o un'agenzia?
    2. Conviene affidare frontend e backend a due fornitori diversi?
    3. Serve davvero un designer UI/UX dedicato?
    4. Chi è proprietario del codice se non lo dice il contratto?
    5. Chi risponde se il software non è accessibile?
    6. Come riduco il rischio che il progetto vada male, qualunque fornitore scelga?

Che cosa stai comprando davvero

Un freelance e un'agenzia offrono lo stesso risultato apparente — un software che funziona — ma vendono due beni economicamente diversi.

Con un freelance compri competenza diretta. Chi ti ascolta è chi scrive il codice: non c'è traduzione fra il tuo problema e la persona che lo risolve, e questo elimina l'intera categoria di errori che nasce dal passaggio di informazioni. In cambio compri anche un singolo punto di rottura: una malattia, un altro cliente più urgente o una scelta di carriera sono eventi che riguardano il tuo progetto.

Con un'agenzia compri continuità e capienza. Se una persona si ferma, un'altra prende il suo posto; se servono cinque competenze diverse, le trovi sotto lo stesso contratto. In cambio paghi una struttura, e accetti che fra te e chi scrive il codice ci sia almeno un passaggio — che è dove si perdono i dettagli e dove nasce la frase "avevamo capito diversamente".

Detto in termini di rischio: il freelance ha una varianza più alta e una media più bassa. Se prendi la persona giusta ottieni il risultato migliore al prezzo migliore; se sbagli persona, o se quella persona sparisce, il costo di recupero è tuo. L'agenzia riduce la varianza e alza il costo medio. Non è una questione di qualità: è una questione di quanto puoi permetterti che qualcosa vada storto.

Le cinque domande che decidono, prima dei prezzi

Prima di leggere un preventivo, conviene rispondere onestamente a queste cinque domande. Le risposte spostano la scelta molto più di qualunque differenza di tariffa.

• Quanto dura il rapporto? Un lavoro di tre settimane e un impegno di tre anni non hanno la stessa risposta. Più il progetto è lungo, più pesa la continuità e meno pesa la tariffa.

• Quante competenze diverse servono davvero? Un gestionale interno può richiedere una persona sola. Un prodotto con app, integrazioni di pagamento, design e infrastruttura ne richiede quattro o cinque, e coordinarle diventa un mestiere a sé.

• Quanto è definito il perimetro? Se sai esattamente cosa vuoi, il freelance è quasi sempre più efficiente. Se lo stai scoprendo strada facendo, ti serve qualcuno che sappia gestire il cambiamento — e questo è un ruolo, non una tecnologia.

• Quanto costa un fermo di due settimane? Per un sito istituzionale, poco. Per il software che emette le fatture o gestisce il magazzino, moltissimo. È la domanda che da sola giustifica una struttura invece di una persona.

• Chi manterrà il software fra due anni? Se la risposta è "non lo so", allora la scelta vera non è fra freelance e agenzia: è fra un software che qualcun altro potrà riprendere in mano e uno che nessuno vorrà toccare.

Il modello freelance: vantaggi e svantaggi

I vantaggi

Nessuna traduzione. Parli con chi esegue. Su progetti in cui i requisiti si chiariscono mentre si costruisce — cioè quasi tutti — questo vale più di qualunque metodologia.

Struttura di costo più leggera. Non stai pagando commerciali, project manager, uffici e margine d'impresa. A parità di ore di lavoro effettivo, la differenza è reale e significativa.

Decisioni rapide. Un cambio di priorità si comunica in una telefonata e ha effetto lo stesso giorno, senza passare da un preventivo di variante.

Selezione mirata. Puoi scegliere la persona che ha già fatto esattamente quella cosa nel tuo settore, invece di prendere l'azienda e scoprire chi ti assegnano.

Gli svantaggi

Un solo punto di rottura. È il rischio principale, e va gestito con il contratto — codice sul repository del committente dal primo giorno, documentazione minima obbligatoria — non con la speranza.

Ampiezza limitata. Esistono ottimi profili completi, ma nessuno è al contempo esperto di infrastruttura, sicurezza, design e mobile. Oltre una certa complessità serve più di una persona, e quindi qualcuno che le coordini.

Disponibilità che varia. Un freelance bravo ha più clienti, e la tua urgenza compete con le loro.

Selezione più difficile. Valutare una persona richiede saper leggere competenze tecniche. È il motivo per cui molte aziende scelgono l'agenzia: non perché costi meno, ma perché non sanno come valutare l'alternativa.

Il modello agenzia: vantaggi e svantaggi

I vantaggi

Continuità contrattuale. Il rapporto è con un'azienda: le persone possono cambiare senza che il progetto si fermi. Su software che deve vivere anni, è l'argomento più forte in assoluto.

Competenze diverse sotto un solo contratto. Design, sviluppo, collaudo, infrastruttura e gestione del progetto sono già coordinati, e non devi farlo tu.

Processo e responsabilità formale. Un fornitore strutturato ha in genere ambienti separati, revisione del codice, collaudo e una catena di responsabilità identificabile — cose che in caso di problema fanno la differenza.

Capienza. Se serve accelerare, si possono aggiungere persone. Con cautela: aggiungere persone a un progetto in ritardo raramente lo accelera, e chi lo promette sta vendendo.

Gli svantaggi

Costo più alto a parità di lavoro. Struttura e margine si pagano, ed è legittimo: vanno però confrontati con ciò che comprano, non ignorati.

Distanza dall'esecuzione. Chi ti ascolta spesso non è chi scrive il codice. Ogni passaggio è un punto in cui il requisito si semplifica un po'.

Non sai chi lavorerà davvero. Le persone presentate in fase commerciale non sono sempre quelle assegnate. È una domanda legittima da fare prima di firmare, e la reazione a quella domanda dice molto.

Rigidità sui cambiamenti. Il perimetro è definito nel contratto, e ogni variazione passa da una trattativa. Su un progetto esplorativo, questa frizione costa più del margine.

Il terzo modello: il team composto

C'è una terza via che nei confronti a due non compare mai, ed è quella che nella pratica regge la maggior parte dei progetti di media dimensione: più freelance scelti singolarmente, con qualcuno che li coordina. Tipicamente uno sviluppatore di riferimento, un designer, e una figura tecnica di supporto chiamata a ore quando serve.

Il vantaggio è che si prende il meglio dei due mondi: competenze scelte una per una, costo senza struttura, e più di una persona che conosce il progetto. Lo svantaggio è che qualcuno deve fare il coordinamento, e quel qualcuno o lo paghi o sei tu. Se sei tu e non hai tempo, il modello non funziona: è la modalità di fallimento più comune di questa formula, e va detto prima di sceglierla.

La domanda decisiva è chi ha l'ultima parola sull'architettura. In un team composto senza un responsabile tecnico riconosciuto, ogni decisione strutturale diventa una trattativa fra pari — e le decisioni strutturali non rimandate sono esattamente ciò che distingue un software mantenibile da uno che verrà riscritto.

Quanto costa davvero: perché la tariffa oraria inganna

Il confronto fra due tariffe orarie è la parte più visibile e la meno informativa di tutta la decisione. Il costo totale di un software su commessa si compone di quattro voci, e la tariffa incide solo sulla prima.

Il tempo di coordinamento. Ogni fornitore in più aggiunge riunioni, allineamenti e zone grigie di responsabilità. Due fornitori non costano il doppio di uno: costano il doppio più il coordinamento, che è a carico tuo se non lo hai comprato.

Il costo dei cambiamenti. Nei preventivi non c'è, nella realtà è la voce che decide. Un fornitore che rende economico cambiare idea vale di più di uno che costa meno all'ora.

Il costo della manutenzione. Un software vive più a lungo di quanto chiunque preveda al momento della firma, e il conto della manutenzione arriva ogni anno. Un'idea dell'ordine di grandezza del problema la dà il rapporto CISQ sul costo della cattiva qualità del software, che stima in circa 1.520 miliardi di dollari il solo debito tecnico accumulato negli Stati Uniti — una stima costruita su fonti pubbliche, quindi un ordine di grandezza e non una misura, ma che indica dove si concentra la spesa vera.

Il costo di uscita. Cosa succede se il rapporto finisce. Qui va detta una cosa scomoda: non esistono dati indipendenti sul costo di cambiare fornitore di sviluppo software. Tutte le cifre che circolano in rete su quanto costa "riprendere in mano" un progetto vengono da pagine commerciali di agenzie che vendono proprio quel servizio. Esiste però un dato serio e vicino: nello studio europeo sul sourcing IT di Whitelane Research, che raccoglie quasi settemila relazioni di fornitura, la prima motivazione di chi riporta in casa attività esternalizzate non è il prezzo ma trattenere la conoscenza critica, indicata dal 59%. Il costo di uscita, cioè, è soprattutto il sapere che se ne va insieme al fornitore.

Il rischio non è la media, è la coda

C'è un modo sbagliato di ragionare sul rischio di un progetto software, ed è chiedersi "quanto sfora in media un progetto". La risposta corretta è che la media non descrive questo fenomeno.

Lo studio più solido sul tema — Flyvbjerg e colleghi, su 5.392 progetti IT, pubblicato nel 2022 sul Journal of Management Information Systems — mostra che gli sforamenti di costo non seguono una distribuzione normale ma una legge di potenza: moltissimi progetti sforano poco, e una minoranza sfora in modo catastrofico. Gli stessi autori avevano già documentato su Harvard Business Review che un progetto su sei sfora di circa il 200% sui costi e del 70% sui tempi. La ricerca di McKinsey con l'Università di Oxford su oltre 5.400 progetti arriva da un'altra strada allo stesso punto: sforamento medio del 45% sul budget e 56% di valore in meno rispetto alle attese.

La conseguenza pratica per chi deve scegliere un fornitore è precisa: non scegliere il fornitore che ottimizza il caso medio, scegli quello che rende improbabile il caso peggiore. Consegne piccole e frequenti invece di una consegna unica, codice sul tuo repository dal primo giorno, un ambiente di prova visibile, la possibilità di interrompere dopo la prima fase. Sono clausole che non costano nulla in trattativa e che tagliano la coda della distribuzione.

Una nota di onestà su un dato che vedrai citato ovunque: le percentuali del CHAOS Report dello Standish Group — quelle del tipo "solo il 31% dei progetti ha successo" — vanno prese con le pinze. Il metodo non è pubblico e una ricerca pubblicata su IEEE Software ne ha demolito l'impianto, mostrando che quelle definizioni di "successo" misurano l'aderenza alle stime iniziali e premiano chi gonfia le stime.

Separare frontend e backend: quando ha senso

È la domanda più tecnica di questa guida ed è anche quella su cui si sbaglia di più: affidare l'interfaccia a un fornitore e il motore a un altro. Ci sono casi in cui è la scelta giusta, e casi in cui produce un prodotto spaccato in due.

La legge che devi conoscere prima di decidere

Nel 1968 Melvin Conway pubblicò un'osservazione diventata famosa: "qualunque organizzazione che progetta un sistema produrrà inevitabilmente un progetto la cui struttura è una copia della struttura di comunicazione dell'organizzazione". Tradotto per chi commissiona software: se affidi il frontend a un fornitore e il backend a un altro, otterrai un'architettura con una frattura esattamente lì. Non è un rischio, è una previsione.

Che non sia solo un aforisma lo suggerisce anche la ricerca empirica: uno studio Microsoft Research presentato a ICSE nel 2008 ha mostrato che le metriche organizzative prevedono la propensione ai guasti di un modulo software meglio delle metriche tecniche tradizionali. Come è organizzato chi scrive il software conta quanto il software.

Quando la separazione funziona

La frattura non è un problema se cade dove il prodotto ha già un confine naturale, e se quel confine è presidiato. Tre condizioni, tutte necessarie:

• Esiste un contratto di interfaccia scritto e testato automaticamente. Non un documento: dei test. Il contract testing guidato dal consumatore è nel massimo livello di raccomandazione del Technology Radar di Thoughtworks da quasi dieci anni, ed è ciò che permette a due fornitori diversi di lavorare senza aspettarsi a vicenda.

• Esiste un responsabile unico dell'interfaccia fra i due. Se il contratto API è di entrambi, non è di nessuno. Il pattern tecnico di riferimento per questo scenario è il Backend for Frontend descritto da Sam Newman: un backend dedicato all'interfaccia, di proprietà di chi la costruisce, che elimina il collo di bottiglia organizzativo delle API generaliste.

• I due possono rilasciare in modo indipendente. È il criterio della ricerca DORA sui team debolmente accoppiati: se ogni rilascio richiede di coordinare due calendari e due ambienti, la separazione ti sta costando e non ti sta dando niente.

Quando è un errore

Su un progetto piccolo o di durata breve, quasi sempre. Il costo del contratto fra le parti — definirlo, testarlo, mantenerlo, litigarci sopra quando qualcosa non torna — è fisso, mentre il beneficio cresce con la dimensione. Sotto una certa soglia si paga solo il costo.

È un errore anche quando la separazione viene usata come scusa per mescolare tecnologie. Il Technology Radar mette esplicitamente in hold — cioè sconsiglia — la "anarchia dei micro-frontend", segnalando come caso particolarmente grave l'uso di più framework diversi dentro la stessa applicazione. Vale la pena notare che perfino il blip sui micro-frontend, che pure era arrivato al livello massimo di raccomandazione, non è più aggiornato dal 2020: era una tecnica per organizzazioni grandi, e come tale va trattata.

In sintesi

Separa frontend e backend fra fornitori diversi quando hai un prodotto abbastanza grande da giustificare un contratto di interfaccia testato, un responsabile dell'API e rilasci indipendenti. In tutti gli altri casi, un unico fornitore che copre entrambi i lati ti costa meno del coordinamento che stai per comprare.

Quanto pesano davvero le decisioni sulla presentazione

Nei preventivi la parte di interfaccia è quasi sempre trattata come rifinitura. Nei progetti reali è il punto in cui si decide se il software verrà usato.

Il dato più concreto e meno discutibile viene dall'e-commerce, dove il comportamento si misura in modo diretto. Secondo l'aggregazione di cinquanta studi condotta dal Baymard Institute, il 70% dei carrelli viene abbandonato, e fra chi aveva una reale intenzione di acquisto le cause sono in larga parte decisioni di interfaccia e di processo: il 18% abbandona perché il sito obbliga a creare un account, il 17% perché il checkout è troppo lungo o complicato, il 12% perché non riesce a vedere il totale prima della fine. La stessa fonte stima che un e-commerce medio possa guadagnare oltre il 35% di conversioni solo ridisegnando il checkout. Baymard vende ricerca sulla usabilità del checkout, quindi il conflitto di interesse va dichiarato — ma la struttura delle cause è coerente con quello che si osserva in qualunque test di usabilità.

E qui va smontata una cifra che troverai ripetuta in ogni presentazione sul tema: "ogni euro investito in UX ne restituisce cento" non ha una fonte verificabile. È attribuita a un report Forrester del 2016 il cui abstract pubblico non contiene quel numero, e con ogni probabilità nasce dalla deformazione di una regola diversa — la 1:10:100 di Roger Pressman, che riguarda il costo di correggere un difetto a mano a mano che il progetto avanza, non il ritorno di un investimento in design. È utile saperlo per due motivi: perché non conviene basare una decisione su un numero inventato, e perché la regola vera dice comunque una cosa importante — sistemare in fase di progettazione costa una frazione di quanto costa dopo il rilascio.

I dati onesti sul rendimento del design esistono e sono più sobri. Il Nielsen Norman Group, su 99 casi studio raccolti fra il 2006 e il 2020, misura un miglioramento medio delle metriche dopo una riprogettazione centrata sull'utente passato dal 247% dei primi anni al 75% del 2020 — e attribuisce il calo, con notevole onestà, al fatto che i punti di partenza sono migliorati. La ricerca di McKinsey su 300 aziende quotate seguite per cinque anni trova che quelle nel quartile più alto per maturità di design crescono molto più delle altre, ma con due avvertenze che McKinsey stessa mette: è una correlazione, non una dimostrazione di causa, e il vantaggio è concentrato nel primo quartile. Tradotto: un po' di design non produce l'effetto. O si fa sul serio, o si sta comprando un'estetica.

Lo specialista UI/UX: quando serve e quando no

Perché costa meno di quanto pensi

C'è un pregiudizio diffuso secondo cui aggiungere un designer dedicato alzi sensibilmente il costo del progetto. I numeri dicono il contrario. Nel barometro 2026 di Malt in Francia, a parità di anzianità (8-15 anni), un UX designer freelance sta a 506 euro al giorno, contro i 535 di uno sviluppatore front-end e i 562 di un back-end: costa dal 5 al 10% in meno di chi scriverà il codice. In Spagna, mercato più vicino all'Italia, la media è di 268 euro al giorno. Anche sulle retribuzioni italiane il quadro è coerente: le fonti disponibili collocano un UX designer fra i 29.000 e i 34.500 euro di RAL, contro circa 37.800 di uno sviluppatore — un differenziale del 10-20%, non un ordine di grandezza.

Il vero motivo per cui in Italia il ruolo è raro non è il costo, è la domanda. Il 24 agosto 2026, su Indeed Italia, gli annunci per "UX designer" erano 171 contro 4.344 per "sviluppatore software": un rapporto di uno a venticinque. Non è che la UX costi troppo: è che il mercato italiano quasi non la chiede — il che, per chi la chiede, è un vantaggio competitivo a buon mercato.

Quando serve davvero

• Quando l'utente non è obbligato a usarlo. Un gestionale interno lo usano comunque; un'app per i clienti no. Dove l'utente può andarsene, l'interfaccia è il prodotto.

• Quando c'è una conversione da difendere. Vendite, richieste di preventivo, iscrizioni: qui il design si misura in euro e il ritorno è calcolabile.

• Quando il processo è complesso. Configuratori, preventivatori, pratiche a più passaggi: sono i casi in cui la differenza fra un flusso pensato e uno improvvisato vale settimane di sviluppo risparmiate.

• Quando il software deve essere accessibile per legge — e nel prossimo capitolo si vede perché questa da sola può bastare a decidere.

• Quando ci sono più fornitori. Se frontend e backend sono separati, il design è l'unico documento condiviso che descrive il prodotto: senza, ogni fornitore interpreta.

Quando non serve

Su uno strumento interno usato da cinque persone che lo conoscono a memoria, su un progetto che riusa un sistema di design già esistente, su un intervento circoscritto dentro un prodotto già disegnato. In questi casi un buon sviluppatore con occhio per l'interfaccia è sufficiente, e chiamare un designer per due schermate è un costo di coordinamento che non ritorna.

Gli svantaggi di aggiungere un designer

Ce ne sono, e vanno detti. Un fornitore in più è un confine in più, con tutto quello che comporta secondo la legge di Conway: se il designer consegna schermate che nessuno ha verificato con chi scrive il codice, si ottengono interfacce belle e irrealizzabili, o realizzate a metà. Il design allunga la fase iniziale, che su un progetto esplorativo può essere l'errore opposto a quello che si voleva evitare. E soprattutto: un designer che consegna immagini e sparisce vale poco. Quello che serve è qualcuno che resti disponibile durante lo sviluppo, perché è lì che emergono i casi che nessun mockup aveva previsto.

Accessibilità: il vincolo che cambia la squadra

Dal 28 giugno 2025, con l'European Accessibility Act recepito in Italia dal decreto legislativo 82 del 2022, i prodotti e servizi digitali rivolti ai consumatori — siti, app, e-commerce, servizi bancari, e-book, biglietterie — devono essere accessibili alle persone con disabilità. Le regole tecniche italiane sono arrivate con la determinazione AgID numero 38 del 4 marzo 2026, che fissa come riferimento le WCAG 2.1 di livello AA e la norma EN 301 549, con schede di controllo distinte per siti, documenti e app mobili. A maggio 2026 AgID ha adottato anche il regolamento sul proprio potere sanzionatorio.

Tre conseguenze pratiche per chi commissiona software, in ordine di importanza.

La responsabilità è del committente, non del fornitore. L'obbligo ricade sull'operatore economico che immette il servizio sul mercato. Il freelance o l'agenzia rispondono solo contrattualmente, cioè per quello che il contratto dice. Se il capitolato non nomina l'accessibilità, la sanzione arriva a te e la rivalsa dipende da cosa hai scritto.

Le sanzioni non sono simboliche: le fonti concordano su un intervallo da 5.000 a 40.000 euro per la violazione dei requisiti, con misure aggiuntive che possono arrivare all'oscuramento del servizio o al ritiro dell'app dagli store. Sono esentate le microimprese fornitrici di servizi — meno di dieci addetti e sotto i due milioni di fatturato — salvo che abbiano ricevuto finanziamenti destinati proprio all'accessibilità.

L'accessibilità è una decisione di design, non una correzione finale. Contrasto dei colori, gerarchia dei contenuti, ordine di navigazione da tastiera, etichette dei campi, gestione degli errori: sono scelte che si prendono quando si disegna. Aggiungerle a fine progetto significa rifare le schermate. È il singolo argomento più forte a favore di un professionista UI/UX dedicato, e trasforma quella che sembrava una voce di lusso in una voce di conformità.

Il contratto: di chi è il software che hai pagato

È la parte che quasi nessuno legge e che decide tutto il resto. In Italia vale una regola che sorprende la maggior parte dei committenti: aver pagato non significa essere proprietari.

L'articolo 12-bis della legge sul diritto d'autore attribuisce al datore di lavoro i diritti di utilizzazione economica del software creato dal lavoratore dipendente. Non si applica ai freelance né alle agenzie esterne. Per il lavoro autonomo, secondo la ricostruzione degli studi legali specializzati e la giurisprudenza di legittimità — fra cui l'ordinanza della Cassazione 19335 del 2022 — i diritti patrimoniali passano al committente solo se l'attività creativa è oggetto esplicito del contratto ed è remunerata. Se il contratto tace, restano a chi ha scritto il codice. I diritti morali di paternità restano comunque sempre all'autore persona fisica, e non sono cedibili.

C'è poi un secondo scoglio, ancora meno noto: la consegna del codice sorgente non è automatica. Si può essere titolari del diritto di usare un software senza averne il sorgente, il che equivale ad avere una casa senza le chiavi.

Le clausole da mettere nero su bianco, indipendentemente dal fatto che il fornitore sia un freelance o un'agenzia:

• Cessione esplicita e integrale dei diritti patrimoniali d'autore al committente.

• Obbligo di consegna del codice sorgente, con formato, documentazione e tempi.

• Repository di proprietà del committente fin dal primo giorno, con accesso continuo — non alla fine.

• Elenco delle componenti di terze parti e open source usate, con le rispettive licenze.

• Deposito del sorgente presso un terzo (escrow) sui progetti in cui un fermo del fornitore sarebbe critico.

• Requisito di conformità WCAG 2.1 AA con attestazione, alla luce del capitolo precedente.

• Condizioni di uscita: cosa viene consegnato, in che tempi e a quale prezzo, se il rapporto finisce.

Un fornitore serio non ha alcun problema con nessuna di queste clausole. La reazione a questa lista, in fase di trattativa, è uno dei migliori strumenti di selezione a disposizione di chi compra.

La scelta in pratica, per tipo di progetto

• Sito o applicazione vetrina — freelance, o un piccolo studio. Un fornitore strutturato qui aggiunge costo e non riduce alcun rischio.

• Gestionale interno su misura — freelance con competenze full-stack, purché il contratto garantisca repository e documentazione. È lo scenario in cui il rapporto diretto rende di più.

• E-commerce con volumi reali — sviluppatore più designer, e il designer non è opzionale: le percentuali di abbandono viste sopra sono soldi, non estetica.

• Prodotto digitale che deve durare anni — agenzia, o un team composto con un responsabile tecnico riconosciuto. La continuità vale più della tariffa.

• Software critico per l'operatività (fatturazione, magazzino, produzione) — struttura, con reperibilità contrattualizzata. La domanda "quanto costa un fermo di due settimane" ha già risposto per te.

• Prodotto con app mobile, backend e integrazioni — o un'agenzia, o un team composto: le competenze sono troppe per una persona sola, e il coordinamento diventa un ruolo.

• Prototipo per validare un'idea — freelance, sempre. Serve velocità e la libertà di buttare via, non processo.

• Ripresa di un progetto lasciato a metà — chiunque sia, prima di firmare fatti fare una valutazione del codice esistente a pagamento e separata dallo sviluppo. È il denaro meglio speso di tutto il progetto.

Il mercato italiano: la scarsità conta più del prezzo

C'è un fatto che riordina l'intera discussione. Secondo l' Osservatorio delle Competenze Digitali, in Italia mancano 236.000 professionisti ICT per allinearsi alla media europea, e a fronte di circa 136.000 annunci l'anno entrano nel mercato circa 73.000 persone: per ogni due posizioni aperte arriva un candidato. I dati Excelsior di Unioncamere confermano dall'altro lato: nei servizi informatici e delle telecomunicazioni il 50,6% delle posizioni è di difficile reperimento.

In un mercato così, il vincolo non è il prezzo: è la disponibilità. Un'agenzia non ti vende soltanto struttura, ti vende persone che hai la certezza di avere. Un freelance bravo ti vende competenza diretta, ma la sua agenda è contesa. È questo, più di ogni confronto fra tariffe, a spiegare perché i progetti si fermano: non perché costino troppo, ma perché non si trova chi li faccia.

Vale la pena aggiungere due precisazioni di onestà su questo capitolo. Non esiste una statistica ufficiale sul numero di freelance ICT in Italia, e non esiste alcuna rilevazione seria sulle tariffe medie italiane di agenzie e freelance: tutto ciò che circola sono listini e marketplace di preventivi, senza campione né metodologia. È il motivo per cui in questa guida i riferimenti economici sono presi dai barometri francese e spagnolo, dichiarando che sono altri mercati.

Conclusioni

La scelta fra freelance e agenzia non si decide sul prezzo, si decide sul rischio che puoi permetterti e sulla durata del rapporto. Il freelance dà competenza diretta, costo più basso e varianza più alta; l'agenzia dà continuità e capienza a un costo maggiore. Il team composto prende il meglio di entrambi e sposta il problema sul coordinamento, che qualcuno deve pur fare.

Sulle due domande più tecniche, la risposta è meno simmetrica di quanto sembri. Separare frontend e backend fra fornitori diversi ha senso solo con un contratto di interfaccia testato, un responsabile dell'API e rilasci indipendenti: sotto quella soglia si compra coordinamento e si vende coerenza. Un professionista UI/UX dedicato, al contrario, costa meno di quanto si crede, incide su ciò che l'utente decide di fare e dal 2025 tocca un requisito di legge — quindi la domanda giusta non è se il progetto se lo può permettere, ma se può permettersi di non averlo.

Qualunque sia la scelta, tre clausole valgono più di tutto il resto: il codice sul tuo repository dal primo giorno, la cessione esplicita dei diritti con obbligo di consegna del sorgente, e consegne piccole e frequenti invece di una consegna unica alla fine. Non costano nulla in trattativa e sono l'unica cosa che rende reversibile una scelta sbagliata.

Domande frequenti

Costa meno un freelance o un'agenzia?

A parità di ore di lavoro effettivo il freelance costa meno, perché non stai pagando struttura, commerciali e margine d'impresa. Ma il costo totale di un software non è la tariffa: sono il coordinamento, i cambiamenti in corsa, la manutenzione negli anni e il costo di uscita se il rapporto finisce. Su un progetto breve e definito il freelance vince quasi sempre; su un software che deve vivere anni ed essere sempre disponibile, la continuità di una struttura può valere la differenza di prezzo.

Conviene affidare frontend e backend a due fornitori diversi?

Solo se ricorrono tre condizioni insieme: un contratto di interfaccia scritto e verificato con test automatici, un responsabile unico di quell'interfaccia, e la possibilità per i due di rilasciare in modo indipendente. Senza queste tre cose la separazione produce soltanto coordinamento, e secondo la legge di Conway l'architettura del prodotto finirà per avere una frattura esattamente dove passa il confine fra i due fornitori. Su progetti piccoli è quasi sempre un errore.

Serve davvero un designer UI/UX dedicato?

Serve quando l'utente non è obbligato a usare il software, quando c'è una conversione da difendere, quando il processo è complesso o quando il servizio deve essere accessibile per legge. Costa meno di quanto si pensi: nei barometri europei un UX designer freelance costa il 5-10% meno di uno sviluppatore a parità di anzianità. Non serve su strumenti interni usati da poche persone o su interventi dentro un prodotto già disegnato.

Chi è proprietario del codice se non lo dice il contratto?

In Italia la norma che assegna al committente i diritti di utilizzazione economica riguarda il lavoratore dipendente: non si applica ai freelance né alle agenzie esterne. Se il contratto tace, i diritti patrimoniali restano a chi ha scritto il codice, e la consegna del sorgente non è automatica. Vanno quindi previste per iscritto la cessione esplicita dei diritti, l'obbligo di consegna del sorgente e il repository intestato al committente fin dall'inizio.

Chi risponde se il software non è accessibile?

L'obbligo ricade sull'operatore economico che immette il servizio sul mercato, cioè sul committente, non su chi ha sviluppato in appalto. Il fornitore risponde solo per quello che il contratto prevede. Per questo la conformità alle WCAG 2.1 AA va scritta nel capitolato con obbligo di attestazione: le sanzioni previste vanno da 5.000 a 40.000 euro, con possibili misure fino all'oscuramento del servizio.

Come riduco il rischio che il progetto vada male, qualunque fornitore scelga?

Gli studi più solidi mostrano che gli sforamenti dei progetti software seguono una legge di potenza: la maggioranza sfora poco, una minoranza sfora in modo catastrofico. Il rimedio non è scegliere il fornitore migliore in media, è rendere improbabile il caso peggiore: consegne piccole e frequenti, codice sul tuo repository dal primo giorno, un ambiente di prova sempre visibile e la possibilità di interrompere dopo la prima fase. Sono clausole che non costano nulla in trattativa.