Zero lock-in contrattuale, zero lock-in tecnico. La proprietà del codice dei SaaS che scriviamo per voi è vostra, scritta nero su bianco nel contratto. Su richiesta depositiamo i sorgenti in escrow presso notaio con clausole di rilascio automatico (fallimento nostro, mancato rinnovo, violazione SLA). I dati li esportiamo in formati standard: SQL dump, mbox, JSON, formati applicativi. La procedura di handover al fornitore successivo è definita in anticipo e ha SLA di 5-7 giorni lavorativi.
01La filosofia: niente lock-in, per scelta
La fedeltà di un cliente non si compra con vincoli contrattuali, si guadagna facendo bene il lavoro. È una posizione che tiene da quarant'anni di mestiere: quando un cliente resta perché non può andare altrove, il rapporto è già avvelenato. Prima o poi trova comunque il modo di liberarsi — e quando succede, ti porta via anche quelli che stavano bene.
Per questo il nostro contratto standard non contiene clausole di esclusiva, penali di uscita sproporzionate, proprietà intellettuale in capo a noi sul codice fatto per il cliente, formati dati proprietari. Se dopo due anni decidete che vi trovate meglio altrove, il peggio che vi diciamo è "ci dispiace, com'è andata, c'è qualcosa che dovevamo fare meglio?". Poi vi prepariamo il pacchetto di handover.
Non è altruismo. È che un fornitore che può trattenerti solo con le catene smette di migliorare. I vincoli contrattuali non sostituiscono la qualità del servizio — la mascherano, finché la maschera tiene.
02Proprietà del codice: chi possiede cosa
Nei contratti di sviluppo SaaS che firmiamo, l'articolo sulla proprietà intellettuale è esplicito: il codice applicativo specifico scritto per il cliente è di proprietà del cliente, dal momento del pagamento della relativa milestone. Non "licenza d'uso", non "diritto non esclusivo" — proprietà piena, con facoltà di modifica, fork, redistribuzione, affidamento a terzi.
Ci sono due eccezioni ragionevoli, dichiarate in anticipo:
- Librerie interne di riuso — componenti che abbiamo sviluppato nel corso degli anni su più progetti (moduli di autenticazione, integrazioni ricorrenti, utility). Restano di nostra proprietà; il cliente ne ha licenza d'uso perpetua, irrevocabile, gratuita, per l'ambito del progetto. Nessuno riscrive ogni volta da zero un client OIDC o un wrapper Stripe, e farvelo pagare come "vostro" sarebbe scorretto.
- Software open source di terzi — resta sotto la licenza originale (MIT, Apache, AGPL a seconda dei casi). Il cliente eredita gli stessi diritti e obblighi che ha chiunque lo usi.
Il confine è tracciato nel contratto, non interpretato a posteriori. Se c'è ambiguità su un modulo, si chiarisce prima di scriverlo — non quando qualcuno vuole andarsene.
03Escrow tecnico: il meccanismo reale
Per i clienti che vogliono una tutela ulteriore — tipicamente chi costruisce sopra il nostro SaaS un pezzo critico del proprio business — offriamo il deposito dei sorgenti presso un notaio terzo, con accordo di escrow software.
Come funziona concretamente: ogni trimestre consegnamo al notaio un pacchetto cifrato contenente l'intera codebase, le istruzioni di build, gli schemi database, l'elenco delle dipendenze con versioni pinnate. Il notaio custodisce il pacchetto e rilascia la chiave di decrittazione al cliente solo al verificarsi di condizioni di triggering definite nel contratto: fallimento o liquidazione di PSA, mancato rinnovo del contratto per nostra rinuncia, violazione di SLA non risolta oltre soglie concordate, cessazione dell'attività sul servizio.
Il costo reale dell'escrow notarile si attesta tra 300 e 600 €/anno a seconda del notaio e della frequenza di deposito. Lo sosteniamo noi, in bolletta non compare. Chi lo chiede è un cliente che sta mettendo sopra il nostro codice un pezzo di business serio — è giusto che la tutela non sia un extra da fatturare.
04Formati di export: standard, non nostri
Il formato dei dati è il secondo punto dove si annida il lock-in — più subdolo del codice, perché spesso il cliente si accorge del problema solo quando prova a uscire. La regola interna: nessun dato deve vivere solo in un formato che esportiamo solo noi.
| Tipo di dato | Dove vive | Formato di export |
|---|---|---|
| Database applicativo | PostgreSQL / MariaDB | SQL dump (pg_dump, mysqldump) |
| Caselle di posta | Mailserver IMAP | mbox o Maildir, full fidelity |
| Configurazioni servizi | File app / YAML | JSON o YAML leggibile |
| Asset e allegati | Filesystem / S3-compatible | Archivio tar.gz con alberatura originale |
| Log e audit trail | File di log / Loki | CSV + ndjson per i tool moderni |
| VM e container | Proxmox / Docker | OVA per VM, image tar per container |
Nessun "formato nostro". Nessun database proprietario. Nessun blob opaco che solo noi sappiamo aprire. Se un giorno il cliente carica questi dump su un server nuovo con il fornitore nuovo, li rimette in piedi senza di noi.
05Runbook e documentazione: cosa consegnamo davvero
Il codice senza contesto è metà del lavoro. La consegna di handover include sempre:
- Documento di architettura — diagramma dei componenti, flussi dati, dipendenze esterne, scelte architetturali con il perché (non solo il cosa). Serve al fornitore successivo per capire dove mettere le mani.
- Credenziali — consegnate attraverso un password manager condiviso (tipicamente Bitwarden o 1Password), non via email. Ogni credenziale è etichettata per servizio e scadenza.
- Runbook operativo — procedure passo-passo per le operazioni ricorrenti: deploy, restart di emergenza, ripristino da backup, aggiornamento certificati, gestione DNS. Scritto per una persona che non ha mai visto prima il sistema.
- Elenco contratti con terze parti — cloud provider, domain registrar, certification authority, mailserver esterni, servizi di pagamento. Con contatti account, numeri cliente, date di rinnovo.
- Log di incidenti e interventi — cosa è successo negli ultimi 12 mesi. Chi prende in mano il sistema eredita anche la memoria operativa.
06La procedura di handover: come funziona
Timeline tipica: 5-7 giorni lavorativi dalla richiesta scritta del cliente. Non è un SLA di cortesia, è un numero che sta nel contratto.
Chi coordina: una persona tecnica nostra con mandato esplicito a rispondere al fornitore successivo — non una segretaria, non un commerciale. Di norma è chi ha messo le mani sul sistema durante la gestione corrente, quindi conosce i dettagli che non stanno nei runbook.
Il flusso pratico: giorno 1-2 consegna sorgenti + dump dati + documentazione; giorno 3-5 call tecnica con il fornitore entrante per walkthrough dell'architettura e delle peculiarità operative; giorno 6-7 passaggio credenziali, trasferimento DNS e domini, disattivazione degli accessi nostri. Poi usciamo di scena.
Ammissione onesta: se il sistema è molto complesso o integrato con altri pezzi, sette giorni sono stretti per un trasferimento indolore. In quei casi concordiamo un periodo di affiancamento aggiuntivo — fatturato a giornata, senza minimi contrattuali. Non è nascosto in clausole, si negozia in chiaro.
07Casi reali: com'è andata
In vent'anni ci sono stati tre clienti che hanno scelto di spostarsi altrove: uno perché si è fatto acquisire da un gruppo che aveva già un IT interno, uno per un cambio di CTO che voleva portare il lavoro a un fornitore con cui aveva una relazione pregressa, uno per riduzione drastica del budget IT dopo una ristrutturazione. In tutti e tre i casi l'handover è avvenuto nei tempi previsti, senza contenzioso.
Il dato che ci interessa davvero è un altro: nessuno dei tre è tornato indietro perché non poteva. Se uno dei tre fosse tornato, saremmo stati contenti — ma per il motivo giusto, non perché il fornitore nuovo aveva trovato un file zippato con password persa da recuperare.
Il rapporto con un fornitore IT è un matrimonio tecnico: lungo, complicato, a volte logorante. Ma deve restare un matrimonio tra adulti consenzienti, non una prigione. Questo è il patto.