Il tuo sviluppatore non risponde più: 5 cose da fare prima di farti prendere dal panico

Ti svegli un mattino, mandi un messaggio al tuo sviluppatore, e nessuno risponde. Passa un giorno. Due. Una settimana. Il progetto è in pausa. Tu non hai accesso al codice. Non sai esattamente cosa è stato fatto. E adesso devi capire come uscirne — possibilmente senza buttare via i mesi di lavoro che hai già pagato.

Questo articolo non è teoria. È quello che faccio quando un founder mi chiama con questo problema, ed è la sequenza esatta che gli faccio seguire nelle prime 48 ore.

Prima cosa: capire se è davvero grave

Non ogni silenzio è una sparizione. C'è una differenza enorme tra un dev che non risponde da 3 giorni perché ha avuto un problema personale, e uno che ha smesso di lavorare per te da settimane. Prima di entrare in modalità emergenza, verifica questi tre segnali:

• Più di 7 giorni di silenzio dopo che gli hai scritto su 2 canali diversi (email + Slack/WhatsApp).
• Nessun commit recente sul repository — se hai accesso a GitHub/GitLab, controlla l'ultima attività. Niente da 2+ settimane è un'ottima ragione di preoccupazione.
• Pagamenti recenti non corrispondono a lavoro consegnato. Se hai pagato per le ultime due milestone e non vedi cosa è stato fatto, sei già in territorio rischioso.

Se due o tre di questi segnali sono presenti, smetti di aspettare e segui i 5 step qui sotto. Ogni giorno che passa rende più difficile il recupero.

Step 1 — Recupera l'accesso a tutto, subito

La prima cosa che fai oggi, non domani: ricostruisci la lista completa degli accessi che dovresti avere e verifichi quali ti mancano.

Lista minima:

• Repository del codice (GitHub, GitLab, Bitbucket). Tu devi essere owner o admin — non "contributor".
• Hosting / cloud provider (Vercel, AWS, Hetzner, ecc.) — devi essere proprietario dell'account, o almeno avere accesso a billing e deploy.
• Dominio e DNS — questo è quello dove ti possono fregare di più. Se il dev ha registrato il dominio a nome suo, hai un problema serio.
• Database e backup — accesso o almeno backup recente che tu possa ripristinare.
• Servizi terzi — Stripe, Mailchimp, Twilio, ecc. Tutti i provider devono avere TE come owner.
• Documentazione — Notion, Google Drive, qualsiasi posto dove ci sono specifiche, password, runbook.

Se ti manca qualcuno di questi, agisci oggi stesso. Molti provider hanno procedure di recupero account per dispute legali se il dominio o il cloud è registrato a nome dell'azienda con prova di pagamento. Contatta il loro supporto subito.

Se invece il dev ha registrato tutto a nome suo personale — dominio compreso — sappi che hai un problema legale, non solo tecnico. Un avvocato che tratta di proprietà intellettuale ti costa meno di un mese di sviluppo perso.

Step 2 — Fotografa lo stato del progetto

Una volta recuperati gli accessi, devi capire dove sei davvero. Non quello che il dev diceva di aver fatto. Quello che esiste oggi nel codice e in produzione.

Da fare entro 24-48 ore:

1. Clona il repository e dai un'occhiata alla struttura. Anche se non sai leggere il codice, conta quanti file/cartelle ci sono e quando è stato l'ultimo commit.
2. Apri la versione in produzione (se esiste) e testa ogni feature una per una. Annota cosa funziona, cosa no, cosa è incompleto.
3. Confronta con la lista feature che il dev doveva consegnare. Quante sono effettivamente in produzione? Quante sono "quasi finite"? Quante non sono mai partite?
4. Salva tutto in un documento condiviso — ti servirà sia per il passaggio al prossimo dev, sia eventualmente in caso di azione legale.

Questo documento — chiamalo "Stato attuale del progetto" — è la base su cui qualsiasi nuovo dev o consulente può costruire. Senza, ogni nuovo arrivato dovrà rifare il lavoro di scoperta da zero, allungando i tempi di settimane.

Step 3 — Audit tecnico esterno (l'errore di NON farlo)

A questo punto la tentazione è enorme: assumere subito un altro freelance, fargli vedere il codice, e dirgli "finisci quello che manca". Non farlo.

Tre motivi:

• Non sai se il codice esistente vale la pena salvarlo. Il prossimo dev ti dirà sempre che vale la pena rifarlo da zero — è il suo interesse economico. Senza una valutazione indipendente, non puoi decidere.
• Non sai quanto tempo serve davvero. Senza un audit, il preventivo del prossimo freelance sarà ottimistico (per chiudere il deal) e si gonfierà in corsa (perché scoprirà problemi che potevano essere visti prima).
• Non hai un piano di intervento prioritizzato. Il prossimo dev comincerà dal pezzo che lo entusiasma di più, non da quello che ti porta in produzione prima.

La cosa più sensata da fare adesso è un audit tecnico esterno — uno indipendente dal dev sparito e dal prossimo che assumerai. In 2-3 giorni produce un report scritto con: cosa funziona, cosa è recuperabile, cosa è da riscrivere, e una roadmap di intervento priorizzata.

Costa qualche centinaio di euro. Ti fa risparmiare migliaia. Ne ho scritto in dettaglio nella pagina audit tecnico software.

Step 4 — Decidere: sblocco, sostituzione, riscrittura

Con l'audit in mano, hai finalmente i dati per prendere una decisione vera. Ci sono tre opzioni, e nessuna è intrinsecamente sbagliata — dipende dal tuo caso specifico.

Opzione A — Sblocco

Quando ha senso: il codice esistente è recuperabile, il 60-80% del lavoro è stato fatto bene, manca finire 2-3 feature e portare in produzione. Tempi: 2-4 settimane. Costo: molto inferiore a rifare. Questa è la strada giusta per l'80% dei casi che vedo.

Opzione B — Sostituzione del dev

Quando ha senso: il codice esistente è decente, il rapporto con il dev precedente era il problema (non il lavoro fatto). Attenzione: il prossimo dev deve essere selezionato con un audit indipendente alle spalle, non con interview standard.

Opzione C — Riscrittura da zero

Quando ha senso: il codice è effettivamente irrecuperabile (raro), oppure le scelte architetturali sono così sbagliate che recuperarle costa più che rifare. La riscrittura sembra sempre più veloce, ma quasi mai lo è — devi rifare anche le decisioni che il dev precedente aveva già preso bene, oltre a quelle sbagliate.

La regola che do ai miei clienti: riscrivere da zero ha senso solo se l'audit ti dice esplicitamente che >70% del codice è da buttare. Sotto questa soglia, lo sblocco è quasi sempre la scelta economicamente migliore.

Step 5 — Cosa NON fare

Cinque errori catastrofici che vedo fare ai founder in questa situazione. Evitali e hai già metà del problema risolto.

1. NON assumere il primo freelance che trovi su Upwork o LinkedIn per "finire il lavoro". Il ricambio di un dev ferito da uno scenario "dev precedente sparito" è un campo minato. Serve seniority, non disponibilità immediata.
2. NON minacciare azioni legali via WhatsApp al dev sparito (anche se te lo meriti). Se serve azione legale, la fai fare a un avvocato. Tu intanto devi concentrarti sul progetto.
3. NON pagare in anticipo il prossimo dev più di 1-2 settimane. Sei già stato bruciato una volta. Pagamenti a milestone consegnate, sempre.
4. NON sottoscrivere un contratto annuale col prossimo CTO o agenzia. Inizia con un trimestre di prova.
5. NON cercare di leggere il codice per capire se è fatto bene (a meno che tu non sia tecnico). È esattamente quello per cui esiste l'audit.

Come prevenire la prossima volta

Quasi tutti i founder che si trovano in questa situazione mi dicono la stessa cosa: "mi sembrava una persona affidabile". E probabilmente lo era. Il problema non è la fiducia. Il problema è la mancanza di sistemi di sicurezza.

Quattro pratiche che eliminano il 90% di questo rischio:

• Owner di tutto sei tu. Repo, hosting, dominio, account terzi. Il dev ha accesso come collaboratore, mai come owner.
• Commit settimanali visibili. Anche se non leggi il codice, controlla che ogni settimana ci siano nuovi commit. Un dev che ha smesso di committare ha smesso di lavorare.
• Demo bi-settimanali in produzione. Una call di 20 minuti ogni 2 settimane dove il dev ti mostra cosa è live (non "quasi pronto"). Se rifiuta, è un red flag enorme.
• Audit tecnico ogni 6 mesi. Una valutazione esterna due volte all'anno. Costa poco e previene l'80% degli incidenti.

Riassumendo

Il tuo sviluppatore non risponde più. Non è la fine del mondo, ma l'hai trattato come tale finora — perché eri solo. Da oggi non lo sei. Segui i 5 step in ordine:

1. Recupera gli accessi a tutto (oggi).
2. Fotografa lo stato del progetto (48 ore).
3. Fai un audit esterno (2-3 giorni).
4. Decidi tra sblocco, sostituzione, riscrittura (sulla base dei dati).
5. Evita i 5 errori del prossimo capitolo.

Se vuoi accelerare i tempi e avere qualcuno che ha già visto questa situazione 20 volte, fammi un fischio. Faccio audit e sblocco progetti come questo — la prima call è gratis e ti rispondo entro 24 ore.