«Ma poi ci sarete ancora?» — la domanda più importante

Arriva quasi sempre alla fine, quando le slide sono chiuse e qualcuno sta già infilando la penna nel taschino. Voce più bassa, mezzo sorriso: «Sì, va bene tutto. Ma poi, tra cinque anni, voi ci sarete ancora?». È la domanda più importante di tutta la riunione, e chi la fa quasi si scusa di averla fatta. Non dovrebbe. Dietro c’è una paura concreta, che ha un nome tecnico poco simpatico: dipendenza dal fornitore software. In inglese la chiamano vendor lock-in, ma il modo in cui la vivi tu è più semplice: se questi spariscono, io cosa faccio?

La risposta onesta è che nessuno può garantirti di esistere tra dieci anni. Nemmeno la tua banca, a dirla tutta. Quello che si può garantire è un’altra cosa, e secondo noi conta di più: che se anche sparissimo domani mattina, il tuo software continui a funzionare e qualcun altro possa metterci le mani senza ricominciare da zero.

Cosa succede davvero quando un fornitore sparisce

Ci capita spesso di raccogliere pezzi lasciati da altri. Il copione si ripete: un gestionale scritto anni fa da un professionista che ha chiuso, cambiato mestiere o semplicemente smesso di rispondere. L’azienda ha il software che gira, ma non ha il codice. Oppure ha il codice su una chiavetta, senza sapere se è la versione giusta. Il dominio è intestato a un’email che nessuno controlla più. Il server sta da qualche parte, ma le credenziali erano nella testa di una persona sola.

Il software intanto funziona. Fino al giorno in cui cambia una normativa, o l’hosting aggiorna la versione di PHP, o serve un campo in più in una fattura. Lì la dipendenza dal fornitore software smette di essere un concetto astratto e diventa un preventivo a cinque cifre per rifare tutto da capo.

Un cliente non resta perché non può andarsene. Resta perché non gli conviene andarsene. Sono due cose diversissime, e si vede da come è scritto il contratto.

Non tutti i lock-in nascono da cattive intenzioni. Molti nascono da pigrizia: nessuno ha documentato niente perché tanto «lo sappiamo noi», e col tempo quel sapere è diventato una gabbia per il cliente e un problema anche per chi l’ha costruita. Ma qualche volta la gabbia è voluta. Codice offuscato, licenze che scadono se non rinnovi, database in formati chiusi, backup che il cliente non può scaricare. Sono scelte tecniche con una funzione commerciale precisa, ed è giusto saperle riconoscere.

Il codice è tuo. Anche scritto nero su bianco

Partiamo dal punto che fa la differenza più grande: la proprietà del codice sorgente. Quando ci commissioni un software su misura, il codice è tuo. Non «in uso», non «in licenza»: tuo. Lo scriviamo nel contratto, insieme a quello che ci portiamo dietro noi, cioè le librerie interne e i componenti che riusiamo su più progetti: quelli restano nostri, ma restano anche liberi da vincoli per te.

La differenza si vede il giorno in cui vuoi cambiare fornitore. Se il codice è tuo, apri la cartella, la consegni a chi vuoi e il lavoro riparte da dove si era fermato. Se non lo è, quello che hai comprato non è un software: è un abbonamento a qualcuno.

Concretamente significa tre cose. Il repository, cioè l’archivio dove vive il codice con tutta la storia delle modifiche, è accessibile a te e non solo a noi. A fine progetto ti consegniamo tutto, non soltanto l’applicazione compilata. E se domani vuoi il pacchetto completo per portarlo altrove, non devi chiedere il permesso a nessuno, né aspettare che ci passi il magone.

Gli accessi: nessuna chiave solo in mano nostra

La seconda gabbia, la più banale e la più diffusa, sono gli accessi. Il dominio registrato con l’account del fornitore. L’hosting intestato a lui. Il certificato, i DNS, la casella email di sistema, il profilo dello store per le app mobile. Tutte cose che costano poco e valgono tantissimo nel momento in cui vanno recuperate.

Il nostro criterio è semplice: ogni cosa che si può intestare a te, va intestata a te. Dominio, hosting, account cloud, chiavi delle API dei servizi esterni. Noi ci lavoriamo dentro come collaboratori, con le nostre utenze, che tu puoi revocare in dieci secondi da un pannello. Se un giorno decidi di chiudere il rapporto, non devi chiedere niente a nessuno: sei già proprietario di tutto quello che serve.

C’è un test molto rapido per capire come stai messo adesso, con qualsiasi fornitore. Prova a farti mandare per iscritto l’elenco degli accessi e a chi sono intestati. Se la risposta arriva in due giorni ed è una tabella noiosa, sei in buone mani. Se arriva imbarazzo, hai trovato una risposta comunque.

Documentazione: scriviamo per chi verrà dopo di noi

La documentazione ha un difetto: non la legge quasi nessuno finché non serve disperatamente. Per questo tanti la saltano. Noi la scriviamo pensando a una persona precisa, che non conosciamo e forse non conosceremo mai: lo sviluppatore che un giorno aprirà questo progetto senza di noi.

Non parliamo di tomi da trecento pagine. Parliamo di quel minimo che rende un progetto ripartibile: come si mette in piedi l’ambiente di sviluppo, com’è fatto il database e perché, quali sono i servizi esterni collegati, dove stanno i log, cosa fa il codice nei punti in cui è meno ovvio. E soprattutto le decisioni. Il perché di certe scelte è la parte che si perde per prima ed è la più costosa da ricostruire: un commento di tre righe scritto due anni fa può risparmiare a un altro professionista una settimana di reverse engineering, e a te la parcella di quella settimana.

Nei progetti che nascono da un’analisi di fattibilità fatta prima di scrivere codice questa parte viene più semplice, perché le decisioni sono state prese in modo esplicito fin dall’inizio invece che improvvisate lungo la strada.

Manutenibilità: tecnologie noiose, nessuna magia

C’è un modo elegante di creare dipendenza dal fornitore software senza scriverlo da nessuna parte: usare tecnologie che nessun altro conosce. Un framework proprietario, un linguaggio esotico, un’architettura personale che funziona benissimo ma solo nella testa di chi l’ha scritta. Il cliente non se ne accorge subito. Se ne accorge quando cerca qualcuno per una modifica e riceve tre preventivi che dicono «meglio rifarlo».

Noi scegliamo tecnologie diffuse e ben documentate, di quelle un po’ noiose. PHP e WordPress dove ha senso, Python, React Native o Flutter sul mobile, database relazionali standard, server Linux normali. Non è mancanza di fantasia: è la garanzia che a Verona, a Brescia o dove ti pare esista più di uno studio in grado di leggere quel codice e portarlo avanti. La stessa logica vale per come è organizzato il progetto dentro: struttura prevedibile, nomi in chiaro, poche furbizie. Il codice si scrive una volta e si legge cento, e quelle cento volte non sarà sempre chi l’ha scritto a leggerlo.

Poi c’è una cosa che sembra un dettaglio e non lo è: i dati. Devono poter uscire. Export in formati aperti, accesso diretto al database, backup che puoi scaricare e conservare tu. I dati della tua azienda sono la parte che vale di più di tutto il progetto, e non devono mai restare in ostaggio di un formato che sappiamo aprire solo noi.

Perché per noi è un principio, non un servizio

Niente di tutto questo è un pacchetto in più da mettere nel preventivo. È il modo in cui lavoriamo, e ha anche una ragione egoistica che preferiamo dirti invece di fartela scoprire.

Un cliente legato a noi da un vincolo tecnico è un cliente che prima o poi ci detesterà. Rinnoverà controvoglia, tratterà ogni intervento come un’estorsione e alla prima occasione se ne andrà sbattendo la porta e parlandone male in giro, che in provincia pesa parecchio. Un cliente libero di andarsene, invece, se resta è perché il lavoro gli piace. È l’unico tipo di rapporto lungo che abbia senso costruire, e per fortuna è anche quello che fa dormire meglio la notte, da entrambe le parti.

Quindi sì, la risposta onesta a «ma poi ci sarete ancora?» è: contiamo di esserci, e non abbiamo intenzione di andare da nessuna parte. Ma il punto vero è un altro, ed è che non serve fidarsi sulla parola. Il codice è tuo, gli accessi sono tuoi, i dati sono tuoi, la documentazione esiste. Se un giorno dovessimo sparire tutti, il tuo software resterebbe in piedi e un’altra persona potrebbe prendere in mano il lavoro senza rifare niente da zero.

Questa è l’unica garanzia che qualcuno possa davvero darti. Per questo ci teniamo a metterla per iscritto.