Ricevere una mail dal fornitore che dice "non riusciamo più a seguire il progetto" è meno raro di quanto si pensi. Quando un'agenzia abbandona un progetto software, il problema va ben oltre il ritardo: ti ritrovi con codice che non conosci, processi che non controlli e un prodotto che dipende da conoscenze non più disponibili.
Il vendor lock-in non è solo una questione tecnologica. È una questione di persone, di organizzazione e di controllo.
Perché succede
Nella maggior parte dei casi ci sono dinamiche molto concrete, senza cattiva fede.
Le priorità dell’agenzia cambiano
Arrivano clienti più grandi o più urgenti. Il tuo progetto scivola in fondo alla lista. Le consegne rallentano, l’attenzione cala, finché diventa evidente che non riescono più a seguirti come prima.
Le persone chiave se ne vanno
Lo sviluppatore che conosceva il progetto cambia lavoro. Chi lo sostituisce non ha lo stesso contesto. È lo stesso problema del bus factor, ma fuori dalla tua azienda.
Le tensioni economiche aumentano
Il budget iniziale si rivela insufficiente, le trattative diventano difficili, la collaborazione si logora. A un certo punto, continuare non conviene più a una delle parti.
Il danno vero non è il ritardo
Il ritardo è solo l’effetto visibile.
Il problema più grande è che spesso:
- Non esiste documentazione utile
- Il codice segue convenzioni interne all’agenzia
- Il processo di deploy è noto solo a loro
- L’infrastruttura è configurata in modo opaco
- Le dipendenze non sono tracciate chiaramente
In pratica, perdi la conoscenza operativa del tuo stesso prodotto.
Come proteggersi prima che succeda
Alcune regole, se stabilite dall’inizio, riducono drasticamente il rischio.
Il repository deve essere tuo
Il codice deve stare su un repository di tua proprietà. L’agenzia ha accesso, ma tu sei il proprietario. Se il rapporto finisce, il codice resta a te senza discussioni.
La CI/CD deve essere trasparente
Il processo di deploy deve essere automatizzato, documentato e comprensibile. Non può dipendere da una procedura manuale che solo loro conoscono.
Documentazione minima ma continua
Tre cose sempre aggiornate:
- Come avviare il progetto in locale
- Come funziona il deploy
- Le principali decisioni architetturali
Se si rimanda “alla fine”, di solito non verrà mai fatto.
Sessioni periodiche di allineamento
Una volta al mese qualcuno della tua azienda dovrebbe capire cosa è cambiato, come è evoluto il progetto e quali sono i punti critici. Questo riduce la dipendenza totale dal fornitore.
Tecnologie standard, non framework proprietari
Soluzioni troppo personalizzate rendono molto difficile il passaggio a un altro fornitore. La velocità iniziale può trasformarsi in un costo di manutenzione molto alto nel tempo.
Cosa fare quando è già successo
Se ti trovi già in questa situazione, l’ordine delle azioni conta.
Evita la tentazione di riscrivere tutto
L’istinto è buttare via tutto. Spesso è un errore, come spiegato parlando del perché riscrivere da zero è rischioso. Il codice esistente contiene mesi di lavoro e casi limite già risolti.
Fai un audit tecnico indipendente
Un developer senior esterno può analizzare il codice in pochi giorni e darti una mappa chiara: cosa è recuperabile, cosa è rischioso, cosa va sistemato subito.
Metti in sicurezza l’infrastruttura
Verifica e prendi controllo di:
- Dominio
- Hosting
- Database
- Certificati
- Accessi ai servizi esterni
Questa è la priorità assoluta.
Valuta con calma il passo successivo
Solo dopo aver capito la situazione reale puoi decidere se cambiare fornitore, internalizzare o fare una soluzione mista. Ma questa volta con regole più chiare.
La lezione da portare a casa
La dipendenza da un fornitore è un rischio di business, non tecnico.
Ogni mese in cui il tuo progetto vive su repository che non controlli, con processi che non conosci e decisioni che non sono documentate, stai accumulando un debito di autonomia.
E quando arriva il momento di pagarlo, il costo è molto più alto di quanto immagini.
Simone Giusti
Consulente software strategico
