Recuperare il codice sorgente (e gli accessi) da uno sviluppatore sparito

Hai pagato per un'app, un sito o un gestionale. Funziona, è online, ci lavorano persone vere. Ma quando provi a metterci mano ti accorgi di una cosa che gela il sangue: non controlli niente. Il codice è su un GitHub che non è tuo. Il dominio è registrato a nome di qualcun altro. Il server lo gestisce una persona che non risponde più. Il prodotto è tuo solo sulla carta.

Se sei a questo punto, probabilmente sei già passato dal silenzio dello sviluppatore. Ora il problema è diverso e più concreto: riprendere il possesso fisico del tuo prodotto. Questo articolo è la sequenza esatta che faccio seguire quando un founder mi chiama nel panico perché «non ho in mano niente».

Prima regola: non è il codice il pezzo più urgente

L'istinto è correre dietro al codice sorgente. Sbagliato. Il codice, nella maggior parte dei casi, è recuperabile o ricostruibile. Quello che ti può fare danni veri e irreversibili in 48 ore è perdere il dominio e gli accessi ai servizi che fanno girare i soldi (pagamenti, email transazionali, account su cui sono registrati i tuoi clienti). Quelli vengono prima.

La priorità corretta è questa, in ordine: dominio e DNS → pagamenti e dati dei clienti → hosting e server → database → codice sorgente. Adesso vediamo perché e come.

Step 1 — Fai l'inventario di cosa NON controlli

Apri un foglio e segna, per ognuna di queste voci, se l' accesso è a tuo nome, condiviso o solo dello sviluppatore:

• Dominio — su che registrar è (Aruba, Namecheap, GoDaddy, Cloudflare…) e a chi è intestato.
• DNS — chi controlla i record (spesso è separato dal registrar, es. Cloudflare).
• Hosting / server — dove gira il prodotto (AWS, Vercel, Hetzner, un VPS, un hosting condiviso).
• Repository del codice — GitHub, GitLab, Bitbucket, e su quale account/organizzazione.
• Database — dove sono i dati veri (gestito, self-hosted, dentro al server).
• Pagamenti— Stripe, PayPal, Nexi: a nome di chi è l'account che incassa.
• Email transazionali — SendGrid, Mailgun, Postmark: è ciò che manda conferme e reset password ai clienti.
• Account terzi — Google Cloud, app store (Apple/ Google Play), Firebase, servizi di mappe, ecc.

Questo foglio è la tua mappa. Tutto ciò che è «solo dello sviluppatore» è un punto di rischio. Tutto ciò che è «a tuo nome» è già salvo.

Step 2 — La verità scomoda sul «tuo» codice

Qui devo essere onesto, perché nessuno te lo dice: il codice potrebbe non essere legalmente tuo come dai per scontato. In Italia, se non c'è un contratto che cede esplicitamente la proprietà intellettuale(clausola di IP assignment / cessione dei diritti di utilizzazione economica), chi ha scritto il software mantiene una parte dei diritti, anche se l'hai pagato.

Non è una consulenza legale e ogni caso fa storia a sé — ma prima di partire all'attacco recupera il contratto o anche solo le email e i preventivi: ti servono sia per capire cosa puoi pretendere, sia se la cosa dovesse finire in mano a un avvocato. Nella pratica, la via «tecnica» (ti riprendi gli accessi che sono di fatto tuoi) è quasi sempre più veloce di quella legale. Ma sapere come stai messo cambia il tono con cui scrivi l'ultimo messaggio allo sviluppatore.

Step 3 — Recupera per primo dominio e DNS

Il dominio è il pezzo che, se lo perdi, ti porta giù tutto: sito, email aziendali, link nei materiali, posizionamento. Ed è anche quello che uno sviluppatore scontento può «tenere in ostaggio» più facilmente.

• Se è intestato a te — entra nel registrar, cambia la password, attiva la 2FA e togli lo sviluppatore dagli utenti delegati. Fatto.
• Se non hai l'accesso— quasi tutti i registrar hanno una procedura di recupero basata sull'email o sui dati dell'intestatario. Se l'intestatario sei tu (anche solo come persona/azienda nei dati WHOIS), puoi rivendicarlo aprendo un ticket col registrar e mostrando un documento.
• Per trasferirlo altrove ti serve il codice di autorizzazione (authcode / codice EPP). Se non riesci a ottenerlo, il trasferimento via supporto del nuovo registrar è comunque possibile, solo più lento.

Step 4 — Metti in sicurezza pagamenti e dati dei clienti

Se incassi tramite un account Stripe/PayPal che non è intestato alla tua azienda, hai un problema doppio: di soldi e di dati. Verifica subito a nome di chi è l'account che riceve i pagamenti e a quale conto sono collegati i payout. Lo stesso vale per il servizio di email transazionali: se sparisce, i tuoi clienti smettono di ricevere conferme e reset password, e te ne accorgi solo quando si lamentano.

Dove puoi, esporta subito: la lista clienti, gli ordini, le fatture. Sono tuoi e un export ti mette al riparo qualunque cosa succeda agli accessi.

Step 5 — Hosting, server e database

Qui l'obiettivo è duplice: ottenere l'accesso e fare un backup completo prima che qualcuno spenga qualcosa.

• Provider cloud(AWS, Vercel, GCP) — se l'account è tuo, cambia credenziali e revoca le chiavi API/access token dello sviluppatore. Se è suo, l'unica via è farti dare l'accesso o ricreare l'infrastruttura altrove a partire dal backup.
• Server / VPS — se hai accesso, fai uno snapshot completodel disco. È la tua assicurazione: dentro c'è spesso il codice in esecuzione e le configurazioni.
• Database — fai un dump completo e scaricatelo in locale. I dati sono la parte che non si ricostruisce: il codice si riscrive, gli ordini di tre anni no.

Step 6 — Il codice sorgente, finalmente

Adesso che le cose che fanno male sono al sicuro, il codice. Tre scenari:

• Hai accesso al repository — perfetto. Trasferisci la proprietà del repo alla tua organizzazione (GitHub/GitLab lo fanno in pochi click) oppure clonalo in locale e ricaricalo su un account tuo. Poi togli lo sviluppatore dai collaboratori.
• Non hai il repo, ma hai il server — il codice in esecuzione è quasi sempre lì. Da uno snapshot del server recuperi il sorgente (o quantomeno il build) e riparti.
• Non hai né repo né server — è il caso peggiore, ma non è la fine. Vai allo step successivo.

Se non hai NIENTE in mano

Capita: prodotto online, ma zero accessi. Anche qui c'è una via. Il prodotto in produzione è una fonte di informazione: il frontend è scaricabile (è quello che il browser già riceve), le API si possono mappare osservando come il sito le chiama, i dati visibili si possono esportare. Non recuperi il sorgente originale, ma ricostruisci abbastanza da non ripartire dal foglio bianco — spesso con un risultato più pulito di prima.

La domanda vera, a quel punto, non è «come recupero l'esatto codice di prima» ma «mi conviene recuperarlo o rifarlo?». Spesso un software lasciato a metà da uno sviluppatore sparito è più costoso da capire e sistemare che da rifare bene. È una decisione che si prende guardando il codice, non a naso.

Come non ritrovartici mai più

Quando sei di nuovo in controllo, blinda la situazione così non dipenderai mai più dalla buona volontà di una sola persona:

• Tutti gli account a nome della tua azienda. Dominio, hosting, repo, pagamenti, email: intestatario sei tu, sempre. Lo sviluppatore viene invitato, non è il proprietario.
• Il repository sulla tua organizzazione dal primo giorno. Chi lavora ci accede come collaboratore.
• Clausola di cessione IP nel contratto. Una riga che dice che il codice prodotto è tuo. Senza, sei punto e a capo.
• Un backup automatico di codice e database che non passa dalle mani di chi sviluppa.

Dove entro io

Quando un founder mi chiama in questa situazione, la prima cosa che facciamo insieme è proprio l'inventario di sopra: in mezza giornata si capisce cosa è davvero in pericolo e cosa è già salvo. Da lì recupero gli accessi tecnici, metto in sicurezza dati e infrastruttura, e ti dico onestamente se il software esistente vale la pena di essere ripreso o no. Non è un lavoro da «altro freelance»: serve qualcuno che abbia visto abbastanza sistemi da sapere dove guardare.

Se ci sei dentro adesso, la cosa peggiore che puoi fare è aspettare sperando che lo sviluppatore si rifaccia vivo. Ogni giorno che passa è un rischio in più su dominio, dati e accessi.

Domande frequenti