Come Costruire Un Team Di Sviluppo Software

La decisione di costruire un team di sviluppo software arriva quasi sempre come una voce di bilancio e non come un piano. Qualcuno ha approvato due posti da sviluppatore, una nota al consiglio ha sostenuto che possedere il codice costa meno che affittarlo, e la ricerca parte prima che nessuno abbia scritto a cosa serve il team. L’assunzione va storta in un modo che resta invisibile per circa nove mesi.

Chi si pone questa domanda quasi sempre non dovrebbe ancora assumere, e la risposta onesta parte da lì. Un team permanente è un costo fisso contro un bisogno che di norma varia. Funziona quando il lavoro è continuo, quando il software è ciò per cui i clienti pagano, e quando qualcuno in azienda sa dire cosa costruire la settimana prossima. Togli una sola di queste condizioni e hai comprato a un anno ciò che potevi comprare a giornata.

Segue l’aritmetica e l’ordine delle mosse: quanto costa davvero uno sviluppatore una volta inclusi National Insurance, previdenza, ferie, attrezzatura e ricerca, quale ruolo aprire per primo, cosa consegnano team di una, tre, cinque e dieci persone, e come condurre un colloquio tecnico quando in azienda nessuno è tecnico.

Quante persone servono per costruire un team di sviluppo software? Meno del previsto e più tardi del previsto. Un senior generalista capace di reggere la consegna dall’inizio alla fine copre più terreno di tre junior, perché su piccola scala il vincolo è il giudizio e non la digitazione. La prima forma davvero stabile è di tre persone, circa 250.000 GBP l’anno con tutti i costi. Con una roadmap discontinua, un’agenzia è di solito lo strumento migliore.

La maggior parte delle aziende non dovrebbe ancora creare un team software

Assumere è il modo più caro di rispondere a una domanda posta male. Un contratto di lavoro ti lega a uno stipendio finché la persona resta, più il preavviso, più i costi di legge descritti sotto, e lo fa prima che tu sappia se quel lavoro esisterà ancora fra diciotto mesi.

Il fallimento è raramente drammatico. Un’azienda assume due sviluppatori, loro costruiscono ciò che è in elenco, e l’elenco finisce. Nessuno vuole licenziare, così il team inventa lavoro: una riscrittura, un aggiornamento di framework, uno strumento interno che nessuno ha chiesto. Dodici mesi dopo il costo del personale è reale, il risultato no, e il fondatore conclude che gli sviluppatori sono improduttivi. Non lo erano. Erano sotto-specificati.

La controargomentazione è valida: le agenzie costano di più al giorno e capiscono meno la tua attività. Entrambe le cose sono vere. Quello che manca è che un’agenzia è un costo variabile che puoi spegnere, quindi un mese storto costa un mese e non un anno. Quando la roadmap è davvero continua il calcolo si ribalta e l’interno vince su costo e velocità. L’errore è ribaltarlo troppo presto. Un perimetro fisso con una fine definita è un incarico di agenzia e non un piano di assunzioni, motivo per cui al nostro servizio di sviluppo software arrivano tante aziende che chiedono organico e in realtà hanno un progetto e non un programma.

Il test che dice se serve davvero un team

Tre condizioni, e le vuoi tutte e tre. Meno di tre significa che non sei pronto.

Il software è il prodotto o sostiene il prodotto? Se i clienti ti pagano per il software, o se è il motivo per cui scelgono te invece di un concorrente, il codice è un asset strategico e affidarne fuori la totalità diventa prima o poi un problema di governance. Se il software gestisce la fatturazione, è impiantistica, e l’impiantistica si compra.

La roadmap è continua? Scrivi cosa costruiresti dal mese quattro al dodici. Non funzioni che ti piacerebbero, lavoro che sai difendere sul piano commerciale. Se l’elenco è magro, hai un progetto con una coda e non un anno di lavoro.

Qualcuno in azienda sa specificare il lavoro? È il punto che si salta. Uno sviluppatore deve sapere quale problema risolvere e da cosa capirai che è risolto. Se l’unica persona che può rispondere è l’amministratore delegato, e ha quaranta minuti a settimana, il team passa gran parte del tempo ad aspettare o a indovinare. Un team senza product owner produce movimento, non progresso.

Una quarta domanda decide i tempi invece della risposta. Puoi finanziare diciotto mesi senza che il software generi ricavi? Se la cassa impone che il team sia in utile dal mese sei, non assumere nessuno e compra il lavoro a giornata.

Quanto costa davvero un dipendente nel 2026

Lo stipendio è circa il settanta per cento del numero. Il resto è di legge, operativo e una tantum, e l’ultima categoria è quella che rovina i budget del primo anno.

I costi di legge che non si negoziano

Il National Insurance a carico del datore è l’aggiunta maggiore. Per l’anno fiscale 2026 a 2027 i datori pagano il 15 per cento sui redditi oltre una soglia secondaria di 5.000 GBP l’anno, secondo le aliquote e soglie GOV.UK per i datori di lavoro. Su uno stipendio di 60.000 GBP fa il 15 per cento di 55.000 GBP, cioè 8.250 GBP. I datori idonei possono compensare fino a 10.500 GBP del debito annuo di classe 1 secondaria tramite l’Employment Allowance, ma una società con un solo amministratore e nessun altro dipendente soggetto a contributi secondari non può richiederla.

L’adesione automatica alla previdenza aggiunge un contributo minimo del datore del 3 per cento, dentro un minimo totale dell'8 per cento, calcolato sui redditi rilevanti fra 6.240 GBP e 50.270 GBP l’anno secondo le indicazioni GOV.UK sui contributi pensionistici aziendali. In cima alla fascia fa circa 1.321 GBP per dipendente. Molti datori versano invece una percentuale dello stipendio pieno, più generosa e più facile da spiegare a un candidato.

Le ferie sono un costo di capacità e non di cassa. Il diritto di legge è di 5,6 settimane, cioè 28 giorni per chi lavora cinque giorni a settimana, e le festività non vanno concesse in aggiunta. Su circa 260 giorni lavorativi siamo vicini all’undici per cento dell’anno prima che qualcuno si ammali.

I costi che restano fuori dal foglio di calcolo

L’attrezzatura è piccola ma reale: un portatile da sviluppo da 1.500 a 2.500 GBP, un monitor, una scrivania. Gli strumenti pesano più del previsto una volta contati controllo di versione, licenza dell’IDE, minuti di integrazione continua, ambienti cloud, tracciamento degli errori e conservazione dei log. Da 1.200 a 3.000 GBP per sviluppatore all’anno è una base di pianificazione difendibile, stima interna e non statistica pubblicata.

La ricerca è il picco. Nel Regno Unito una società a successo chiede di norma una percentuale del primo stipendio annuo fra la fine della prima decina e la metà della seconda, quindi metti a budget da 9.000 a 15.000 GBP su un ruolo da 60.000 GBP, salvo assunzione diretta. Anche questa è una stima interna.

La voce che nessuno calcola è la gestione. Un senior che segue altri due perde dal venti al quaranta per cento della propria capacità di consegna, quindi tre assunzioni non danno il risultato di tre persone.

Leggilo come circa 1,4 volte lo stipendio nel primo anno e 1,2 volte dopo, senza il carico gestionale. Le cifre di stipendio, attrezzatura, strumenti e ricerca sono stime interne di pianificazione; solo le voci National Insurance, previdenza e ferie vengono da aliquote pubblicate.

La strada del freelance e cosa compra davvero

Un freelance a giornata toglie i costi di legge e il preavviso, e aggiunge un premio e un obbligo di governance. Nel Regno Unito uno sviluppatore senior che fattura tramite la propria società si colloca di solito nella fascia da 400 a 600 GBP al giorno, con competenze rare e incarichi brevi sopra. È una stima interna, coerente con le fasce che citiamo altrove su questo sito.

A 500 GBP al giorno e 220 giorni fatturabili fa 110.000 GBP l’anno contro 72.000 GBP con tutti i costi per un dipendente a 60.000 GBP. Il premio compra tre cose: puoi fermarti, puoi partire in fretta, e prendi qualcuno che ha già risolto questo problema altrove. Ti costa la continuità e la conoscenza che esce con il contratto.

I freelance funzionano bene per una lacuna di competenza definita, per coprire un’assenza e per i primi sei mesi di una costruzione in cui vuoi giudizio senior senza impegnare organico. Funzionano male come sostituto permanente di un team, perché la struttura di incentivi premia in silenzio la durata invece del completamento, e perché nessuno risponde del codice diciotto mesi dopo. La versione sensata è ibrida: freelance per i picchi e le specializzazioni, dipendenti per le parti del sistema che non puoi permetterti di veder uscire. È lo schema dietro la maggior parte dei nostri incarichi di assumere uno sviluppatore web.

Il lavoro fuori busta paga e cosa chiedono le regole

Questa sezione descrive un obbligo. Non è consulenza fiscale, e qualunque accordo con un freelance, di qualsiasi dimensione, andrebbe verificato con un commercialista o uno specialista di fiscalità del lavoro prima di partire.

Le regole sul lavoro fuori busta paga, note come IR35, si applicano quando qualcuno fornisce servizi tramite un proprio intermediario e sarebbe stato un dipendente se avesse contrattato direttamente con te. Le indicazioni GOV.UK sul lavoro fuori busta paga stabiliscono chi decide. Un committente privato medio o grande determina lo status occupazionale del lavoratore ai fini fiscali e deve emettere uno Status Determination Statement con le motivazioni. Per un committente piccolo fuori dal settore pubblico quella responsabilità resta all’intermediario del lavoratore.

Se sei piccolo lo dice il test dimensionale del Companies Act. L’Employment Status Manual di HMRC registra che dal 6 aprile 2025 le soglie sono salite a un fatturato oltre 15 milioni di GBP e un totale di bilancio oltre 7,5 milioni di GBP, con il limite di 50 dipendenti invariato. Un’azienda è media o grande se soddisfa almeno due dei tre criteri in due esercizi consecutivi.

HMRC pubblica uno strumento per la determinazione vera e propria. Lo strumento di verifica dello status occupazionale ai fini fiscali può essere usato da committenti, lavoratori o agenzie, e HMRC dichiara di attenersi al risultato purché le informazioni fornite siano corrette e in linea con le sue indicazioni. Quella riserva è tutto: un esito basato sul contratto che avresti voluto avere non vale nulla.

La conseguenza pratica è semplice. I freelance costano meno dei dipendenti sul piano amministrativo solo finché sei piccolo. Superato il test dimensionale, ogni incarico porta con sé una determinazione, una dichiarazione e una registrazione.

Quanto costa un’agenzia e a cosa rinunci

Nel Regno Unito le tariffe giornaliere di agenzia per uno sviluppatore senior vanno spesso da 600 a 1.200 GBP, a seconda dell’esperienza, del settore e di quanta gestione della consegna è inclusa. È circa il doppio di un freelance e il triplo di una giornata di dipendente con tutti i costi, e il confronto inganna in entrambe le direzioni.

Il premio compra capacità già assemblata. Una squadra di agenzia da tre persone ha già lavorato insieme, ha una pipeline di rilascio, una reperibilità e un senior che rivede il codice. Costruire questo in casa richiede sei-nove mesi e due giri di assunzioni. Per una costruzione a perimetro fisso, o per una prima versione in cui stai ancora capendo cosa deve essere il prodotto, quel vantaggio di partenza batte di solito la differenza di tariffa.

Quello a cui rinunci è vicinanza e permanenza. La comprensione che un’agenzia ha della tua attività è limitata a ciò che le hai raccontato, e se ne va con lei. Il rimedio è la documentazione e una clausola di passaggio di consegne scritta all’inizio e non alla fine.

Il punto di pareggio si ragiona meglio in mesi che in tariffe. Sotto i nove mesi circa di lavoro continuo l’agenzia costa meno, una volta valutati ricerca, avviamento e rischio di un’assunzione sbagliata. Oltre i diciotto mesi l’interno vince nettamente. La nostra guida su come scegliere e ingaggiare un’agenzia di sviluppo software copre la scelta, e la guida al budget per software su misura copre i numeri.

La prima assunzione tecnica decide tutto il resto

Tutto ciò che viene dopo la prima assunzione tecnica dipende dal giudizio di quella persona. Sceglie il linguaggio, l’hosting, l’approccio al rilascio e il modello dei dati, e ogni assunzione successiva viene valutata su uno stack che ha definito lei. Un’azienda che sbaglia qui non se ne accorge per un anno, e poi se ne accorge tutta insieme.

Assumi un senior generalista che sappia reggere la consegna dall’inizio alla fine. Non uno specialista della tecnologia che pensi ti serva, e non un manager. Qualcuno che sappia parlare con un cliente, decidere cosa costruire, costruirlo, metterlo in produzione e assisterlo un martedì sera. Quel profilo è caro, circa da 70.000 a 95.000 GBP fuori Londra come stima interna, ed è la cosa meno cara che comprerai quell’anno.

La prova nel colloquio non è se conosce il tuo framework. È se sa descrivere un progetto che ha dimensionato male e dire cosa farebbe diversamente, e se chiede dei tuoi clienti prima di chiedere del tuo stack. Chi chiede solo della tecnologia costruirà qualcosa di tecnicamente eccellente e commercialmente irrilevante.

Dai a questa persona autorità e non solo un titolo. Se non può dire di no a una richiesta di funzionalità, hai assunto un paio di mani molto costose. Il nostro articolo su come assumere uno sviluppatore software nel Regno Unito entra più a fondo nella selezione.

Perché assumere prima un junior fallisce

La logica è sempre la stessa e sempre sbagliata. Un junior costa 28.000 GBP invece di 80.000 GBP, quindi puoi prenderne due, e cresceranno nel ruolo. Quello che succede davvero è che non c’è nessuno a farli crescere.

Uno sviluppatore junior è un saldo negativo sulla consegna per tre-nove mesi. Non è una critica, è come funziona il mestiere: gli servono revisioni del codice, una guida sull’architettura e qualcuno che lo fermi prima che fissi una decisione costosa da disfare. Senza una persona senior che lo faccia, la revisione non avviene mai e il junior manda lavoro non controllato dritto nel sistema che regge la tua attività.

Il conto arriva più tardi, come debito tecnico. Riscrivere diciotto mesi di codice mai revisionato di norma costa più dello stipendio risparmiato, e lo costa quando il software è già portante.

I junior sono un buon investimento nell’ordine giusto. Quando hai un senior con tempo per fare da mentore e una base di codice con test e un processo di revisione, un junior diventa capacità economica che si accumula. Assunti per primi, sono una passività scoperta con un numero di matricola.

Forme di team: cosa consegnano una, tre, cinque e dieci persone

Un organigramma dice chi risponde a chi. A chi compra serve invece una descrizione di cosa ogni dimensione riesce davvero a mettere in produzione, e cosa strutturalmente non riesce.

Uno sviluppatore

Un senior generalista può costruire e mandare avanti una singola applicazione di superficie contenuta. Rilascia ogni settimana, risolve da solo i problemi di produzione e tiene tutto il sistema in testa, il che lo rende veloce. Quello che non può fare è ammalarsi, andare in ferie o dimettersi. Un team di una persona non ha alcuna ridondanza, e ogni azienda che gira su un solo sviluppatore porta un rischio non quotato. Coprilo con un contratto di assistenza di agenzia per le assenze, oppure accettalo in modo esplicito invece che per inerzia.

Tre sviluppatori

Tre è la prima forma che sopravvive all’uscita di una persona. Di norma un technical lead e due sviluppatori, con il lead che passa metà settimana sulla consegna e metà su revisioni, pianificazione e sblocchi. Tre persone reggono due filoni di lavoro, una cadenza di rilascio e un turno di reperibilità. Non possono specializzarsi, quindi tutto ciò che richiede competenza profonda, come un’integrazione dei pagamenti o una riscrittura per le prestazioni, si compra fuori. Con tutti i costi siamo intorno a 250.000 GBP l’anno.

Cinque sviluppatori

A cinque la struttura inizia a ripagarsi. Ora puoi permetterti uno specialista accanto ai generalisti, e il technical lead smette di scrivere codice per gran parte della settimana. Cinque persone reggono un prodotto con una base utenti vera, rispondono agli incidenti in orario di ufficio e avanzano comunque sulla roadmap. È anche la dimensione in cui l’assenza di un product owner diventa insostenibile, perché il costo di coordinamento supera quello che un fondatore assorbe nei ritagli.

Dieci sviluppatori

Dieci sono due team, che tu abbia tracciato la linea o no. I percorsi di comunicazione crescono più in fretta dell’organico, quindi l’approccio informale si rompe e serve una titolarità esplicita: chi possiede quale servizio, chi è reperibile, chi decide. È qui che l’engineering manager diventa un ruolo e non un cappello, e qui che il lavoro di piattaforma (rilasci, ambienti, osservabilità) diventa il mestiere di qualcuno invece della serata di tutti.

I ruoli spiegati a un lettore non tecnico

I titoli nel software sono incoerenti fra aziende, il che li rende difficili da comprare. Ecco cosa fa ogni ruolo della propria settimana.

Product owner

Decide cosa si costruisce e in quale ordine, mette per iscritto cosa significa “fatto”, e sa dire di no. Passa la settimana a parlare con i clienti e con il team, e a convertire gli uni in lavoro su cui l’altro può agire. Senza questo ruolo lo fa male qualcun altro, di solito il technical lead, a spese del suo tempo di consegna. Puoi restare senza un product owner dedicato fino a circa cinque sviluppatori, se un fondatore ha davvero un giorno a settimana da dedicarci.

Technical lead

Possiede il modo in cui il sistema è costruito. Rivede il codice, prende le decisioni di architettura e risponde quando il disegno si rivela sbagliato. A tre persone scrive ancora codice quasi ogni giorno, a dieci ne scrive pochissimo. È il ruolo che non puoi saltare a nessuna dimensione sopra uno, perché è da lì che arriva la coerenza.

Sviluppatore full-stack

Costruisce funzionalità lungo tutto il percorso, dallo schermo che vede l’utente al database dietro. È la spina dorsale di ogni piccolo team, perché un generalista raccoglie qualunque cosa stia bloccando il rilascio. Su piccola scala assumi quasi solo questo profilo.

Specialista

Profondo in un’area: mobile, ingegneria dei dati, sicurezza, un framework preciso. Enormemente utile quando il lavoro lo richiede davvero, e fermo quando non lo richiede. Compra gli specialisti a giornata finché il bisogno non è continuo per almeno sei mesi.

Ingegnere QA

Prova il sistema di proposito invece che per caso, costruisce suite di test automatici e possiede la definizione di un rilascio sicuro da pubblicare. Gli sviluppatori provano il proprio lavoro, ma provano ciò che si aspettavano. Un tester prova ciò che un utente farà davvero.

Ingegnere di piattaforma

Possiede il terreno su cui gira il software: ambienti, pipeline di rilascio, monitoraggio, backup, costi. A volte lo chiamano DevOps, che a rigore è una pratica e non un mestiere. Il lavoro esiste a ogni dimensione; la domanda è se sia il mestiere di qualcuno o lo straordinario di tutti.

Quando servono un tester, un designer e un ingegnere di piattaforma

Ognuno di questi ha un segnale onesto, ed è un sintomo e non un numero di teste.

Assumi un tester dedicato quando le regressioni arrivano ai clienti più di una volta a trimestre, o quando i rilasci rallentano perché nessuno si fida abbastanza da premere il pulsante. Entrambe le cose significano che la verifica manuale ha superato quello che gli sviluppatori assorbono. In un team di cinque di solito succede fra il mese dodici e il ventiquattro.

Assumi o ingaggia un designer quando gli sviluppatori prendono decisioni di interfaccia dentro la pull request. È un difetto di sequenza e non di capacità: stanno progettando e costruendo insieme, e alla metà di progettazione resta il tempo che avanza. Un designer part time basta ben oltre i dieci sviluppatori.

Assumi un ingegnere di piattaforma quando il rilascio diventa un evento invece di una routine, o quando la settimana del tuo sviluppatore migliore se ne va in ambienti e pipeline. Se pubblicare richiede una persona precisa e un pomeriggio tranquillo, il terreno è diventato il collo di bottiglia. Il nostro articolo sulle buone pratiche di pipeline CI/CD racconta com’è fatto il buono prima che tu assuma per questo.

Assumi un engineering manager intorno alle otto-dieci persone, e non prima. Sotto quella soglia un technical lead con autorità è meglio di un manager senza credibilità tecnica, perché le decisioni che contano su piccola scala sono tecniche.

Scrivere un annuncio di lavoro che filtra

Un annuncio ha un solo compito: ridurre il numero di candidature da leggere e allo stesso tempo alzare la quota di quelle pertinenti. La maggior parte fa l’opposto, perché elenca tecnologie invece di problemi.

Apri con il problema. “Guiderai la riscrittura di un sistema di prenotazioni che muove 4 milioni di GBP l’anno e oggi perde circa un ordine a settimana” dice a un bravo sviluppatore molto più di un paragrafo di aggettivi, e seleziona chi trova la cosa interessante. Nomina lo stack in una riga, indicato come stato attuale e non come requisito: un ottimo sviluppatore impara il tuo framework in quindici giorni e uno debole non si salva perché lo conosce già.

Pubblica la fascia salariale. I ruoli senza fascia attirano chi ottimizza sul volume, e sprecano un intero giro di colloqui per scoprire una distanza che un numero avrebbe mostrato in dieci secondi. Se la fascia ti mette a disagio da pubblicare, probabilmente è sbagliata.

Sii esplicito sulla forma del team, compreso il fatto che è piccolo. “Sarai il nostro primo sviluppatore, con riporto al fondatore” è un’attrattiva vera per alcuni e un deterrente vero per altri, e vuoi entrambi gli effetti. La vaghezza qui produce candidati che accettano e se ne vanno al mese quattro.

Poi taglia l’elenco dei requisiti a ciò che serve davvero. Quattordici punti elenco sono una lista di preferenze travestita da specifica, e scoraggiano candidature di persone che avrebbero fatto bene il lavoro.

Condurre una valutazione tecnica che non puoi condurre

Senza un fondatore tecnico la tentazione è valutare la sicurezza di sé, che non correla con nulla. Struttura il processo perché il giudizio tecnico si formi in un punto di cui ti puoi fidare.

Usa un esercizio breve e pagato da fare a casa. Due o tre ore, retribuite a una tariffa sensata, con una traccia scritta che indichi i vincoli e i criteri di valutazione. Gli esercizi non pagati di più giorni filtrano il tempo libero e non la capacità, e ti fanno perdere proprio i candidati esperti che vuoi. Tienilo vicino al lavoro vero: una piccola funzionalità su una base di codice realistica predice il mestiere meglio di un rompicapo di algoritmi.

Porta un valutatore tecnico esterno per la revisione e il colloquio di approfondimento. Un’ora di uno sviluppatore senior che legge la consegna e fa ripercorrere al candidato le sue decisioni dice più di qualsiasi quantità di domande di competenza. Metti in conto una tariffa giornaliera e trattala come un’assicurazione economica contro un’assunzione che costa un anno.

Chiedi al candidato di spiegare il suo codice a te, che non sei tecnico. Se non sa descrivere cosa ha costruito e perché in termini che segui, quella è un’informazione: gran parte del lavoro consiste nel comunicare con persone che non sono sviluppatori.

Prendi le referenze sul serio e fai una domanda precisa: cosa ha fatto questa persona quando non era d’accordo con una decisione. La risposta separa chi solleva i problemi presto da chi tace e costruisce correttamente la cosa sbagliata.

I controlli sul diritto al lavoro non sono facoltativi

Ogni datore deve verificare che un candidato abbia il diritto di lavorare nel Regno Unito, e la verifica va completata prima dell’inizio del rapporto. Le indicazioni GOV.UK sulla verifica del diritto al lavoro di un candidato indicano tre metodi accettabili: un controllo online con un share code, un controllo manuale dei documenti originali con il candidato presente, o un controllo tramite un fornitore di identità certificato che usa tecnologia di validazione dei documenti. I cittadini britannici e irlandesi non possono ottenere uno share code, quindi il loro controllo passa dai documenti o da un fornitore di identità.

Conserva le copie per la durata del rapporto e per due anni dopo, e metti a calendario un controllo ripetuto per chiunque abbia un permesso di lavoro a termine. È la documentazione che stabilisce la scusante di legge se più avanti emerge un problema.

L’esposizione non è banale. GOV.UK afferma che un datore può subire una sanzione civile fino a 60.000 GBP per ogni lavoratore irregolare quando il controllo corretto non è stato fatto. Per un’azienda alle sue prime due assunzioni è più dell’intero budget di ricerca. Inserisci il controllo nel processo di offerta invece che nel primo giorno, così nessuna data di inizio arriva con le carte in sospeso.

Assumere fuori dal Regno Unito

Se il candidato che vuoi non ha già il permesso di lavorare qui, ti serve una sponsor licence prima di poterlo assumere, e quello è un progetto e non un modulo.

Richiedere una Worker licence costa 611 GBP per uno sponsor piccolo o non profit e 1.682 GBP per uno medio o grande, secondo le indicazioni GOV.UK sulla sponsorizzazione. La maggior parte delle decisioni arriva in meno di otto settimane, con un servizio prioritario da 750 GBP che dà una risposta in dieci giorni lavorativi quando ci sono posti. Pianifica sui tempi standard, perché quella coda va in ordine di arrivo.

Il ruolo stesso deve superare una soglia salariale. Il visto Skilled Worker richiede uno sponsor autorizzato e un certificate of sponsorship, e GOV.UK fissa il requisito salariale standard a 41.700 GBP l’anno o alla tariffa corrente per la professione, a seconda di quale sia più alta. Per gran parte dei ruoli software è la tariffa corrente, e non la soglia generale, a vincolare.

Poi c’è l’Immigration Skills Charge, a carico del datore quando viene assegnato il certificate of sponsorship. GOV.UK la fissa a 480 GBP per i primi dodici mesi per uno sponsor piccolo o non profit e a 1.320 GBP per uno medio o grande, con 240 GBP o 660 GBP per ogni semestre successivo. Su una sponsorizzazione triennale per un datore medio fa 3.960 GBP, e lo sponsor non può ribaltarla sul lavoratore.

Metti a budget da 6.000 a 9.000 GBP e tre-quattro mesi per una prima assunzione sponsorizzata. Spesso è la scelta giusta per una competenza rara, e quasi mai per una prima assunzione che ti serve operativa in sei settimane.

L’inserimento e i primi novanta giorni

Fissa un obiettivo misurabile: il nuovo sviluppatore manda qualcosa in produzione nella prima settimana. Non una funzionalità importante, un piccolo cambiamento reale che i clienti vedono. È la prova più rapida che il tuo ambiente sia davvero praticabile, e sposta la psicologia dell’assunto da osservatore a proprietario.

Perché accada devono essere vere diverse cose. Un setup locale documentato che funziona su una macchina pulita. Account e accessi predisposti prima del primo giorno invece che richiesti quel giorno. Un percorso di rilascio che non richiede la benedizione di una persona precisa. Un affiancatore designato con l’agenda davvero libera quella settimana. Se ne manca uno, la prima cosa che il nuovo sviluppatore impara è che i tuoi sistemi non funzionano.

Al giorno trenta dovrebbe aver rilasciato una funzionalità significativa e saper descrivere l’attività, non solo la base di codice. Al giorno sessanta dovrebbe rivedere il codice degli altri e mettere in discussione le decisioni. Al giorno novanta dovrebbe individuare il lavoro invece di riceverlo.

Quei traguardi sono anche il tuo sistema di allarme precoce. Chi al giorno sessanta non mette in discussione nulla o è fuori posto o è gestito troppo stretto, e in entrambi i casi si aggiusta al mese tre a una frazione di quello che costa al mese nove. Il nostro articolo sull’inserimento degli sviluppatori che rilascia nella prima settimana ne descrive la meccanica.

La retention, calcolata invece che raccontata

Sostituire uno sviluppatore costa la parcella di ricerca, l’avviamento e la consegna che chi se ne va ha smesso di produrre dal momento delle dimissioni. Su un ruolo da 60.000 GBP, 12.000 GBP di parcella più tre mesi di resa ridotta portano la cifra reale oltre 25.000 GBP. È una stima interna, e prudente, perché esclude la conoscenza che se ne va con lui.

Gli sviluppatori raramente se ne vanno solo per i soldi, anche se i soldi sono la ragione che dichiarano. Se ne vanno perché non riescono a consegnare. Un rilascio che richiede tre giorni, una coda di revisione che nessuno smaltisce, una roadmap che cambia ogni quindici giorni, sei mesi di lavoro cancellati prima dell’uscita. Ognuna di queste cose dice a una persona capace che il suo sforzo non si converte in risultati, e le persone capaci hanno alternative.

La spesa di retention commercialmente razionale non sta quindi nei benefit. Sta nell’automazione dei rilasci, in un processo di revisione che funziona, in una roadmap stabile e in abbastanza margine perché la manutenzione avvenga prima di diventare un’emergenza. Sono gli stessi investimenti che aumentano la velocità di consegna.

Le fasce salariali contano ancora, in un modo preciso. Gli stipendi vanno alla deriva quando il mercato si muove e le revisioni interne no, e la prima persona che se ne accorge è quella che fa colloqui altrove. Rivedi le fasce ogni anno su dati pubblici come il bollettino ONS sulle retribuzioni dei dipendenti nel Regno Unito, che colloca la retribuzione annua lorda mediana dei dipendenti a tempo pieno a 39.039 GBP nell’aprile 2025. Costa molto meno di una lettera di dimissioni.

Il modello ibrido su cui atterra la maggior parte

Dopo diciotto mesi, quasi tutte le aziende partite per costruire un team interno finiscono a metà strada: un piccolo nucleo permanente che possiede il prodotto, con un’agenzia o dei freelance agganciati per specializzazioni e picchi. Non è un fallimento del piano. È l’assetto che sopravvive al contatto con una roadmap vera.

Funziona quando sono vere tre cose. Il team interno possiede l’architettura e l’ambiente di produzione, così la parte esterna contribuisce dentro una struttura che controlli tu invece di definirne una. La revisione del codice va in entrambe le direzioni, quindi il lavoro esterno lo rivede il tuo team e il lavoro del tuo team lo rivedono loro. E il perimetro della parte esterna è scritto come risultati e non come ore.

Fallisce quando l’agenzia diventa una scatola nera. Il segnale è che nessuno in casa sa spiegare come funziona un componente. Impediscilo in modo strutturale: il lavoro esterno finisce nel tuo repository, si rilascia dalla tua pipeline ed è documentato come condizione di pagamento invece che come cortesia finale. Tieni in contratto una sessione di trasferimento di conoscenza a cadenza fissa, mensile di solito basta. Il nostro confronto su esternalizzare lo sviluppo software, Regno Unito contro offshore vale la lettura prima di scegliere dove sta la metà esterna, perché la sovrapposizione dei fusi cambia parecchio la resa di questo modello.

Un piano a tappe per i primi diciotto mesi

Mesi uno-tre: non assumere. Scrivi la roadmap dei mesi quattro-diciotto e falla rivedere da qualcuno di tecnico che non ti sta vendendo nulla. Compra il lavoro immediato da un’agenzia o da un freelance. Il risultato di questa fase è una risposta difendibile sulla continuità del lavoro.

Mesi quattro-nove: assumi il senior generalista. Una persona, ben pagata, con autorità sulle decisioni tecniche. Tieni la capacità esterna in parallelo per i primi due mesi, così la consegna non si ferma mentre la persona si orienta. Punto di decisione al mese nove: la roadmap è ancora piena, e questa persona sa specificare lavoro per altri.

Mesi dieci-quindici: se entrambe le risposte sono sì, aggiungi due sviluppatori per arrivare alla forma stabile di tre, e nomina un product owner anche se è un fondatore che assegna formalmente un giorno a settimana. Se una risposta è no, resta a una persona più capacità esterna, che è uno stato permanente del tutto valido per un’azienda il cui software sostiene il prodotto invece di esserlo.

Mesi sedici-diciotto: il secondo punto di decisione. Aggiungi la quarta e la quinta persona solo se il vincolo è davvero capacità e non direzione. I team crescono per la ragione sbagliata più spesso che per quella giusta, e il sintomo è un backlog lungo ma non ordinato per priorità. A ogni punto di decisione chiediti se la prossima assunzione è più veloce della prossima giornata di agenzia.

Da dove iniziare

Scrivi prima la roadmap a diciotto mesi, rispondi onestamente al test in tre parti, poi quota entrambe le strade con i numeri veri e non con il solo stipendio. Quasi tutte le aziende scoprono che la prima assunzione dovrebbe essere una persona senior invece di due profili intermedi, e che i sei mesi precedenti si comprano meglio a giornata.

Mecanik lavora su entrambi i lati. Portiamo avanti incarichi di sviluppo software per aziende che non sono pronte ad assumere, e forniamo capacità senior tramite assumere uno sviluppatore web ai team che costruiscono un nucleo e hanno bisogno di coprire i picchi mentre lo fanno. Se stai valutando le due strade, la conversazione utile è quella sulla roadmap, perché è lei a decidere.

Domande frequenti

Quanto costa assumere uno sviluppatore software nel Regno Unito? Metti a budget circa 1,4 volte lo stipendio nel primo anno e 1,2 volte dopo. Su uno stipendio di 60.000 GBP fa circa 85.600 GBP nel primo anno, composti da stipendio, National Insurance a carico del datore al 15 per cento oltre la soglia secondaria di 5.000 GBP per l’anno fiscale 2026 a 2027, un contributo pensionistico minimo del 3 per cento sui redditi rilevanti, attrezzatura, strumenti e una parcella di ricerca. Le cifre di stipendio, attrezzatura, strumenti e ricerca sono stime interne di pianificazione.

La mia prima assunzione tecnica deve essere un senior o un junior? Un senior, e generalista invece che specialista. Uno sviluppatore junior è un saldo negativo sulla consegna per tre-nove mesi e ha bisogno di una persona senior che riveda il suo lavoro, quindi assumerlo per primo genera codice non controllato dentro un sistema da cui dipende la tua attività. La riscrittura di norma costa più dello stipendio risparmiato. I junior sono un buon investimento quando ci sono già un senior con tempo per il mentoring e un processo di revisione.

Quanti sviluppatori servono per costruire un team di sviluppo software? Tre è la forma più piccola che sopravvive all’uscita di qualcuno: un technical lead più due sviluppatori, intorno a 250.000 GBP l’anno con tutti i costi. Un senior generalista può mandare avanti una singola applicazione ma non ha ridondanza per malattia, ferie o dimissioni. A cinque uno specialista e un product owner dedicato iniziano a ripagarsi, e dieci sono di fatto due team che richiedono una titolarità esplicita dei servizi.

Quando un’agenzia è meglio di sviluppatori interni? Quando il lavoro ha una fine definita, quando hai meno di nove mesi circa di roadmap continua, o quando ti serve capacità prima di quanto un giro di assunzioni possa darla. Un’agenzia è un costo variabile che puoi fermare, quindi un mese storto costa un mese e non un anno. Oltre i diciotto mesi di lavoro continuo, un team interno vince nettamente su costo e velocità.

Cosa devo verificare prima di assumere uno sviluppatore nel Regno Unito? Completa un controllo sul diritto al lavoro prima dell’inizio del rapporto, con uno share code online, con i documenti originali in presenza del candidato, o tramite un fornitore di identità certificato. GOV.UK afferma che la sanzione civile può arrivare a 60.000 GBP per ogni lavoratore irregolare quando il controllo corretto non è stato fatto. Se sponsorizzi qualcuno da fuori dal Regno Unito ti servono anche una sponsor licence, un certificate of sponsorship e l’Immigration Skills Charge.