Il cliente deve sapere cosa controlla, a cosa può accedere e cosa gli serve per continuare il progetto anche senza di noi.

La proprietà del codice è solo una parte del problema. Si può possedere il codice e non essere comunque in grado di andare avanti, se mancano gli accessi, i dati, le configurazioni o la conoscenza di come sta in piedi il sistema.

Le domande che contano sono quattro, e in ogni progetto devono avere una risposta chiara prima che serva.

Proprietà: chi possiede quello che viene prodotto. Accesso: chi può entrare nei repository, negli ambienti, negli account e nell'infrastruttura, e da quando. Portabilità: cosa serve concretamente per portare il progetto altrove, comprese documentazione e consegne. Componenti di terzi: librerie, servizi in abbonamento, API, modelli e licenze non possono diventare proprietà del cliente, e va detto quali sono e cosa comportano.

Ci sono poi i dati, che meritano una risposta a parte: di chi sono, chi può accedervi e come si esportano. E ci sono le parti costruite sull'AI, dove quello che è davvero trasferibile non coincide sempre con quello che si vede funzionare: configurazioni e prompt possono passare, un servizio esterno no.

Il principio dietro tutte queste risposte è uno solo: non vogliamo dipendenze artificiali. Se un cliente resta con noi deve essere perché gli conviene, non perché andarsene è tecnicamente complicato.

Le condizioni precise, compreso il rapporto fra pagamenti e trasferimento della proprietà, stanno nel contratto del progetto.