Cosa vuol dire che codice e server sono intestati a te

C'è una storia che sento spesso. Un'attività fa fare un sito o un gestionale, tutto va bene per un paio d'anni, poi il rapporto con lo sviluppatore finisce. E si scopre che il dominio è intestato a lui, che il server è sul suo account, che il codice non si sa dove sia. Il software funziona, ma non è tuo. Sei un ostaggio gentile.

Per questo la prima delle mie garanzie è: tutto intestato a te. In questo articolo ti spiego cosa vuol dire, pezzo per pezzo.

I pezzi di un software

Un sito o un gestionale non è una cosa sola. È fatto di parti diverse, e ognuna ha un proprietario. Vediamole.

• Il codice sorgente. È il testo scritto dallo sviluppatore da cui nasce il programma. Chi ha il codice può modificarlo, correggerlo, farlo crescere. Chi non ce l'ha, no.
• Il server. Il computer sempre acceso, di solito nel cloud, dove il software gira. Ha un account con un nome sopra.
• Il database. L'archivio con i tuoi clienti, i tuoi ordini, i tuoi documenti. Il database è la parte più preziosa: sono i tuoi dati.
• Il dominio. L'indirizzo del sito. Chi lo possiede decide dove punta.
• Gli account dei servizi. Email, pagamenti, store delle app, invio di notifiche. Ognuno ha un login e un intestatario.

Quando dico “tutto intestato a te”, intendo tutti e cinque. Non basta avere il codice se il dominio è di qualcun altro, e non basta avere il dominio se il codice è sparito.

Cosa ricevi alla consegna

Alla consegna non ricevi solo un sito che funziona. Ricevi un documento con dentro tutto quello che serve per essere autonomo.

1. 01Il codice sul tuo account GitHub, in un repository con tutta la storia delle modifiche. Io ci lavoro come collaboratore: puoi togliermi l'accesso quando vuoi.
2. 02L'account del server, per esempio Vercel per i siti, intestato a te, con la tua email e il tuo metodo di pagamento.
3. 03L'account del database, per esempio Supabase, con i backup automatici già attivi.
4. 04Il dominio sul tuo account, con il rinnovo automatico impostato.
5. 05Gli accessi a ogni altro servizio usato dal progetto, elencati uno per uno, con scritto a cosa serve ciascuno.
6. 06Le istruzioni per pubblicare una modifica, scritte in modo che un altro sviluppatore capisca in un'ora.

Perché lo faccio

Potrei fare come tanti: tenere tutto sui miei account e chiederti un canone mensile. Sarebbe una rendita comoda. Ma cambierebbe il rapporto: tu resteresti con me perché non puoi andartene, non perché lavoro bene.

C'è anche un motivo pratico. Se mi succede qualcosa, se cambio lavoro, se sparisco per un mese, la tua attività non si ferma. Il software è tuo e chiunque può metterci mano.

E i costi dopo la consegna?

Questa è la domanda che arriva subito dopo, ed è giusta. Se non paghi un canone a me, paghi qualcosa a qualcuno? Sì, ma poco, e direttamente al fornitore.

Cosa non vuol dire

Per onestà, ti dico anche cosa questa garanzia non copre.

• Non vuol dire che il software non ha bisogno di cure. Ogni tanto una manutenzione serve, per esempio quando un servizio esterno cambia. Si fa a preventivo, quando serve, e la puoi affidare a chi vuoi.
• Non vuol dire che i prezzi dei fornitori restano fermi per sempre. I fornitori cambiano i piani. Per questo scelgo servizi open source o con alternative facili, così se un fornitore alza i prezzi si trasloca.
• Non vuol dire che devi capire tutto tu. Il documento di consegna serve al prossimo sviluppatore, non a te. Tu devi solo sapere che esiste e dove sta.

Come verificarlo

Con me o con chiunque altro, prima di firmare fai una domanda semplice: “Alla consegna, a chi sono intestati dominio, server, database e codice?”. Se la risposta non è “a te” per tutti e quattro, chiedi perché.

La proprietà del codice non è un dettaglio tecnico. È la differenza tra avere uno strumento e avere un affitto.