Chi ha sviluppato il nostro software se n’è andato: la checklist dei primi 7 giorni

Gennaio 2024: una PMI manifatturiera del Nord Italia si sveglia e scopre che il programmatore che gestiva il gestionale di produzione da sei anni ha rassegnato le dimissioni la sera prima, senza preavviso. Nessuna documentazione, nessun passaggio di consegne, credenziali di accesso al server conosciute solo da lui. Il software girava in produzione da anni. Nessuno sapeva dove stava il codice.
Questa situazione capita più spesso di quanto si pensi, e quasi sempre coglie l’azienda impreparata. Lo sviluppatore sparito, che sia un freelance che smette di rispondere o un dipendente che se ne va di colpo, lascia un vuoto tecnico che può bloccare operatività, aggiornamenti e manutenzione.
Nei primi sette giorni puoi fare la differenza tra un problema gestibile e una crisi lunga mesi. Questa è la checklist.

Le prime 48 ore: accessi e controllo dei danni

La priorità assoluta non è trovare un sostituto. È capire cosa hai e cosa non hai più.
Entro le prime 24 ore devi cambiare tutte le credenziali a cui lo sviluppatore aveva accesso. Server, database, repository Git, pannelli di controllo, account email di servizio, chiavi API. Non è una questione di fiducia personale: è la procedura corretta ogni volta che un membro del team con accesso privilegiato lascia l’organizzazione. Farlo dopo una settimana è già tardi.
Fai un elenco scritto di ogni sistema che lo sviluppatore gestiva. Parti dalle email, dai contratti, dagli scambi su Slack o Teams. Spesso le credenziali sono sparse in thread dimenticati o in file condivisi. Recupera tutto quello che riesci prima che gli accessi scadano o vengano disattivati.
Se lo sviluppatore era un freelance e usava account personali per i servizi (hosting, repository, DNS), hai un problema in più: quegli account potrebbero non essere tecnicamente tuoi. Contatta il fornitore del servizio con i dati del tuo contratto e chiedi il trasferimento della proprietà. Molti provider lo gestiscono con una procedura standard, ma serve tempo.
Il software già in produzione continuerà a girare. Il rischio immediato non è che si spenga domani mattina: è che si rompa qualcosa e nessuno sappia come intervenire.

Giorni 2-4: mappa il codice e le dipendenze

Adesso che gli accessi sono sotto controllo, serve capire cosa c’è dentro.
Trova il repository del codice sorgente. Se non sai dove sia, controlla GitHub, GitLab, Bitbucket, oppure cerca nei file di configurazione del server. Se il codice è solo sull’hard disk del developer e non hai modo di recuperarlo, la situazione è seria ma non necessariamente senza uscita: un tecnico può analizzare l’applicativo in produzione e ricostruire parte della logica.
Una volta trovato il codice, fai una copia completa su un repository sotto il tuo controllo. Adesso, non tra qualche giorno.
Poi mappa le dipendenze esterne: librerie, servizi di terze parti, licenze software, domini, certificati SSL con date di scadenza. Spesso uno sviluppatore gestisce in autonomia rinnovi e aggiornamenti che l’azienda non vede. Un certificato SSL scaduto blocca il sito. Un dominio non rinnovato fa sparire tutto. Verifica le scadenze dei prossimi sei mesi e segnati tutto su un foglio.
Cerca anche la documentazione. Se c’è, bene. Se non c’è, è normale: la maggior parte dei progetti custom ha documentazione scarsa o assente. Non è un dramma adesso, ma è una delle prime cose che il prossimo sviluppatore dovrà affrontare. Per capire come gestire questa fase nel tempo, vale la pena leggere cosa comporta la manutenzione software custom per le PMI.

Giorni 4-6: capire cosa si può fare da soli e cosa no

A questo punto hai una fotografia abbastanza chiara della situazione. Serve una decisione.
Alcune aziende hanno internamente qualcuno con competenze tecniche di base: un IT manager, un sistemista, un developer part-time. Se c’è questa figura, può gestire la continuità operativa a breve termine mentre cerchi una soluzione strutturata.
Se non c’è nessuno con competenze tecniche, la domanda da farti è questa: il software è abbastanza stabile da reggere qualche settimana senza interventi? Se la risposta è sì, hai tempo per cercare con calma. Se la risposta è no, o se ci sono aggiornamenti urgenti in sospeso, hai bisogno di supporto esterno subito.
Questo è il momento giusto per fare una valutazione onesta del codice. Un tecnico esterno può leggere il repository e dirti in poche ore se il codice è gestibile, se ci sono problemi latenti, se l’architettura regge. Non è un audit formale: è una lettura rapida che ti dà le informazioni per decidere.
Una cosa che spesso si sottovaluta in questa fase è la questione della proprietà intellettuale. Se lo sviluppatore era un freelance senza un contratto scritto che cedesse esplicitamente i diritti patrimoniali sul codice, tecnicamente potrebbe rivendicare la paternità dell’opera (L. 633/1941). Non è detto che lo faccia, ma è un rischio reale. Se hai dubbi sul contratto, parla con un legale prima di procedere con modifiche o redistribuzioni del codice.
Se ti trovi in una situazione simile a quella di un’azienda il cui fornitore ha chiuso i battenti, la guida su come recuperare software e dati quando il fornitore ha chiuso copre scenari tecnici analoghi e può darti un riferimento utile.
Se hai bisogno di un punto di vista tecnico rapido su quello che hai trovato, raccontaci la situazione: possiamo fare una prima lettura del codice e dirti cosa stai guardando.

Giorno 7: il piano per i prossimi 30 giorni

Arrivato qui, hai gli accessi sotto controllo, una copia del codice, una mappa delle dipendenze e un’idea della stabilità del sistema. Adesso serve un piano.
Le opzioni principali sono tre.
La prima è trovare un nuovo sviluppatore, freelance o agenzia, che prenda in mano il progetto. Questa è la scelta giusta se il software è strategico per il business e vuoi continuare a svilupparlo. Il tempo di onboarding dipende molto dalla qualità del codice e dalla documentazione: con un repository ordinato e qualche commento utile, un paio di settimane bastano per partire. Senza nulla, si parla di più tempo. Per capire cosa valutare nella scelta, la guida su come scegliere un’agenzia di sviluppo software custom copre i criteri operativi.
La seconda opzione è valutare se il software vale ancora la pena di essere mantenuto. Se è datato, mal scritto o non più adatto alle esigenze attuali, questa crisi può essere l’occasione per ripensare l’architettura. Non è una decisione da prendere d’impulso nei primi sette giorni, ma è una domanda legittima da mettere sul tavolo.
La terza opzione, quella che sconsigliamo apertamente, è non fare nulla e sperare che il software regga. Può funzionare per settimane o mesi, ma ogni giorno che passa senza manutenzione aumenta il rischio di un’interruzione non pianificata nel momento peggiore. Un software senza nessuno che lo conosca è una bomba a orologeria, non un bene aziendale.
Un’ultima cosa pratica: qualunque sia la scelta, inizia subito a costruire un minimo di documentazione interna. Anche solo un documento con la lista dei servizi usati, le credenziali (in un gestore di password aziendale, non in un foglio Excel), le scadenze e i contatti dei fornitori. Se questa situazione si ripetesse, quel documento varrebbe più di qualsiasi altra precauzione.

Se hai trovato il repository ma non sai cosa stai guardando, o se il software è in produzione e non hai nessuno che lo conosca, scrivici: possiamo fare una prima analisi tecnica e aiutarti a capire da dove partire.

Q: Cosa faccio se lo sviluppatore non risponde più e non ho accesso al codice?
A: Prima mossa: recupera le credenziali di accesso ai server e ai repository da qualsiasi canale disponibile (email, contratti, colleghi). Se hai solo l’eseguibile senza codice sorgente, valuta un’analisi tecnica per capire cosa si può estrarre. Agisci entro 24-48 ore per evitare che le credenziali scadano o che l’accesso venga revocato.
Q: Chi è il proprietario del codice se lo sviluppatore era un freelance?
A: Dipende dal contratto. Senza una clausola esplicita di cessione dei diritti patrimoniali, il codice potrebbe restare in capo all’autore per legge (L. 633/1941). Se non hai un contratto scritto, la situazione è complicata ma non irrecuperabile: un legale specializzato in proprietà intellettuale può aiutarti a capire i margini.
Q: Quanto tempo ci vuole per trovare un nuovo sviluppatore che prenda in mano il progetto?
A: Varia molto in base alla complessità del codice e alla documentazione disponibile. Con buona documentazione e codice ordinato, un paio di settimane bastano per l’onboarding. Senza documentazione e con codice non strutturato, si parla di qualche mese prima che il nuovo sviluppatore sia operativo in autonomia.
Q: Devo cambiare tutte le password subito?
A: Sì, subito. Database, server, repository, pannelli di controllo, account email di servizio: tutto quello a cui lo sviluppatore aveva accesso va ruotato nelle prime 24 ore. Non è una questione di fiducia personale: è una procedura standard quando cambia un membro del team con accesso privilegiato.
Q: Il software può smettere di funzionare se lo sviluppatore se ne va?
A: Il software già rilasciato continua a girare. Il rischio non è l’interruzione immediata, ma il blocco in caso di guasto, aggiornamento necessario o scadenza di licenze gestite dallo sviluppatore. Per questo i primi 7 giorni servono a mappare queste dipendenze prima che diventino un’emergenza.