"Abbiamo trovato un team offshore, cioè esterno e spesso in un altro paese, che fa lo stesso lavoro a un terzo del costo."
L'outsourcing software low cost è una tentazione ricorrente: negli ultimi vent'anni, questa frase ha dato il via a centinaia di progetti. Molti sono partiti con entusiasmo. Molti, dopo un anno, si sono ritrovati con codice che "funziona" ma che nessuno riesce più a toccare senza rompere qualcosa.
È un problema di modello organizzativo.
Il modello delle software farm low-cost è costruito per produrre tanto codice, in poco tempo, al costo più basso possibile. Funziona bene quando il problema è scrivere task. Funziona molto meno quando il problema è rappresentare fedelmente il tuo business, far evolvere il software nel tempo e mantenerlo sano per anni.
Come funziona davvero il modello
Lo schema è quasi sempre lo stesso. L'azienda vuole ridurre i costi di sviluppo, si affida a una software farm con molti sviluppatori, la comunicazione passa attraverso uno o due project manager, il team tecnico è numeroso, junior e intercambiabile, e l'incentivo principale diventa chiudere ticket velocemente, non capire il problema a fondo.
Questo modello ha senso industriale. È pensato per scalare. Ma ha un effetto collaterale enorme: il codice prodotto è scollegato dal contesto reale del tuo business.
E quando il codice è scollegato dal contesto, diventa fragile.
Il vero ostacolo è la comunicazione
Quando lavori con un team a migliaia di chilometri di distanza, con poche ore di sovrapposizione e una comunicazione mediata da documenti e task, succede una cosa prevedibile: le sfumature si perdono.
Le conversazioni veloci diventano thread di email. I chiarimenti immediati diventano messaggi che ricevono risposta il giorno dopo. I requisiti vengono interpretati alla lettera, non nel loro intento.
Nessuna malafede: è la conseguenza naturale del contesto.
Nel software, però, un requisito frainteso non produce una piccola differenza. Produce un comportamento completamente diverso da quello che ti aspettavi.
Il fuso orario impedisce la collaborazione vera
Quando il tuo team lavora mentre tu dormi, e tu lavori mentre loro dormono, la collaborazione diventa asincrona forzata.
Scompaiono le sessioni di analisi fatte bene, le discussioni architetturali spontanee e i chiarimenti rapidi sulle decisioni ambigue. Resta uno scambio di documenti e ticket. Il software, però, nasce bene dal confronto continuo, non da una catena di passaggi intermedi.
Questo non rallenta solo il progetto. Peggio: impedisce al team di capire davvero cosa sta costruendo.
Il vero problema: nessuno possiede il codice
Nelle software farm low-cost, il turnover è spesso alto. Le persone cambiano progetto, cliente, azienda. Dopo sei mesi, chi ha scritto quel modulo potrebbe non esserci più. Dopo un anno, può capitare che nessuno del team originale sia ancora sul progetto.
Il codice resta. La conoscenza no. È il problema del bus factor portato all'estremo.
È una versione amplificata del problema descritto in The Mythical Man-Month: aggiungere persone non crea comprensione, crea frammentazione.
Quando quel software passa in mano a un nuovo team — interno o esterno — sembra scritto da qualcuno che non conosceva il tuo business. Perché, di fatto, è così.
Perché all'inizio sembra funzionare
Nei primi mesi tutto fila liscio.
Le feature arrivano. I ticket si chiudono. Il costo è contenuto. Sembra una scelta brillante.
Il problema emerge dopo, quando devi fare modifiche non previste, il business cambia oppure serve aggiungere una logica nuova che interagisce con quelle esistenti. È lì che scopri che il codice è una somma di task chiusi, non un sistema pensato per evolvere. E ogni modifica diventa un rischio.
È il momento in cui inizi a dire: "Ogni volta che tocchiamo qualcosa, si rompe qualcos'altro."
Un problema di incentivi, non di geografia
Questo modello non esiste solo in un paese. Esiste ovunque il lavoro venga organizzato con tanti sviluppatori intercambiabili, poca ownership, comunicazione filtrata e focus sulla velocità più che sulla comprensione. Il risultato tende a essere sempre lo stesso: codice che fa quello che c'è scritto nel ticket, ma non quello che serve davvero al business.
Perché oggi questo modello ha ancora meno senso
Per vent'anni, il vantaggio competitivo delle software farm low-cost era semplice:
tanto codice a basso prezzo.
Anche accettando inefficienze e fragilità architetturale, il conto tornava. Perché il collo di bottiglia era sempre lo stesso: servivano tante ore uomo per scrivere codice.
Oggi questo presupposto sta saltando.
Strumenti come GitHub Copilot, Cursor o Claude Code producono codice in minuti, senza fuso orario, senza incomprensioni linguistiche e a un costo marginale quasi nullo.
Il valore si è spostato: da chi scrive il codice al prezzo più basso a chi sa decidere cosa scrivere, come strutturarlo e come farlo evolvere.
Ed è esattamente la parte che il modello low-cost non copre.
Il paradosso umano
Questo crea un paradosso che vale la pena riconoscere.
Per anni, questo modello ha funzionato perché il mercato chiedeva quantità di codice. E moltissimi sviluppatori hanno lavorato esattamente per soddisfare quella richiesta.
Ora il mercato si sta spostando.
Perché la richiesta è cambiata: da "scrivi questo ticket" a "capisci questo sistema".
Il problema è per cosa vengono pagati.
E quella cosa sta perdendo valore molto velocemente.
La lezione per chi commissiona software
Questo non è un attacco a un paese. È una critica a un'idea pericolosa:
che il software sia un problema di manodopera.
Finché sembrava esserlo, l'outsourcing low-cost aveva senso economico. Oggi si vede chiaramente che il valore vero non era lì.
Il software riguarda comprensione del business, decisioni architetturali, comunicazione continua e responsabilità sul sistema nel tempo. Sono tutte cose che non si possono spacchettare in ticket da mandare dall'altra parte del mondo.
E oggi, nemmeno da delegare a un'AI.
Simone Giusti
Consulente software strategico
