Assumere internamente o esternalizzare lo sviluppo?
Il confronto onesto, compresi i casi in cui assumere è chiaramente la risposta migliore.
Assumere vi dà competenze permanenti e pieno controllo, al prezzo di tre-sei mesi di selezione e dei costi di avere dipendenti. L’outsourcing parte in poche settimane e si riduce quando il lavoro finisce. La maggior parte delle aziende, prima o poi, ha bisogno di entrambi.
Aggiornato novembre 2026
Risposta breve
Assumete per tutto ciò che è centrale, permanente e cuore della vostra attività. Esternalizzate un progetto definito, un picco temporaneo o una competenza che vi serve di rado. Esternalizzare qualcosa di centrale e continuativo è di solito un modo costoso per evitare di assumere.
Il confronto che si fa è il costo orario. Quello che conta è cosa succede quando il lavoro cambia.
Uno sviluppatore in outsourcing sembra più caro all’ora di uno stipendio diviso per i giorni lavorativi. Quel confronto è quasi sempre sbagliato, perché conta lo stipendio e nient’altro: non le spese di selezione, l’attrezzatura, i contributi, i benefit, le ferie, i due o tre mesi prima che una persona sia produttiva, né il costo di un’assunzione che non funziona.
Ma la ragione onesta per assumere non è il costo. È la continuità e l’investimento. Una persona assunta da voi accumula per anni la conoscenza del vostro prodotto, è presente quando si prendono le decisioni e tiene al codice in un modo che è davvero più difficile da comprare.
La vera decisione riguarda la forma del lavoro. Il lavoro permanente, centrale e strategico va tenuto in azienda: esternalizzarlo mette fuori dall’azienda la conoscenza meno sostituibile e crea una dipendenza costosa da sciogliere. Progetti definiti, picchi temporanei e specializzazioni occasionali sono ciò in cui l’outsourcing è davvero bravo.
La maggior parte delle aziende finisce per fare entrambe le cose, e l’assetto sensato è un piccolo team stabile che possiede il nucleo, con capacità esterna intorno. L’assetto che va male è l’inverso: esternalizzare il nucleo e assumere per la periferia.
Fianco a fianco.
| Team interno | Outsourcing | |
|---|---|---|
| Tempi di avvio | 3–6 mesi per assumere | 2–4 settimane |
| Costo | Stipendio, contributi, attrezzatura, benefit | Una fattura mensile |
| Se il lavoro finisce | Riduzione del personale | Si chiude con preavviso |
| Se non funziona | Lento e difficile | Si sostituisce, o si chiude |
| Conservazione della conoscenza | Resta, finché restano le persone | Va documentata di proposito |
| Ferie e malattie | Problema vostro | Coperte |
| Affinità culturale e lealtà | Più forti | Più deboli, a dirla tutta |
| Adatto a | Lavoro centrale, permanente, strategico | Progetti, picchi, competenze occasionali |
Assumete internamente quando
- Il lavoro è centrale e non finirà
- La conoscenza profonda del prodotto cresce di valore negli anni
- Vi serve qualcuno presente ogni giorno quando si decide
- Potete aspettare tre-sei mesi e sostenere i costi fissi
Esternalizzate quando
- Il lavoro ha una fine definita, o è un picco temporaneo
- Una competenza vi serve di rado, non sempre
- Assumere localmente è lento, costoso o davvero difficile
- Volete partire ora, non tra sei mesi
Gli errori più comuni.
Confrontare la tariffa oraria solo con lo stipendio
Selezione, attrezzatura, contributi, benefit, ferie, tempi di inserimento e rischio di un’assunzione sbagliata sono costi reali che non compaiono mai nel confronto.
Esternalizzare il nucleo per risparmiare
Funziona finché non volete cambiare direzione in fretta, o finché il rapporto con il fornitore non finisce. La vostra conoscenza più importante non dovrebbe stare fuori dall’azienda.
Pensare che la conoscenza passi da sola
Non passa. Documentazione scritta durante tutto il lavoro, codice nel vostro repository dal primo giorno e un vero passaggio di consegne: nulla di questo accade se non è previsto fin dall’inizio.
Assumere per un picco temporaneo
Tre-sei mesi per selezionare, poi il picco passa e vi ritrovate con personale in eccesso e una riduzione dell’organico da gestire. È esattamente ciò a cui serve l’outsourcing.
Quattro domande che chiudono la questione.
La prima da sola risolve la maggior parte dei casi.
Questo lavoro esisterà ancora tra due anni?
Se sì ed è centrale per l’attività, assumete. Se ha una fine definita, esternalizzate: non dovreste gestire una riduzione del personale per un progetto.
Potete aspettare tre-sei mesi per partire?
È un tempo realistico di selezione, compresi i preavvisi. Se la risposta è no, l’outsourcing è l’unica strada che parte in poche settimane.
Questa competenza vi serve sempre o di rado?
Uno specialista di sicurezza che vi serve due volte l’anno non dovrebbe essere un dipendente. Uno sviluppatore di prodotto che vi serve ogni giorno probabilmente sì.
Sapreste descrivere come lascereste il vostro fornitore?
Chiedetelo direttamente a lui. Se non sa rispondere con chiarezza, la vostra conoscenza non è al sicuro e il confronto sui costi è irrilevante.
Cosa si chiede subito dopo.
Di solito all’ora, non sempre nel complesso. Dal lato interno spesso si trascura il costo pieno: spese di selezione, attrezzatura, contributi, benefit, ferie, i mesi prima che una persona sia produttiva e il rischio di un’assunzione sbagliata. Dal lato esterno si trascurano il costo del coordinamento e la conoscenza che se ne va quando l’incarico finisce. Confrontate tutto, o il confronto vi inganna.
Non ce n’è una intrinseca, in nessuna direzione. Esistono team esterni eccellenti e team interni scadenti, e viceversa. Ciò che cambia davvero sono incentivi e continuità: un dipendente investe per anni nel codice, un team esterno investe nell’incarico. Si gestisce con l’assetto giusto, ma conviene vederlo con lucidità.
Se ne va, a meno che non facciate in modo che resti, ed è questo il vero rischio, più del costo. Documentazione scritta durante tutto il lavoro e non nell’ultima settimana, codice nel vostro repository dal primo giorno e un passaggio di consegne con chi subentra. Se un fornitore non sa descrivere come lo lascereste, avete già la risposta sulla sicurezza della vostra conoscenza.
Prima o poi lo fa la maggior parte delle aziende, e di solito è l’assetto giusto. Un piccolo team stabile che possiede il prodotto centrale, con capacità esterna per i picchi, il lavoro specialistico o un secondo filone di attività. Ciò che non funziona è esternalizzare il nucleo e assumere per la periferia: così la conoscenza meno sostituibile finisce fuori dall’azienda.
— altri confronti
Raccontateci il progetto, com’è davvero.
Scriveteci cosa vi serve e dove siete bloccati. Vi rispondiamo entro un giorno lavorativo con domande vere, e se il progetto dovrebbe essere più piccolo di come lo immaginate ve lo diremo.